Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2017-07-12 📝 Original message:On Wed, Jul 12, 2017 at ...

📅 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>;