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. On Wed, Jul 12, 2017 at 1:00 PM, Chris Stewart <stewart.chris1...@gmail.com> wrote: > 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 >> >> >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
