{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-06-28\n📝 Original message:On Wed, Jun 28, 2017 at 12:37 AM, Chris Stewart via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e A new block rule is added which requires that the miner's coinbase reward be\n\u003e at index 0 in the coinbase transaction's output vector.\n\nThis is an absurd restriction-- I hope it was not your intent to\ndirectly ban P2Pool and probably any other form of decentralized or\nless centralized mining pooling... but thats what doing that does.\n\n\u003e It also fixes the witness commitment output to be at index 1 of the coinbase transaction's output vector.\n\nThis removes important flexibility that was intentionally preserved.\nWhat happens when an additional commitment is needed for bitcoin?\nmust some sidechain be irreparably destroyed? looks like it in  your\nproposal.\n\n\u003e For instance, the mimblewimble sidechain could correspond to index 2 of the vector outputs on the coinbase transaction.\n\nAnd what happens if index 1 isn't present? if index 35 is used must\nthere be 34 dummy outputs?\n\n\u003e This op code looks into the coinbase transaction's output vector at the given index (which is derived from the sidechain id) and checks to see if the hash in the block matches the hash inside of the BRIBEVERIFY progra\n\nThis is not monotone/reorg safe. It means that the output coins (if\nany) are not equivalently fungible with other bitcoins (for, e.g. 100\nblocks) because if there is a reorg this transaction cannot be\nrestored to the chain.  It's also impure and not compatible with\ncaching, which would be unfortunate and slow block propagation."}