Z_sendmany - Privacy Policy

Technical Support
1

Two Part Question:

Part One:
When sending zec with zcash-cli z_sendmany using curl:

curl --user myusername --data-binary ‘{“jsonrpc”: “1.0”, “id”:“curltest”, “method”: “z_sendmany”, “params”: [“t1M72Sfpbz1BPpXFHz9m3CdqATR44Jvaydd”, [{“address”: “ztfaW34Gj9FrnGUEf833ywDVL62NWXBM81u6EQnM6VR45eYnXhwztecW1SjxA7JrmAXKJhxhj3vDNEpVCQoSvVoSpmbhtjf”, “amount”: 5.0}]] }’ -H ‘content-type: text/plain;’ http://127.0.0.1:8232/

1 1.0 ‘AllowFullyTransparent’ ?? where is it placed? in the above curl

Where, what is the correct formatting for the different Privacy Policy Options using curl? examples?

Part Two:
Using : z_listunspent , z_viewtransaction, z_listreceivedbyaddress, I’m trying to find a method to view a received transaction’s privacypolicy? If I receive a transaction to my wallet which is transparent, reveals amounts or receiving address etc, How can I view the policy used?

@Autotunafish or any help / advice out there?
Thanks

2 Likes
2

Check out the examples here.

The privacy policy is not actually contained in the transaction metadata. It’s just a function of the senders wallet. However, you can get a pretty good idea about it per the address you received the funds at. If it was received transparent, then the minimum policy would have been ‘AllowRevealedRecipients’

Ill find some better examples

(I don’t know if anybody has actually asked about the curl version of the command)

1 Like
3

Curl z_sendmany with Privacy Policy: Help
Have any of you been able to z_sendmany using curl with privacy policy in the correct format?
@pacu, @_garethtdavies, @ChileBob @BrunchTime

Any help welcome.

Maybe this helps someone, here’s what some parameter arrays will look like:

[] — An empty array
["000b4430a7a2ba60891b01b718747eaf9665cb93fbc0c619c99419b5b5cf3ad2"] — An array with data
["'$signedhex'"] — An array with a variable
[6, 9999999] — An array with two parameters
{} - An empty object
[''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout' } ]'', ''{ "'$recipient'": 0.298, "'$changeaddress'": 1.0}''] — An array with an array containing an object and a bare object
1 Like
4

The node that I run has the internal wallet disabled (because it was making it a little bit under performant) so I cant personally troubleshoot this. The 3 values don’t have associated field labels but theyll likely be double quoted(?) and contained within the same bracket as the first address(?), perhaps like this?
5.0}] 'val1, ‘val2’, “privpolicy”] }’ -

The 2 numeric values might need single quotes, because I guess they may not technically be strings.

1 Like
5 
rpcCreds="your_username:your_password"

creds=$(echo -n "$rpcCreds" | base64)

authHeader="Basic $creds"

curl -v -X POST "http://localhost:18232" \
     -H "Authorization: $authHeader" \
     -H "Content-Type: application/json" \
     -d '{
           "jsonrpc": "1.0",
           "id": "curltest",
           "method": "z_sendmany",
           "params": [
             "'"{FROM_ADDR}"'",
             [
               {
                 "address": "'"{TO_ADDR}"'",
                 "amount": '"0.001"'
               }
             ],
             1,
             0.00001,
             "AllowRevealedRecipients"
           ]
         }'

This is what I’d do, works for me

5 Likes
6

Ah ok no qoutes on the first two :heart:Solid Snake
and that little, leading comma

2 Likes
7

Monumental Thank you @BrunchTime !!!
Thanks, for the quick and awesome reply, written perfectly clear. Works like a charm.

Go Bruins

4 Likes
8

Hi! Joining a little late to the party.

You need to put your arguments as @brunchtime said, in the JSON string payload.

This is because CURL is communicating with your node through RPC calls, so you are calling your node as it if was any node out there.

You also need to verify how your node is configured to make sure you authenticate correctly using the rpcuser and rpcpassword that you’ve set for it.

TIP: the zcashd node is not great at selecting notes. So it’s always convenient to have a good stock of unspent notes at your disposal to avoid “duplicate nullifier” errors when sending many payments subsequently.

2 Likes
9

Hi all, kinda related to this. I have some zcash from back in the day on a t-address. I am trying to play around with the private transactions/addresses.

I tried the z_sendmany, but with no success. Most of the posts I found use a z_address. The latest wallet doesnt give a z_address, it gives a u-address.

What is the proper flow of getting funds from t (transparent) to z or u?

zcash-cli z_getnewaddress
error code: -1
error message:
z_getnewaddress is DEPRECATED and will be removed in a future release

Use z_getnewaccount and z_getaddressforaccount instead, or restart 
with `-allowdeprecated=z_getnewaddress` if you require backward compatibility.

Should I pass this deprecated flag so I can get a z-address and then send from z to u?

Or is there a way to send directly from t to u?

Also, is there any GUI for zcashd? Its been years since I used it last and the user experience is even worse now then it was on the day of the launch lol :slight_smile:

1 Like
10

If you really need that RPC method just restart with the flag.

I understand that you need to send your funds from the t address to some other place.

Z_sendmany should let you spend transparent funds provided that you specify the correct privacy policy. this is mainly necessary so that you are aware of the privacy implications of the transaction you will initiate. I did’t test it but IIRC if you do z_sendmany --help you should be shown all the options available

1 Like
11

I have built some helper utilities that may help here.

Hope this helps :student:

12

We don’t currently have a JSON-RPC method that includes an inferred privacy policy used by the sender for a received transaction, but it wouldn’t be particularly hard to implement, because the privacy implications of a given transaction are plainly visible in its format.

The purpose of the privacy policy argument to zcashd’s JSON-RPCs was to enable senders to control how their wallet built their own transactions, within the constraints of JSON-RPC’s limited interactivity for existing methods. It’s not really the ideal way to handle the privacy implications of a proposed transaction, but it worked well enough for this purpose.

A better mechanism, and the one we’ve been working towards in the Zcash Rust crates, is to build transactions in steps:

  • User requests that a transfer of funds be created (e.g. with a ZIP 321 Payment Request URI).
  • Wallet returns a Transaction Proposal, that says how the wallet will enact the requested transfer of funds.
    • In particular, this contains enough information to determine the privacy implications of the proposed transaction(s).
    • Wallets should always strive to create the most private transaction possible, given the constraints of the user’s current wallet state.
  • User reviews the Transaction Proposal in their wallet’s UI, which ideally includes details about what information will be disclosed or leaked.
  • If the user is happy with the Transaction Proposal and its privacy, the user confirms the proposal.
  • The wallet then builds the corresponding transaction(s) from the proposal.

Privacy Policies in zcashd have the downside that the user has to state the desired policy up-front before any proposal is made, and if the proposal can’t be created satisfying the stated policy then nothing happens and the user doesn’t learn what kind of transaction could have been created. With the Transaction Proposal workflow (currently used under the hood in the mobile SDKs and that I want to expose JSON-RPCs for in Zallet), users instead learn the (ideally if the wallet is well-implemented) most private transaction that the wallet can produce, and they can decide whether that transaction is sufficient or whether they need to take additional steps to improve the overall state of their wallet and enable more private transactions.

1 Like
13

That was actually my question. Do I need this method?

I am asking because from the resources I found around the forum, the example transactions commands always use from t to z address.

And same with unified u addresses, they always use from z to u address.

So my main question here is, is it possible to send from t to u without using the deprecated functions?

14

Yes. A Unified Address (u address) is just a wrapper around one or more z addresses and possibly a t address. The underlying protocols used are the same.

1 Like