Witness for note commitment is null on spending from imported Zaddr

After importing a z spending key from one wallet to a new wallet I want to send coin from the corresponding zaddr in the second wallet to a new zaddr in that second wallet. I see the correct amount in the zaddr with z_getbalance. I have this message when trying to do the shielded TX with z_sendmany from the second wallet: “Witness for note commitment is null”. I did reindex the second wallet but it still does not want to send doing the same message. How can this be resolved and what does it mean? Documentation is sparse on this issue. When trying to do the TX from the first wallet it works. I thought just importing the spending key was sufficient to spend the zec out of a zaddr.

Also reindex is very slow using most of the time only one core cannot this be multi threaded? Or maybe can I reindex only part of the block chain? Thx

2 Likes

After reindex of the new wallet ended (was done offline) I stopped zcashd and launched it again online to finish synchronization. It aborted with this error:

zcashd: wallet/wallet.cpp:659: void CWallet::IncrementNoteWitnesses(const CBlockIndex*, const CBlock*, ZCIncrementalMerkleTree&): Assertion `(nd->witnessHeight == -1) || (nd->witnessHeight == pindex->nHeight - 1)’ failed.
Aborted

2 Likes

@Lou I filed a Github ticket about this, so reponses might be there as well as here. User writes "Witness for note commitment is null on spending from imported Zaddr" · Issue #2486 · zcash/zcash · GitHub

[Edit by @daira: moved to error on spending from imported z-addresses: "Witness for note commitment is null" · Issue #2524 · zcash/zcash · GitHub ]

1 Like

@Lou ou Can you post to the Github ticket the commands you ran to set up the second node/wallet, reindex etc. Did you run zcash-cli z_importkey spendingkey yes

1 Like

Hmm I just tried this on regtest and it worked:
zcash-cli -regtest z_exportkey address
then
zcash-cli -regtest stop
then
deleted wallet.dat
ran zcashd -regtest -daemon

did
zcash-cli -regtest z_importprivkey key
and
z_sendmany worked for corresponding address

did you use z_exportkey to get the key?

Same thing worked on mainnet

A sidenote while working on this - we really need to have z_listrecievedbyaddress return recieved at all addresses if not given an address parameter.
Otherwise you need to go over all your addresses manually to see where your outputs are

Hmm - I’m betting it has to do with this comment in the code before the assertion failed:

                // The only time a note witnessed above the current height
                // would be invalid here is during a reindex when blocks
                // have been decremented, and we are incrementing the blocks
                // immediately after.

thank you bitcartel and arielgabizon,

Well I did a z_exportwallet “filename” and took it out of this generated file.

I then imported the Skey using zcash-cli z_importkey spendingkey

I then tried to send from it to another z_address in that wallet and got the error “Witness for note commitment is null”. -rescan did not change anything to this error.

I then reindexed, as it was taking so long I sent from the first wallet the coin to the z_address in the second wallet directly.

When the second wallet finished reindexing (offline) I stop it, and ran the daemon (online, to synch) and it crashed on startup with the second error (zcashd: wallet/wallet.cpp:659). Luckily I had a backup of the VM in which this wallet was and I could get the coin in the second z_address after synching. The first z_address was empty so I could not try to send again from this copy of the second wallet.

At this point, did you wait until the reindexing had finished before trying to send? You can force the rescan by adding “yes” as a parameter after the spendingkey.

Ping @str4d

I imported the keys, several in a row in fact, with “zcash-cli z_importkey spendingkey no” for the first ones then “zcash-cli z_importkey spendingkey yes” for the last one (to not do rescan everytime). I then closed the second wallet for 2 weeks.
Later, I opened the second wallet, synch it, tried to send from one of the zaddress in common between the two wallets to one of the zaddress only in the second wallet (all this was to change of wallet while keeping traceability by importing the relevant key from the first wallet, so I could show with the viewkey later from where the coin came). At this time it failed with “Witness for note commitment is null”. I did -rescan it changed nothing. I did -reindex then.
Meanwhile as reindexing was so long I sent from the common same zaddress in the first wallet to one of the z address in the second wallet (same TX I tried to do from the second wallet and that failed with the error). This worked from the first wallet. I thought it shall not be an issue to do this while reindexing the second wallet because it was months backward in time at this index. After reindexing finished (offline), I stopped the second wallet, put internet and run zcashd to synch the last blocks (that shall have contained the spend TX). During the initial rescan at opening it crashed with the zcashd: wallet/wallet.cpp:659 error. Then I took my backup of the second wallet, synched it, got the coin and moved them to taddress to be sure :wink:

I wanted to use the z_exportwallet and z_importkey feature to save my wallet on paper, but now that I see this issue with the zkeys I will only put on paper the t_address which I am sure give no error on importation as it is well known code. BTW z_importwallet “walletfile” does not work, the exported file is not found even tough the folder is specified in zcash.conf and the name of file is the same than used with z_exportwallet “walletfile”.

But can you explain briefly what is this note commitment and why it is not possible for me using the SKey and the common state of the blockchain to use the coins in the imported Z_address (which I can see with z_getbalance).

1 Like

Is there a solution or workaround for this problem?

When importing z_addresses it also helps to know how long they’ve been in use to guesstimate what block their transaction history starts at and then provide that number to: z_importkey “zkey” ( rescan startHeight )

Thanks for your reply!

Shouldn’t it then be enough to start the wallet just with -rescan? I tried that and it doesn’t help. Also reindexing didn’t work out so far.

I also read the thread in the github issue to this topic but it didn’t really help.

In my case it’s about BTCP, but a solution for ZCash should help there too obviously.

If a sufficiently low blockheight is entered with z_importkey to account for all the transactions for that key then I don’t know why it would be necessary to use the -rescan flag when starting zcashd.

I had the same problem and tried almost all solutions that have been offered and somewhere on github I read that if you export your wallet before full sync it works so I tried and it worked,the things that I did was,exporting the wallet which holds the coins and has problem with sending and then making a new wallet from zero and immediately after starting zcashd I imported the wallet with z_importwallet and waited until full sync and today I didn’t had problems with spending :slight_smile: