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

<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