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

ZIP 213: Clarify rationale for no shielded coinbase maturity

This commit is contained in:
Jack Grigg 2020-02-24 12:21:21 +00:00
parent 206ff55aff
commit 9e45264d9d
1 changed files with 24 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
zip-0213.rst
View File

@ -124,17 +124,30 @@ 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 acts as a de-facto 10-block maturity on all notes, coinbase included. This might be
proposed as a consensus rule in future. proposed as a consensus rule in future.
There is another reason for shielded coinbase maturity being unnecessary: when a reorg or There is another reason for shielded coinbase maturity being unnecessary: shielded
rollback occurs that would cause a shielded coinbase output to disappear, it will also coinbase outputs have the same effect on economic activity as regular shielded outputs.
invalidate every shielded transaction that uses an anchor descending from the tree that When a transparent address receives a coin in some "parent" transaction and later spends
the shielded coinbase output had been appended to. That is, all economic activity would be it, a tree of "direct child" transactions is created that all require the original parent
rolled back in addition to the shielded coinbase output disappearing, so there is no transaction to be valid. However, most wallets treat unspent transparent outputs as a
reason to make shielded coinbase a special case when the same behaviour occurs in regular single "bucket of money", and select coins to spend without direct user input. This can
shielded notes already. In the transparent coinbase case, only direct child transactions create a disconnect between the economic activity of users (who might be intending to
of the transparent coinbase would become invalid, and thus it would be possible to end up spend funds that they just received, creating "logical child" transactions), and their
in a situation where a logical child transaction (for example, a mining pool paying out on-chain transaction graph.
miners) persists in the block chain after its logical parent (the mining pool receiving a
block) disappears. > For example, a mining pool that successfully mines a block will receive a coinbase
> output, but their subsequent payout to miners might instead spend ZEC that they already
> had before the block was mined. If the mining pool pays out for block X, and then a
> reorg or rollback occurs that causes the transparent coinbase in block X to become
> invalid, the payout transaction might still be mined on the new chain, even though the
> funds that the miner was logically spending do not exist there.
By contrast, 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 shielded economic activity would be rolled back in addition to the shielded coinbase
output disappearing, ensuring that all logical child transactions are invalidated, not
just direct child transactions. Therefore, there is no reason to make shielded coinbase a
special case when the same behaviour already occurs in regular shielded notes.
Requiring that note commitments are valid when recovering using a fixed outgoing viewing 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 key implies that target addresses and values for all Sapling outputs within the coinbase