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 Wed, May 24, 2017 at 9:50 AM, Tier Nolan <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