# Coinbase outputs as Transaction outputs **URL:** \ **Category:** Research\ **Created:** [June 16, 2020, 3:45pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441 "2020-06-16T15:45:33Z")\ **Posts on this page:** 19\ **Page:** 2
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [July 2, 2020, 2:53pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/21 "2020-07-02T14:53:01Z")
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)) ---
**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\ **Post date:** [July 2, 2020, 3:05pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/22 "2020-07-02T15:05:07Z")
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). ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [July 2, 2020, 3:05pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/23 "2020-07-02T15:05:55Z")
> [@Kurt](#): > > ensures that in typical reorgs (let’s say the non Nation State reorgs) only the user being double spent is affected [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. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [July 2, 2020, 3:08pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/24 "2020-07-02T15:08:39Z")
> [@antioch](#): > > The coinbase output is just a regular output now, so maybe it can be broadcast as part of a regular tx ahead of time. 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. ---
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [July 2, 2020, 3:20pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/25 "2020-07-02T15:20:22Z")
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. ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [July 2, 2020, 3:26pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/26 "2020-07-02T15:26:24Z")
> [@tromp](#): > > 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. 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. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [July 2, 2020, 3:32pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/27 "2020-07-02T15:32:08Z")
> [@antioch](#): > > Miner could replace an existing input with a smaller input removing those 60 grin though? That only works if said input belongs to the miner, so they know its blinding factor and can adjust the kernel appropriately. ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [July 3, 2020, 10:57am UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/28 "2020-07-03T10:57:28Z")
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). ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [July 3, 2020, 11:25am UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/29 "2020-07-03T11:25:59Z")
> [@antioch](#): > > So are we saying the primary (sole?) benefit of coinbase maturity is to minimize collateral damage incurred during a 51% attack? 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. ---
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [July 3, 2020, 11:42am UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/30 "2020-07-03T11:42:36Z")
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). ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [July 3, 2020, 11:49am UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/31 "2020-07-03T11:49:03Z")
> [@tromp](#): > > Both very rare events. 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? ---
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [July 3, 2020, 11:53am UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/32 "2020-07-03T11:53:08Z")
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. ---
**Author:** ![Paouky](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/paouky/32/513_2.png) [@Paouky](https://forum.grin.mw/u/Paouky)\ **Post date:** [July 3, 2020, 2:47pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/33 "2020-07-03T14:47:06Z")
I think the risk is very much bearable. In the event of a reorg, whatever the cause may be, the **absolute worst case** scenario is an unnecessary collateral damage of ~16 grin hours (1000 blocks). As time passes it becomes a very small share of overall network value. Besides, It’s more likely that a reorg would result in 0 damage that a maturity rule could have prevented. ---
**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\ **Post date:** [July 3, 2020, 3:01pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/34 "2020-07-03T15:01:37Z")
Might be worth pointing out that the 51% attacks on Grin might be a bit different than in say Bitcoin due to OWAS. If the attacker attacks by being online but avoids showing his blocks, then they can skip their own transaction in block inclusion and replace it with some other with which they move the money and thus protect themselves from a replay of tx. If they mine offline, they would need to find in which block their transaction was included and then subtract their transaction from the block transaction. It might be much simpler (though worse incentives) to just include their own transaction in the block and be done with it (which is a way worse attack, even worse than what the maturity rule protects against) ---
**Author:** ![johndavies24](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/johndavies24/32/1828_2.png) [@johndavies24](https://forum.grin.mw/u/johndavies24)\ **Post date:** [July 3, 2020, 5:29pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/35 "2020-07-03T17:29:08Z")
What about the normal, occasional, non-malicious reorgs? Are these ever more than 1 block? ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [July 3, 2020, 7:02pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/36 "2020-07-03T19:02:17Z")
You might see an occasional 2 block reorg, but MUCH fewer than 1 block ones. I don’t know of anyone keeping track of these. Probabilities go down exponentially. A 10-deep reorg would only result from an attack or a network partition. ---
**Author:** ![david](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/david/32/660_2.png) [@david](https://forum.grin.mw/u/david)\ **Post date:** [July 3, 2020, 7:52pm UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/37 "2020-07-03T19:52:00Z")
I will once again remind everyone of the bitcoin 0.7 =\> 0.8 upgrade as an example of why eliminating the coinbase maturity rule is risky. If there was no coinbase maturity rule, that accidental 24 block fork could’ve been much worse. That’s not to say that I am against eliminating coinbase outputs, but I think it’s important to understand the full implications. [https://freedom-to-tinker.com/2015/07/28/analyzing-the-2013-bitcoin-fork-centralized-decision-making-saved-the-day/](https://freedom-to-tinker.com/2015/07/28/analyzing-the-2013-bitcoin-fork-centralized-decision-making-saved-the-day/) ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [July 5, 2020, 9:21am UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/38 "2020-07-05T09:21:48Z")
I’m going to suggest a potentially unpopular approach - 1. Leave coinbase outputs and kernels in place for HF4 (final scheduled HF) 2. Leave the option open in the future to simplify these through a future (as yet undetermined) HF We know how coinbase outputs work and we know the validation rules for these are in place and correct. There is still some level of uncertainty around exactly how this proposed simplification affects miner incentives and double-spend incentives. I would hate to push a potentially contentious change out like this in our final scheduled hardfork and then subsequently discover we need to change the consensus rules back to something similar to what we have today (via an unscheduled hardfork). My understanding is we do have consensus in the community around supporting “duplicate outputs” and I propose we focus on investigating and ideally implementing the changes required to get this rule change in for HF4, leaving coinbase outputs as they currently stand today. There are some edge cases to think through around the interaction between spending duplicate outputs and coinbase maturity rules andI propose we tackle these with the assumption that coinbase outputs will remain. I’d love to hear arguments for why people _do_ think we should tackle “coinbase outputs as transaction outputs” _now_ in advance of HF4. ---
**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\ **Post date:** [July 5, 2020, 10:53am UTC](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441/39 "2020-07-05T10:53:43Z")
While I find the “no coinbase outputs” idea tempting, as you said, there are a few uncertainties right now unfortunately. I agree it shouldn’t be rushed and the approach you suggest makes more sense. Hopefully, we make a decision on how the hard forks will look like post HF4 and revisit it later. [Previous page](https://forum.grin.mw/t/coinbase-outputs-as-transaction-outputs/7441.md?page=1)