zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

s/when a rollback occurs/when a reorg or rollback occurs/

This commit is contained in:
Jack Grigg 2019-10-19 16:44:27 +13:00
parent 821bd9f8f1
commit 90ad18ff22
No known key found for this signature in database
GPG Key ID: 9E8255172BBF9898
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
zip-0213.rst
View File

@ -127,17 +127,17 @@ spending a note is to select an anchor 10 blocks back from the current chain tip
acts as a de-facto 10-block maturity on all notes, coinbase included. This might be
proposed as a consensus rule in future.
There is another reason for shielded coinbase maturity being unnecessary: when a rollback
occurs that would cause a shielded coinbase output to disappear, it will also invalidate
every shielded transaction that uses an anchor descending from the tree that the shielded
coinbase output had been appended to. That is, all economic activity would be rolled back
in addition to the shielded coinbase output disappearing, so there is no reason to make
shielded coinbase a special case when the same behaviour occurs in regular shielded notes
already. In the transparent coinbase case, only direct child transactions of the
transparent coinbase would become invalid, and thus it would be possible to end up in a
situation where a logical child transaction (for example, a mining pool paying out miners)
persists in the block chain after its logical parent (the mining pool receiving a block)
disappears.
There is another reason for shielded coinbase maturity being unnecessary: when a reorg or
rollback occurs that would cause a shielded coinbase output to disappear, it will also
invalidate every shielded transaction that uses an anchor descending from the tree that
the shielded coinbase output had been appended to. That is, all economic activity would be
rolled back in addition to the shielded coinbase output disappearing, so there is no
reason to make shielded coinbase a special case when the same behaviour occurs in regular
shielded notes already. In the transparent coinbase case, only direct child transactions
of the transparent coinbase would become invalid, and thus it would be possible to end up
in a situation where a logical child transaction (for example, a mining pool paying out
miners) persists in the block chain after its logical parent (the mining pool receiving a
block) disappears.
Requiring that note commitments are valid when recovering using a fixed outgoing viewing
key implies that target addresses and values for all Sapling outputs within the coinbase