Questions regarding zcash docs and transactions

[Hinghould]

Hi @ all
I am working on a small project. Its about to interact with a local zcash testnet node via HTML interface and RPC-commands. Until now, everything works fine. The project is just for self studying and to learn more about the technology. While reading the “Zcash 5.5.0 RPC Docs” i was from time to time confused. I hope that someone can help me with my questions.

In the whole chapter(z_mergetoaddress) is no word about unified addresses. Is it possible to use ANY_UNIFIED in the “fromaddresses” array?
Is it possible to mix sapling and orchard addresses in “fromaddresses” array?
What are the default shielded limits for orchard notes?

As i saw, there is just one command to generate addresses - z_getaddressforaccount.
The commands getnewaddress and z_getnewaddress are DEPRECATED. How to generate different types of addresses? I was just able to generate utest1… addresses with different pools.

If you validate unified addresses (z_validateaddress), the property “ismine” is missing in the Result. What is the reason for?

The last thing is about transactions between different accounts in the same wallet.

Example:

I created a transaction (z_sendmany) from a unified address[Account:0,receiver_types:[“orchard”]] to three different receivers.
Receiver one: unified address[Account:1,receiver_types:[“p2pkh”, “sapling”, “orchard”],amount:0.01]
Receiver two: unified address[Account:3,receiver_types:[“p2pkh”, “sapling”, “orchard”],amount:0.01]
Receiver three: unified address[Account:4,receiver_types:[“p2pkh”, “sapling”, “orchard”],amount:0.02]

I was expecting that i spend a amount in the high of 0.0401 ZEC. But my expecting was wrong. I spend a amount of 0.04606575 ZEC. If i check the transaction details, there is one additional entry in the outputs array. The entry has a amount of 0.00596575 ZEC.
The differences to the other entries are the the property “address” is missing and “walletInternal” is true.
After the transaction is done, the amount of 0.00596575 ZEC returns to the sender address. During the transaction, it is not possible to use this amount.
What is the reason for this behavior? How can i calculate the additional amount before the transaction is made?

Best regards

[Autotunafish]

The z_mergetoaddress works w/ taddy and sapling (and sprout to migrate maybe), not orchard. They can be a mixed array of those allowed address types.
A limit on combining orchard notes, as an aside, might be governed by the tx’s action count, each note would constitute at least 2 (I figure?). The fewer the actions, the lighter and smoother it all goes so. Once you exceed 20 maybe then you start to get into spam-filter territory…
Use the z_getaddressforaccount like so:
This call would generate a new full UA for acct 4 at the diversifier index 1

zcash-cli z_getaddressforaccount 4 ‘[“p2pkh”,“sapling”,“orchard”]’ 1

This call would generate a new partial UA with Orchard and transparent receivers for acct 2 at the diversifier index 3

zcash-cli z_getaddressforaccount 2 ‘[“p2pkh”,“orchard”]’ 3

This call would generate a new partial UA with a single Sapling receiver for acct 3 at the diversifier index 7

zcash-cli z_getaddressforaccount 3 ‘[“sapling”]’ 7

See?

Yes zcashd wallet tx behavior is a little different now it seems such as with the whole acct balance being locked for the tx and other things, I’ll leave it to the ecc devs to explain why that is, idk.

[Hinghould]

Hi Autotunafish
thanks for your time and reply.
With your information, I will continue testing the “z_mergetoaddress” function. We will see how it progresses.

I will keep the following in mind when generating addresses.
It is only possible to generate uniform addresses. The address will always start with (u/utest1). The length of the address will change with the number of pools used.
1 pool = 110 characters (p2pkh is not allowed as single pool. At least one shielded pool is needed)
2 pools = 182 characters
3 pools = 217 characters.

Without the “listaddresses” command, I can’t see which address uses which pool.

Have a great day

[Autotunafish]

Those commands are deprecated but the address types generated by them i.e transparent and sapling only or standalone would be required for the use of z_mergetoaddress. Unified addresses can contain different combinations of those addresses but they are considered receivers and not individually usable in the same way as a legacy standalone address. Otherwise z_sendmany can give you the same overall functionality of combining per-account notes in a tx with more flexibility

[Hinghould]

After a few more tests, i found two more curiosities.

If you check a transactions between unified addresses using the “gettransaction” command, the fee property has the value of the amount spent and not the value of the transaction fee paid.

At the end one more transaction.
The transaction is between two unified addresses of the same account but different pools.
I planed to send 0.01 ZEC from a unified address [“account”:4,“receiver_types”:[“sapling”]] to an unified address [“Account”:4,“receiver_types”:[“orchard”]]. The balance on the sender’s side before the transaction was 0.03 ZEC. I used 0.0001 ZEC as the fee and “fullPrivacy” as the privacy policy.
The whole “sapling” balance (0.03 ZEC) went into the transaction process. In the output array (z_viewtransaction) are two entries. The first entry has a amount of 0.0199 ZEC (unknown random amount) and the second entry has a amount of 0.01 ZEC. I thought, perfect, then the amount of 0.0199 ZEC will return to the sapling balance. I was wrong again. Nothing came back, the entire balance is now in the orchard pool. Of course, I have also tested the reverse way. It was okay

Best regards

[Autotunafish]

Agree on the curiosities with the amounts displayed with regards to the fee and I have to look into that a little more deeply.
The second part about the weird transaction sounds like the change was auto-shielded into orchard and the amount missing would be the new compounded-action transaction fees enforced now by 317. There is a new transaction builder send method coming that will give users more insight about what will happen during the transaction but it has not yet been released yet.
Do you have that txid?

[Hinghould]

Hi Autotunafish
here is the TXID of the last case - 21ff65b2a9503c6505ac906a6ef71cde73b1c9629c33bd758cbd1f38814ea510.
I hope, you will find something, to bring more light in the dark.

Best regards

[Autotunafish]

No but I assume it’s because this particular Explorer isn’t updated to support newer transaction types. I’ll have to resync my testnet node and then get the block deltas and then take a look at that transaction for more details
https://blockexplorer.one/zcash/testnet/tx/21ff65b2a9503c6505ac906a6ef71cde73b1c9629c33bd758cbd1f38814ea510

[Hinghould]

I checked the transaction details again and have an idea why this happened. The additional random amount was also deposited into the orchard pool. In most cases, this random amount goes back to the sender. But in this case, it can’t go back because the amount is in a different pool. After the transaction is done, it remains in the orchard pool

Best regards

[hanh]

Zcash follows the utxo model. If you are not familiar with it, I recommend you read about it first.

[Autotunafish]

As you can see the funds were transferred (autoshielded) from sapling to orchard and the (new-original) normal fee was paid. This is the wallet behavior w/ regards to shielded by default