that fixes up to reorg of depth 5. i never said i liked the fix. bitcoin does it clean
No, whoever bought the main (non-uncle) reward from that small reorg is still S.O.L.
What does SOL mean? Yeah it seems half a fix. i guess they are happy with that, which is weird
Sore Out of Luck
There is a good related thread here from zcash discussing the coinbase maturity rule - https://github.com/zcash/zcash/issues/953
So from the various comment here ii seems like the “coinbase maturity rule” attempts to minimize damage incurred during a reorg for a couple of different reasons -
- large reorg with explicit double spend attack
- large reorg due to consensus bug
I think @tromp (and others) has convinced me that (1) is an issue regardless of coinbase maturity.
(2) is still interesting and is more in line with minimizing the side effects and unintentional double spends (or non-spends) of anything derived from any coinbase outputs that end up re-org’d out of existence. That said, coinbase maturity does not appear to be any silver bullet here either. A large re-org is going to massively damaging whatever happens.
On the “pros” side of things -
- simplicity - no coinbase as special case makes everything simpler
- also potentially simplifies logic around “duplicate outputs” if we decide to support these
- on-chain privacy as discussed above - every block gets an additional output/kernel aggregation (ignoring p2p tx analysis etc.)
- less data - ideal scenario would remove the features byte from inputs/outputs
I do wonder how much privacy gains we actually see in practice with this. On-chain is clear but tx relay and txpool/stempool is far less clear. Anybody relaying txs is very likely currently to see majority of outputs in a block in tx form and would be able to identify the subset of outputs that would contain the coinbase output. In many cases this is likely a single output.
There are probably things a miner can do to potentially hide coinbase outputs though.
It feels like there is room in there for improvements over time.
The coinbase output is just a regular output now, so maybe it can be broadcast as part of a regular tx ahead of time. The miner aggregating and adjusting at block construction time somehow. Just thinking out loud, have not thought this through fully.
There is no separate coinbase validation any more - the validation rule is rolled up into the full block validation. Output - inputs must result in 60 grin new supply when summing against the kernels.
The miner would want to validate that they are indeed the sole recipient of those 60 grin and the remaining txs sum to 0 as expected, taking fees into consideration.
As we have discussed in Keybase, only non-financially driven reorg attacks are essentially of the same effect regardless if coinbase maturity is implemented or not, as the attacker might want to erase a bunch of transactions in this case (think Nation state).
(1) is an issue regardless of coinbase maturity is essentially false, since double spends attacks historically only attacks a given transaction and keep included all the others. The reason being that the attacker has strictly no reason to screw up the blockchain to optimize his profit for his double spend.
If I wanted to insulate myself from this I would look at the number of confirmations, not of the output I received, but of all the outputs involved in the tx where I received my funds.
If you send me grin via
(A, B, C) -> D and I want some level of confidence that my funds are not going to subsequently disappear then I need to be aware of the current number of confirmations on
A, B, C (the source of my funds).
And @tromp has made a pretty good argument that you want to be doing this anyway when receiving large amounts of funds, regardless of coinbase maturity.
But yes - there is a difference in terms of “collateral damage”. With no coinbase maturity rule then all outputs descended from affected coinbase are subject to something analogous to a successful double spend attack within the reorg period.
With the coinbase maturity rule we have today the double spend fallout is limited to those outputs explicitly targeted for attack. At least that is my understanding.
Exactly, the coinbase maturity rule ensures that in typical reorgs (let’s say the non Nation State reorgs) only the user being double spent is effected (and also, for sure, the miners that mined the block(s) before are effected too as they lose their coinbase reward(s))
I was thinking about miners including it in a block before as well, but I couldn’t see it work out because you can’t know which miner is going to mine a block. I hope I’m wrong but the only way I was able to see it was if miners create multiple coinbase outputs (I think the code allows for this iirc). But this creates an anonymity set that is entirely separate (due to coinbase labels) so the users can’t benefit from the miner output and the miner can’t benefit from the users. It wouldn’t be possible to know which coinbase UTXO holds the grins though. So if a miner creates N coinbase outputs, they have created 1/N amount blinding set (it’s not really anonymity set because we know they have the same owner).
[EDIT] Ignore the comment below. The re-org history is completely up to the attacker and doesn’t allow for any spenders to change their mind unless they are colluding with the attacker.
It cannot ensure that. Anyone whose spending tx got reorged can opportunistically try to doublespend it, e.g. with a much higher fee to make it preferable over the old spend.
It cannot; as the balanced value requirement means that one of the inputs must supply the 60 Grin reward?! An unbalanced tx would not get relayed or make it onto mempools.
I don’t understand your thought here as I understand of it that the person being double spent can himself proceed to double spend in the process : “anyone whose spending tx got reorged can (…) try to double spend it”.
Historically attackers only attack one transaction, which makes perfect sense financially speaking to not harm unnecessarily the value of the blockchain.
Miner could replace an existing input with a smaller input removing those 60 grin though?
I guess that input needs to actually exist though.
Again, not fully thought through and likely does not work.
That only works if said input belongs to the miner, so they know its blinding factor and can adjust the kernel appropriately.
So are we saying the primary (sole?) benefit of coinbase maturity is to minimize collateral damage incurred during a 51% attack?
The attack may be focused on a single transaction but its all the other transactions, descended from subsequent coinbase being reorg’d away that coinbase maturity prevents?
(Edited last sentence to make it more clear - subsequent coinbase may be “undone” but maturity rule prevents this from affecting potentially many descendent txs).
Also the damage incurred in an accidental chain split due to a consensus bug and the resulting orphaning of one branch when fixed.
Both very rare events.
It does not prevent subsequent coinbase outputs being effected. All coinbase outputs inside the blocks being reorged are effected in the sense that they will not exist anymore once the reorg is completed. Coinbase maturity prevents coinbase outputs being spent too soon (100 blocks in bitcoin), which in turn prevents by definition child transactions being created from them too soon (100 blocks need to be appended to the blockchain before you can spend the coinbase output, in other words before you can do any child transaction from them).
I guess the question is are these rare enough to consider implementing what is going to be a potentially contentious change like this.
And if the incentives change by removing the maturity rule then are these potentially less rare?
They are rare but they happened on a non negligible number of mid-cap altcoins. And a consensus bug happened in bitcoin. Which essentially means that it’s not rare.