mirror of https://github.com/zcash/zips.git
Merge pull request #325 from str4d/zip-213-clarify-rationale
ZIP 213: Clarify rationale for no shielded coinbase maturity
This commit is contained in:
commit
2575a8b805
35
zip-0213.rst
35
zip-0213.rst
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue