Coinbase outputs as Transaction outputs

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 -

  1. large reorg with explicit double spend attack
  2. 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.

3 Likes