Hi Russell/ZmnSCPxj,

I think you guys are right. The only problem I can see with it is replaceability of the bribe transaction. If the 'Bribe' is the fee on the transaction it isn't clear to me what the best way to replace/remove it is.

If we have the amount in the output (instead of the fee) we can construct a contract like this

OP_IF <id> <hash> OP_BV OP_ELSE OP_DUP OP_HASH160 <pubkey hash> OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF

That way, if the miner does *not* include your bribe, he is *still* incentived to include your redemption.

If we decide to only an OP_RETURN output, we can replace the 'bribe' transaction with a transaction that double spends the prevout. Thus if your 'bribe' transaction is not included in a block, a miner can still include your double spend transaction to refund yourself (and a miner gets to collect his normal mining fee). 

I'm not 100% sure if there are mempool policies that would reject this double spend tx or not -- but I guess this is an implementation detail not a high level design one.

Also if there is not a commitment in the coinbase transaction it may be harder to search for drivechain commitments. I've been floating around the idea of a 'drivechain commitment tx' so we could easily see where all of the voting is happening for withdrawal transactions -- but that is very much up in the air.

-Chris

On Wed, Jul 12, 2017 at 8:39 AM, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@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.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev