Chris Stewart [ARCHIVE] on Nostr: 📅 Original date posted:2017-07-12 📝 Original message:Hi Russell/ZmnSCPxj, I ...
📅 Original date posted:2017-07-12
📝 Original message: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.chris1234 at 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 at lists.linuxfoundation.org> wrote:
>
>>
>>
>> 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.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/92171a60/attachment.html>;
📝 Original message: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.chris1234 at 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 at lists.linuxfoundation.org> wrote:
>
>>
>>
>> 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.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/92171a60/attachment.html>;