📅 Original date posted:2017-07-12
📝 Original message:On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
In any case, let me propose actual improvements to the OP_BRIBEVERIFY
> proposal:
>
> 1. Remove the necessity of coinbase commitments. The miner commits to
> the sidechain_id and h* in the transaction that pays the OP_BRIBEVERIFY
> anyway. That way the h* commitment occurs only once in the block, in the
> transaction that does the OP_BRIBEVERIFY. In addition, there is no need to
> impose particular ordering on the coinbase outputs, which would be
> problematic as pointed out by others, for example if the miner is
> interested only in merge mining for sidechain id #35 and nobody else.
>
> 2. When verifying a block, keep a set of sidechain ID's. When processing
> a transaction in that block with OP_BRIBEVERIFY, check if the sidechain ID
> is in that set. If not in that set, add it to that set and continue script
> processing. If already in the set, fail the script processing. This
> ensures that at most one OP_BRIBEVERIFY exists for each sidechain_id in a
> mainchain block.
>
At this point can we eliminate the need to use the scripting system at all
and just use a special, currently non-standard, OP_RETURN output to hold
the sidechain_id and h* instead? We can soft fork in a rule that at most
one such output can appear in a block per sidechain_id.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/d3ad9afc/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 18:03:52
in reply to nevent1q…u0n3
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 18:03:52Event JSON
{
"id": "950ccf5c3332d173f55609ca3a454c8bfdc3131ab83be04506839bc3087b66b7",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686161032,
"kind": 1,
"tags": [
[
"e",
"52b451de2ab6d599e8057dc09a8d1c72b1915752195eef8652787bc553d99caf",
"",
"root"
],
[
"e",
"b6ff2d11770ef3af48bfa54efe50d9599f7efaf98bcd5efca43ccd5575f66c1f",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2017-07-12\n📝 Original message:On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\nIn any case, let me propose actual improvements to the OP_BRIBEVERIFY\n\u003e proposal:\n\u003e\n\u003e 1. Remove the necessity of coinbase commitments. The miner commits to\n\u003e the sidechain_id and h* in the transaction that pays the OP_BRIBEVERIFY\n\u003e anyway. That way the h* commitment occurs only once in the block, in the\n\u003e transaction that does the OP_BRIBEVERIFY. In addition, there is no need to\n\u003e impose particular ordering on the coinbase outputs, which would be\n\u003e problematic as pointed out by others, for example if the miner is\n\u003e interested only in merge mining for sidechain id #35 and nobody else.\n\u003e\n\u003e 2. When verifying a block, keep a set of sidechain ID's. When processing\n\u003e a transaction in that block with OP_BRIBEVERIFY, check if the sidechain ID\n\u003e is in that set. If not in that set, add it to that set and continue script\n\u003e processing. If already in the set, fail the script processing. This\n\u003e ensures that at most one OP_BRIBEVERIFY exists for each sidechain_id in a\n\u003e mainchain block.\n\u003e\n\nAt this point can we eliminate the need to use the scripting system at all\nand just use a special, currently non-standard, OP_RETURN output to hold\nthe sidechain_id and h* instead? We can soft fork in a rule that at most\none such output can appear in a block per sidechain_id.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/d3ad9afc/attachment.html\u003e",
"sig": "dbc35aa3e41f2d2bffbbcf9898090a0ea62e0a451402de5badf0bf484e913a468188b58769efff2a73596bc2638e16a3aa7797cd9f196eb61c216568707e6bae"
}