📅 Original date posted:2017-06-28
📝 Original message:On Wed, Jun 28, 2017 at 12:37 AM, Chris Stewart via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> A new block rule is added which requires that the miner's coinbase reward be
> at index 0 in the coinbase transaction's output vector.
This is an absurd restriction-- I hope it was not your intent to
directly ban P2Pool and probably any other form of decentralized or
less centralized mining pooling... but thats what doing that does.
> It also fixes the witness commitment output to be at index 1 of the coinbase transaction's output vector.
This removes important flexibility that was intentionally preserved.
What happens when an additional commitment is needed for bitcoin?
must some sidechain be irreparably destroyed? looks like it in your
proposal.
> For instance, the mimblewimble sidechain could correspond to index 2 of the vector outputs on the coinbase transaction.
And what happens if index 1 isn't present? if index 35 is used must
there be 34 dummy outputs?
> 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
This is not monotone/reorg safe. It means that the output coins (if
any) are not equivalently fungible with other bitcoins (for, e.g. 100
blocks) because if there is a reorg this transaction cannot be
restored to the chain. It's also impure and not compatible with
caching, which would be unfortunate and slow block propagation.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 18:03:39
in reply to nevent1q…7qnd
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 18:03:39Event JSON
{
"id": "d80860bb4f219c3ba01278571184a2cfbb210760a42d09a73066bc7782ced91b",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686161019,
"kind": 1,
"tags": [
[
"e",
"ceb90cc04617646a4ed9dd447660214398effadc094de82e24452613b40f4a5e",
"",
"root"
],
[
"e",
"81decd8e4d34c8e96adadf46597bcc5bf267a862265a4cba1494aa307a4ce78a",
"",
"reply"
],
[
"p",
"e3e3813ca5b2f45117ae42a2a1c99f5c6bd172c115acc2538066aad916544817"
]
],
"content": "📅 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.",
"sig": "3f44835fcd7b69a8538d7c0055c0689524cef65fb7d0ee903d5fab2b10172abee1322eeeddfb2ecc70cbbebc108efd4163bb5f9953c6fdface364fe4bf90744a"
}