Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2017-06-28 📝 Original message:On Wed, Jun 28, 2017 at ...
📅 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.
📝 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.