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

Merge pull request #325 from str4d/zip-213-clarify-rationale 

ZIP 213: Clarify rationale for no shielded coinbase maturity
This commit is contained in:
str4d 2020-02-28 17:38:08 +13:00 committed by GitHub
parent 29e39136ca 9e45264d9d
commit 2575a8b805
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
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
proposed as a consensus rule in future.
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.
There is another reason for shielded coinbase maturity being unnecessary: shielded
coinbase outputs have the same effect on economic activity as regular shielded outputs.
When a transparent address receives a coin in some "parent" transaction and later spends
it, a tree of "direct child" transactions is created that all require the original parent
transaction to be valid. However, most wallets treat unspent transparent outputs as a
single "bucket of money", and select coins to spend without direct user input. This can
create a disconnect between the economic activity of users (who might be intending to
spend funds that they just received, creating "logical child" transactions), and their
on-chain transaction graph.
> 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
key implies that target addresses and values for all Sapling outputs within the coinbase