Re: [bitcoin-dev] Drivechain -- Request for Discussion

[CryptAxe <cryptaxe@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3797 bytes --]

Your assumptions of the bribe process are indeed correct you seem to
have a pretty good handle on all of that.

Hopefully I can clear up a few things. BMM among other things is still a
work in progress so you'll have to wait a
bit longer before any reorg code is on github. The "ratchet" system on
github right now just has the block hash
part of the critical hash script. The completed version needs to check
the sidechain number (ID) and the sidechain
block number in the script. Also the block number can only change by +1
or -1, so when a new h* is added to the
queue it must be compared to the most recent h* in the queue.
std::abs(queue.back().nHeight - ToAdd.nHeight) must equal 1.

Here's what the script looks like on github:
Note that the h* is just a block hash.

script << OP_RETURN << ToByteVector(h*);

Here's what I'm testing right now as I'm working on BMM:

script << OP_RETURN << CScriptNum::serialize(nSidechain) <<
CScriptNum(nSidechainHeight) << ToByteVector(sidechain blinded block
hash h*)

One other thing I want to make sure is clear enough is that the block
number in the critical hash script is
a sidechain block number, not a mainchain block number. That might mess
up the new format you have
suggested for bribes. And the reason a sidechain miner would want to
refund their bribe is if the h* doesn't
end up in a coinbase after a number of blocks, making their blinded
block on the sidechain invalid as tx's
will be spent in other blocks that do get their h* in a coinbase.

We were thinking about making bribe outputs have a maturity period like
generated coins. You
think that they should be locked for >100 blocks by having OP_BRIBE also
check the lock time?

I like all of your suggestions so far, thank you for taking a look!


On 05/24/2017 03:05 AM, Tier Nolan via bitcoin-dev wrote:
> On Wed, May 24, 2017 at 9:50 AM, Tier Nolan <tier.nolan@gmail.com
> <mailto:tier.nolan@gmail.com>> wrote:
>
>     OP_BRIBE_VERIFY could then operate as follows
>
>     <block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY
>
>     This causes the script to fail if
>       <block height> does not match the block height, or
>       <critical hash> is not the hash for the sidechain with
>     <sidechain_id>, or
>       there is no hash for that sidechain in the block's coinbase
>
>
> I was thinking more on the process for these transactions.
>
> I assume that the process is
>
> - sidechain miner broadcasts transaction with OP_BRIBE output
> - this transaction ends up in the memory pool of miners
> - Miners add the transaction to their next block
> - Miners add a transaction which spends the output to one of their own
> addresses
>
> I think you need an additional rule that OP_BRIBE checks fails unless
> the output is locked 100 or more blocks.
>
> The output script would end up something like
>
> IF
>    <block height> <chain_id> <critical hash> OP_BRIBE_VERIFY
> ELSE
>   <public key> OP_CHECKSIG
> ENDIF
>
> This output acts like "anyone can spend" for the one block height. 
> Otherwise, only the sidechain miner can spend the output.
>
> This allows the sidechain miner to reclaim their coins if the
> transaction ends up in a different block.
>
> OP_BRIBE_VERIFY would have an additional rule
>
> The script to fails if
>   one or more of the transaction outputs start with something other
> than the template
>   <block height> does not match the block height, or
>   <critical hash> is not the hash for the sidechain with
> <sidechain_id>, or
>   there is no hash for that sidechain in the block's coinbase
>
> The template is
>   <100> OP_CHECKSEQUENCE_VERIFY
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Type: text/html, Size: 7553 bytes --]