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

[Tier Nolan <tier.nolan@gmail.com>]

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

On Wed, May 24, 2017 at 6:32 PM, CryptAxe via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.
>

I think it is better to have it locked to a particular bitcoin height and
if it doesn't get included in that block, the sidechain miner can re-claim
it.

This could be taken to the extreme where the sidechain miner specifies a
particular parent of the claiming block.

The output should have a standard template, so miners can easily find bids.

The template on my previous post was:

IF
   <block height> <chain_id> <critical hash> OP_BRIBE_VERIFY
ELSE
  <public key> OP_CHECKSIG
ENDIF


If the output is spent by the miner for block <block height>, then the
sidechain miner has spent the funds.

Otherwise, the sidechain miner can use the else branch to reclaim his money.

The sidechain miner could also reclaim his money if the transaction was
included in an earlier block.  That would defeat the purpose of the bribe.
Bitcoin miners would have a (justified) incentive to not allow Bribe
outputs to be spent "early".

The bribe transactions could be created with no fees.  This would mean that
it is pointless for bitcoin miners to include them in blocks unless they
are claiming the outputs.

The relay rules would need to be modified to handle that.  Pools could
allow bids to be made directly, but that is less decentralized.

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*)
>

I don't think OP_BRIBE should care about info for the side chain.  The only
thing that is necessary is to indicate which sidechain.

You could just define the critical hash as

Hash( SideChainHeight | blinded h* )

For bribe payout release, it needs to give that particular miner an
advantage over all competitors, so their block forms the longest chain on
the sidechain (assuming their block is actually valid).

> 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.
>
The sidechain miner is saying that they will pay the bribe but only if
their block is included in the main chain.  The means that main chain
height is important.

They are paying for their block to be placed ahead of all competing blocks
for their chain.

It does mean that the side-chain can have at most the same number of blocks
as bitcoin.

>
> 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?
>

Well, it depends on the exact rules for OP_BRIBE.

The process I see is:

- sidechain miner submits a bribe transaction which pays to op bribe
- bitcoin miner includes that transaction in his block (or it could be
included in a previous block)
- bitcoin miner includes a claim transaction in his block

The claim transaction spends the outputs from the bribe transaction.  If
the claim transaction is block height locked, then it violates the rules
that previous soft-forks have followed.

For previous opcode changes there was a requirement that if a transaction
was accepted into block N, then it must also be acceptable in block (N+1).

The only (unavoidable) exceptions were double spends and coinbases outputs.

This means that the same protection should be added to your claim
transaction.

You could do it by requiring all outputs of the claim transaction to start
with

<100> CHECK_SEQUENCE_VERIFY DROP ...

This is only a few bytes extra at the start of the output script.

This means you can't use witness or P2SH output types for any of the
outputs, but that isn't that important.  The point of the transaction is to
make a payment.

An alternative would be to just add the rule as part of soft-fork
definition.  You could define a claim transaction as one that spends at
least one OP_BRIBE output and therefore, all its outputs have a 100 block
delay.

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