public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
@ 2017-06-28  0:37 Chris Stewart
  2017-06-28  4:07 ` Gregory Maxwell
                   ` (2 more replies)
  0 siblings, 3 replies; 25+ messages in thread
From: Chris Stewart @ 2017-06-28  0:37 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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

<pre>
  BIP: <BIP number>
  Layer: Consensus (Soft fork)
  Title: OP_BRIBEVERIFY
  Author: Chris Stewart <chris@suredbits•com>
  Status: Draft
  Type: Standards Track
  Created: 2017-06-27
</pre>


==Abstract==

This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin
scripting system that allows for a user to bribe a miner to include a hash
in the coinbase transaction's output.


==Summary==

BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
critical hash is included at the given vout index in the coinbase
transaction
the script evaluates to true. Otherwise, the script will fail.

This allows sidechains to be merged mined against
bitcoin without burdening bitcoin miners with extra resource requirements.

==Motivation==

The current political climate of bitcoin is extremely contentious. Many
community members
have different visions of what bitcoin is. This op code is meant to
enable [http://www.truthcoin.info/blog/blind-merged-mining/ Blind Merge
Mining].
This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains miners
can
bribe bitcoin miners to to include their block hash in the bitcoin
blockchain. If their block
is included in the coinbase transaction's vout, it is assumed that block is
a mined block on the sidechain.

This will allow various factions of the community to realize their vision
on their own separate
blockchain that is interoperable with the bitcoin blockchain. This allows
those factions to use
bitcoin as a 'reserve currency' for their own network.


===Commitment Structure===

A new block rule is added which requires that the miner's coinbase reward
be at index 0 in the coinbase transaction's output vector.

It also fixes the witness commitment output to be at index 1 of the
coinbase transaction's output vector.

This is needed so we can reliably tell what vout corresponds to what
drivechain. For instance, the mimblewimble sidechain
could correspond to index 2 of the vector outputs on the coinbase
transaction.

The commitment is recorded in a <code>scriptPubKey</code> of the coinbase
transaction. It must be at least 34 bytes in size
   1-byte - OP_RETURN (0x6a)
   1-byte - Push the following 32 bytes (0x20)
  32-byte - block hash

the 35th byte and onward have no consensus meaning.

===OP_BRIBEVERIFY op code===

This op code reads two arguments from the stack. The stack top is expected
to be a sidechain id for which this user attempting to blind merge mine for.
The next element on the stack is expected to be a block hash. This op code
looks into the coinbase transaction's output vector at the given index
(which is derived from the sidechain id) and checks
to see if the hash in the block matches the hash inside of the BRIBEVERIFY
program. If the hashes match, the OP_BRIBEVERIFY acts as an OP_NOP. If the
comparison between the two hashes fail, the script fails.

===BRIBEVERIFY program===

A standard BRIBEVERIFY program has the format:
  1-byte - Push the following 32 bytes (0x20)
 32-byte - block hash
  1 byte - Push operation? (needed if number can't be encoded as OP_0 -
OP_16)
  1 byte - sidechain id
  1 byte - OP_BRIBEVERIFY op code

==Detailed Specification==

Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.


 case OP_NOP4:
 {
    //format: block_hash sidechain_id OP_BRIBEVERIFY
    if (!(flags & SCRIPT_VERIFY_BRIBEVERIFY)) {
        // not enabled; treat as a NOP4
        if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
            return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
        }
        break;
    }

    if (stack.size() < 2)
        return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);

    const CScriptNum scriptNumSidechainId(stacktop(-1),fRequireMinimal);
    uint8_t nSidechainId;
    if (!checker.CheckSidechainId(scriptNumSidechainId,nSidechainId)) {
        return set_error(serror, SCRIPT_ERR_UNKNOWN_SIDECHAIN);
    }

    // Check block hash
    bool fHashCritical =
checker.CheckCriticalHash(stacktop(-2),nSidechainId);
    if (!fHashCritical) {
        return set_error(serror, SCRIPT_ERR_UNSATISFIED_BRIBE);
    }
    break;
 }



https://github.com/Christewart/bitcoin/blob/94b6f33f2278c42d4d8758a3c8ffe2078e4ec933/src/script/interpreter.cpp#L427

https://github.com/drivechain-project/bitcoin/pull/13

==Deployment==

TODO

==Credits==

Credit to Paul Sztorc for the original idea of Blind Merge Mined sidechains.

Credit to CryptAxe for writing the foundational layer of software for
drivechains so I could implement OP_BRIBEVERIFY.


==References==

Blind Merge Mined Sidechains -
http://www.truthcoin.info/blog/blind-merged-mining/

Mailing list discussion -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014408.html

==Copyright==

This document is placed in the public domain.

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

• * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
    2017-06-28  0:37 [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains Chris Stewart
  @ 2017-06-28  4:07 ` Gregory Maxwell
    2017-06-28 16:35   ` Paul Sztorc
    2017-06-28  5:20 ` Luke Dashjr
    2017-06-28  8:26 ` ZmnSCPxj
    2 siblings, 1 reply; 25+ messages in thread
  From: Gregory Maxwell @ 2017-06-28  4:07 UTC (permalink / raw)
    To: Chris Stewart; +Cc: Bitcoin Protocol Discussion
  
  On Wed, Jun 28, 2017 at 12:37 AM, Chris Stewart via bitcoin-dev
  <bitcoin-dev@lists•linuxfoundation.org> wrote:
  > A new block rule is added which requires that the miner's coinbase reward be
  > at index 0 in the coinbase transaction's output vector.
  
  This is an absurd restriction-- I hope it was not your intent to
  directly ban P2Pool and probably any other form of decentralized or
  less centralized mining pooling... but thats what doing that does.
  
  > It also fixes the witness commitment output to be at index 1 of the coinbase transaction's output vector.
  
  This removes important flexibility that was intentionally preserved.
  What happens when an additional commitment is needed for bitcoin?
  must some sidechain be irreparably destroyed? looks like it in  your
  proposal.
  
  > For instance, the mimblewimble sidechain could correspond to index 2 of the vector outputs on the coinbase transaction.
  
  And what happens if index 1 isn't present? if index 35 is used must
  there be 34 dummy outputs?
  
  > This op code looks into the coinbase transaction's output vector at the given index (which is derived from the sidechain id) and checks to see if the hash in the block matches the hash inside of the BRIBEVERIFY progra
  
  This is not monotone/reorg safe. It means that the output coins (if
  any) are not equivalently fungible with other bitcoins (for, e.g. 100
  blocks) because if there is a reorg this transaction cannot be
  restored to the chain.  It's also impure and not compatible with
  caching, which would be unfortunate and slow block propagation.
  
  
  ^ permalink raw reply	[flat|nested] 25+ messages in thread

• • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
      2017-06-28  4:07 ` Gregory Maxwell
    @ 2017-06-28 16:35   ` Paul Sztorc
      0 siblings, 0 replies; 25+ messages in thread
    From: Paul Sztorc @ 2017-06-28 16:35 UTC (permalink / raw)
      To: Gregory Maxwell, Chris Stewart; +Cc: Bitcoin Protocol Discussion
    
    Chris/Greg,
    
    For pending withdrawals (side-to-main transfers), all of the data is
    stored in a teeny tiny extension block which contains all the drivechain
    data (which we called "MinerDB"). And miners were supposed to commit to
    this and put it in the coinbase in some locate-able place (for example,
    index 1).
    
    I had assumed that this would go the same for BMM, since it is all
    drivechain-themed. Thus, all drivechains, and all drivechain-stuff (BMM
    included), would claim one output index.
    
    Moreover, while DC claims an output "slot", the claim doesn't need to be
    permanent...if the BTC-value of the relevant output is not equal to
    zero, the BMM code could just ignore it. The sidechains would each
    assume that no sidechain block was merged-mined in this period. And DC
    would assume that no forward progress was made on any side-to-main
    transfers (ie, that everyone "abstained").
    
    Perhaps that addresses Greg's third, first, and second concerns.
    
    I am having some trouble understanding concern #4. I think you mean to
    say that the output coins of a transaction which is encumbered by OP
    BribeVerify are different from other coins. Indeed they are, and coins
    locked by OP BribeVerify cannot be moved until their associated
    sidechain header ("h*") is ~100 blocks deep in the sidechain (hence the
    earlier conversation about the "ratchet", which attempts to measure this).
    
    The timeline that CryptAxe and I discussed, as I last remember it, is that:
    0. (setup) The sidechain node is run by a briber, and this briber
    constructs a sidechain block paying himself all the fees. These fees
    total q=4 BTC.
    1. Negotiations happen out of bound, between Briber and all miners.
    (still setting up) Each new transaction the Briber makes, he chooses a
    completely new h* (which is trivial for him to do by incrementing a
    nonce/anything), and he may as well also fund each of these txns with
    the same unspent output (owned by him). This prevents a miner from
    annoying the Briber by including many ultimately-invalid transactions.
    2. Miner1 includes h* in the coinbase of today's block thus BMMing a
    sidechain block today, he also includes the transaction he just
    negotiated with the Briber (call it, "tx1"). This tx1 is one where
    Briber pays z=(q-0.001) to an op_bribe script that will eventually pay z
    BTC to Bitcoin address M owned by "miner1".
    3. After ~123 blocks, the ratchet (on mainchain) indicates that the
    sidechain headers have advanced sequentially by x=100 places. This
    allows miner1 to spend from tx1 to address M.
    3. OR, after ~250 blocks, the second timing threshold is reached*, and
    the Briber can spend from his script back to an address he controls
    (also predefined in steps 1 and 2).
    
    
    *This is the dual-threshold time-locking technique that the LN uses to
    prove a negative.
    
    The second timelock setup is required because it is possible that miner
    will earnestly BMM a sidechain block, but then reorg such that this
    block is orphaned out of the longest (side)chain. In this case, the
    Briber doesn't get paid his tx-fees, so he is entitled to a refund.
    
    
    So, maybe this BIP will need to be edited a little. : ) Nonetheless, I'm
    glad Chris is taking the initiative and doing this work. And I'm sorry
    if the documentation has shifted too much. At the bottom of the spec
    blog post there are some notes, but they probably aren't very helpful.
    
    
    
    On 6/28/2017 12:07 AM, Gregory Maxwell via bitcoin-dev wrote:
    > On Wed, Jun 28, 2017 at 12:37 AM, Chris Stewart via bitcoin-dev
    > <bitcoin-dev@lists•linuxfoundation.org> wrote:
    >> A new block rule is added which requires that the miner's coinbase reward be
    >> at index 0 in the coinbase transaction's output vector.
    > 
    > This is an absurd restriction-- I hope it was not your intent to
    > directly ban P2Pool and probably any other form of decentralized or
    > less centralized mining pooling... but thats what doing that does.
    > 
    >> It also fixes the witness commitment output to be at index 1 of the coinbase transaction's output vector.
    > 
    > This removes important flexibility that was intentionally preserved.
    > What happens when an additional commitment is needed for bitcoin?
    > must some sidechain be irreparably destroyed? looks like it in  your
    > proposal.
    > 
    >> For instance, the mimblewimble sidechain could correspond to index 2 of the vector outputs on the coinbase transaction.
    > 
    > And what happens if index 1 isn't present? if index 35 is used must
    > there be 34 dummy outputs?
    > 
    >> This op code looks into the coinbase transaction's output vector at the given index (which is derived from the sidechain id) and checks to see if the hash in the block matches the hash inside of the BRIBEVERIFY progra
    > 
    > This is not monotone/reorg safe. It means that the output coins (if
    > any) are not equivalently fungible with other bitcoins (for, e.g. 100
    > blocks) because if there is a reorg this transaction cannot be
    > restored to the chain.  It's also impure and not compatible with
    > caching, which would be unfortunate and slow block propagation.
    > _______________________________________________
    > bitcoin-dev mailing list
    > bitcoin-dev@lists•linuxfoundation.org
    > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    > 
    
    
    ^ permalink raw reply	[flat|nested] 25+ messages in thread

• * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
    2017-06-28  0:37 [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains Chris Stewart
    2017-06-28  4:07 ` Gregory Maxwell
  @ 2017-06-28  5:20 ` Luke Dashjr
    2017-06-28  5:28   ` Adam Back
    2017-06-28 16:43   ` Paul Sztorc
    2017-06-28  8:26 ` ZmnSCPxj
    2 siblings, 2 replies; 25+ messages in thread
  From: Luke Dashjr @ 2017-06-28  5:20 UTC (permalink / raw)
    To: bitcoin-dev, Chris Stewart
  
  On Wednesday 28 June 2017 12:37:13 AM Chris Stewart via bitcoin-dev wrote:
  > BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
  > critical hash is included at the given vout index in the coinbase
  > transaction
  > the script evaluates to true. Otherwise, the script will fail.
  > 
  > This allows sidechains to be merged mined against
  > bitcoin without burdening bitcoin miners with extra resource requirements.
  
  I don't see how. It seems like the logical outcome from this is "whoever pays 
  the most gets the next sidechain block"... That's not particularly useful for 
  merge mining.
  
  > This enables sidechains in Bitcoin.
  
  There are different kinds of sidechains...
  
  Federated peg: this already works on Bitcoin.
  SPV/SNARK peg: this isn't enabled by your BIP.
  Drivechains: this isn't enabled by your BIP.
  
  How do you say this enables any kind of sidechain?
  
  > A new block rule is added which requires that the miner's coinbase reward
  > be at index 0 in the coinbase transaction's output vector.
  > 
  > It also fixes the witness commitment output to be at index 1 of the
  > coinbase transaction's output vector.
  
  This is unacceptable, for reasons Greg already pointed out.
  
  > This document is placed in the public domain.
  
  Note that this is not acceptable for BIPs anymore.
  
  https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#BIP_licensing
  
  
  ^ permalink raw reply	[flat|nested] 25+ messages in thread

• • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
      2017-06-28  5:20 ` Luke Dashjr
    @ 2017-06-28  5:28   ` Adam Back
      2017-06-28 16:43   ` Paul Sztorc
      1 sibling, 0 replies; 25+ messages in thread
    From: Adam Back @ 2017-06-28  5:28 UTC (permalink / raw)
      To: Luke Dashjr; +Cc: Bitcoin Dev
    
    On 27 June 2017 at 22:20, Luke Dashjr via bitcoin-dev
    <bitcoin-dev@lists•linuxfoundation.org> wrote:
    > On Wednesday 28 June 2017 12:37:13 AM Chris Stewart via bitcoin-dev wrote:
    >> BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
    >> critical hash is included at the given vout index in the coinbase
    >> transaction the script evaluates to true. Otherwise, the script will fail.
    >>
    >> This allows sidechains to be merged mined against
    >> bitcoin without burdening bitcoin miners with extra resource requirements.
    >
    > I don't see how. It seems like the logical outcome from this is "whoever pays
    > the most gets the next sidechain block"... That's not particularly useful for
    > merge mining.
    
    Maybe that's phrased badly but the point of the "blind merge mining"
    is just that the sidechain fees are paid in main chain bitcoin (rather
    than in sidechain bitcoin).
    
    That means that a miner who solo mines the main chain could still mine
    the sidechain by requesting a block-proposal from a trusted sidechain
    fullnode.  The sidechain fullnode would actually pay the mainchain
    fee, and pay itself the sidechain fees as part of the side-chain
    block-proposal.
    
    This was viewed as less centralising than forcing miners to directly
    process sidechain blocks, which could in principle be bandwidth and
    CPU expensive to process, construct and validate.
    
    Adam
    
    
    ^ permalink raw reply	[flat|nested] 25+ messages in thread

  • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
      2017-06-28  5:20 ` Luke Dashjr
      2017-06-28  5:28   ` Adam Back
    @ 2017-06-28 16:43   ` Paul Sztorc
      1 sibling, 0 replies; 25+ messages in thread
    From: Paul Sztorc @ 2017-06-28 16:43 UTC (permalink / raw)
      To: Luke Dashjr, bitcoin-dev, Chris Stewart
    
    
    Hi Luke,
    
    On 6/28/2017 1:20 AM, Luke Dashjr via bitcoin-dev wrote:
    > On Wednesday 28 June 2017 12:37:13 AM Chris Stewart via bitcoin-dev wrote:
    >> BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
    >> critical hash is included at the given vout index in the coinbase
    >> transaction
    >> the script evaluates to true. Otherwise, the script will fail.
    >>
    >> This allows sidechains to be merged mined against
    >> bitcoin without burdening bitcoin miners with extra resource requirements.
    > 
    > I don't see how. It seems like the logical outcome from this is "whoever pays 
    > the most gets the next sidechain block"... That's not particularly useful for 
    > merge mining.
    
    This is one of the assumptions which BMM exploits, see #4 of:
    http://www.truthcoin.info/blog/blind-merged-mining/#focus
    
    The idea is that this is a safe assumption, because it is already the
    case today. If we assume that miners revenue-maximize, and further that
    the "bidder" frames his payments in tx-fees, then a willing buyer can
    control the next block by simply filling it with high tx-fee spam.
    Anyone who is willing to pay the most can already 'get' the next
    mainchain block (only, indirectly).
    
    > 
    >> This enables sidechains in Bitcoin.
    > 
    > There are different kinds of sidechains...
    > 
    > Federated peg: this already works on Bitcoin.
    > SPV/SNARK peg: this isn't enabled by your BIP.
    > Drivechains: this isn't enabled by your BIP.
    > 
    > How do you say this enables any kind of sidechain?
    
    Yes, it is unclear, but Chris' email is specific to blind merged mining
    (BMM), which is kind of a "sidechains +". So this does not directly
    enable any sidechains. Instead, it enables the "+" part.
    
    --Paul
    
    
    ^ permalink raw reply	[flat|nested] 25+ messages in thread

• * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
    2017-06-28  0:37 [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains Chris Stewart
    2017-06-28  4:07 ` Gregory Maxwell
    2017-06-28  5:20 ` Luke Dashjr
  @ 2017-06-28  8:26 ` ZmnSCPxj
    2017-06-28 22:20   ` Paul Sztorc
    2 siblings, 1 reply; 25+ messages in thread
  From: ZmnSCPxj @ 2017-06-28  8:26 UTC (permalink / raw)
    To: Chris Stewart; +Cc: Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 7270 bytes --]
  
  Good morning.
  I still do not see what this does that cannot be done by:
  OP_RETURN <sidechain-id> <sidechain-block-id>
  A transaction with such an output would allow sidechain-miners to bribe mainchain-miners by paying a transaction fee if the transaction containing this OP_RETURN is included in a block and committed to by a mainchain-miner in the Merkle tree root.
  It would not require a softfork.
  --
  I have an alternate proposal that sidechains and altcoins that want to do "blinded" merge mining can use without a softfork:
  1. Encode a block header as a simple cons-pair, with the head as the block and the tail as the parent cons-pair.
  1.1. This can be encoded as a 32-byte hash of the block including its header, and the 32-byte hash of the parent cons-pair.
  1.2. This is now the actual "chain" in the sidecoin/altcoin blockchain.
  2. When a sidechain-node wants to know the consensus, it downloads mainchain-blocks and looks for OP_RETURN's.
  2.1. Starting with its genesis cons-pair hash (equivalent to the empty list) as the current cons-pair, it scans each OP_RETURN transaction.
  2.1.1. If an OP_RETURN is 64-byte and has the parent cons-pair equal to the current cons-pair, look for the side block indicated and confirm its correctness. If correct, update the current cons-pair for the hash of the OP_RETURN data.
  2.2. When reaching the latest mainchain block, the current cons-pair is now the sidecoin/altcoin latest block.
  2.3. Note that if multiple OP_RETURN in a block match the current cons-pair, the first one is considered the correct chain. This property means that the sidechain/altchain can only have a chainsplit if the mainchain has a chainsplit.
  3. When a sidechain-miner wants to create a side-block, it generates a new cons-pair and creates an OP_RETURN transaction for it, paying a mainchain-miner to include it in the next mainchain-block.
  3.1. The sidechain-miner risks that its competitors will outbid it and get its OP_RETURN earlier in a mainchain-block (or earlier in the order of transactions). It can mitigate this risk by updating itself to become a mainchain-miner, it can then keep its OP_RETURN transaction private and put it earlier in the block, ensuring it will "win" the sidechain-consensus if it wins the mainchain-consensus.
  Regards,
  ZmnSCPxj
  -------- Original Message --------
  Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
  Local Time: June 28, 2017 8:37 AM
  UTC Time: June 28, 2017 12:37 AM
  From: bitcoin-dev@lists•linuxfoundation.org
  To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
  <pre>
  BIP: <BIP number>
  Layer: Consensus (Soft fork)
  Title: OP_BRIBEVERIFY
  Author: Chris Stewart <chris@suredbits•com>
  Status: Draft
  Type: Standards Track
  Created: 2017-06-27
  </pre>
  ==Abstract==
  This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin
  scripting system that allows for a user to bribe a miner to include a hash
  in the coinbase transaction's output.
  ==Summary==
  BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
  critical hash is included at the given vout index in the coinbase transaction
  the script evaluates to true. Otherwise, the script will fail.
  This allows sidechains to be merged mined against
  bitcoin without burdening bitcoin miners with extra resource requirements.
  ==Motivation==
  The current political climate of bitcoin is extremely contentious. Many community members
  have different visions of what bitcoin is. This op code is meant to
  enable [http://www.truthcoin.info/blog/blind-merged-mining/ Blind Merge Mining].
  This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains miners can
  bribe bitcoin miners to to include their block hash in the bitcoin blockchain. If their block
  is included in the coinbase transaction's vout, it is assumed that block is a mined block on the sidechain.
  This will allow various factions of the community to realize their vision on their own separate
  blockchain that is interoperable with the bitcoin blockchain. This allows those factions to use
  bitcoin as a 'reserve currency' for their own network.
  ===Commitment Structure===
  A new block rule is added which requires that the miner's coinbase reward be at index 0 in the coinbase transaction's output vector.
  It also fixes the witness commitment output to be at index 1 of the coinbase transaction's output vector.
  This is needed so we can reliably tell what vout corresponds to what drivechain. For instance, the mimblewimble sidechain
  could correspond to index 2 of the vector outputs on the coinbase transaction.
  The commitment is recorded in a <code>scriptPubKey</code> of the coinbase transaction. It must be at least 34 bytes in size
  1-byte - OP_RETURN (0x6a)
  1-byte - Push the following 32 bytes (0x20)
  32-byte - block hash
  the 35th byte and onward have no consensus meaning.
  ===OP_BRIBEVERIFY op code===
  This op code reads two arguments from the stack. The stack top is expected to be a sidechain id for which this user attempting to blind merge mine for.
  The next element on the stack is expected to be a block hash. This op code looks into the coinbase transaction's output vector at the given index (which is derived from the sidechain id) and checks
  to see if the hash in the block matches the hash inside of the BRIBEVERIFY program. If the hashes match, the OP_BRIBEVERIFY acts as an OP_NOP. If the
  comparison between the two hashes fail, the script fails.
  ===BRIBEVERIFY program===
  A standard BRIBEVERIFY program has the format:
  1-byte - Push the following 32 bytes (0x20)
  32-byte - block hash
  1 byte - Push operation? (needed if number can't be encoded as OP_0 - OP_16)
  1 byte - sidechain id
  1 byte - OP_BRIBEVERIFY op code
  ==Detailed Specification==
  Refer to the reference implementation, reproduced below, for the precise
  semantics and detailed rationale for those semantics.
  case OP_NOP4:
  {
  //format: block_hash sidechain_id OP_BRIBEVERIFY
  if (!(flags & SCRIPT_VERIFY_BRIBEVERIFY)) {
  // not enabled; treat as a NOP4
  if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
  return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
  }
  break;
  }
  if (stack.size() < 2)
  return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
  const CScriptNum scriptNumSidechainId(stacktop(-1),fRequireMinimal);
  uint8_t nSidechainId;
  if (!checker.CheckSidechainId(scriptNumSidechainId,nSidechainId)) {
  return set_error(serror, SCRIPT_ERR_UNKNOWN_SIDECHAIN);
  }
  // Check block hash
  bool fHashCritical = checker.CheckCriticalHash(stacktop(-2),nSidechainId);
  if (!fHashCritical) {
  return set_error(serror, SCRIPT_ERR_UNSATISFIED_BRIBE);
  }
  break;
  }
  https://github.com/Christewart/bitcoin/blob/94b6f33f2278c42d4d8758a3c8ffe2078e4ec933/src/script/interpreter.cpp#L427
  https://github.com/drivechain-project/bitcoin/pull/13
  ==Deployment==
  TODO
  ==Credits==
  Credit to Paul Sztorc for the original idea of Blind Merge Mined sidechains.
  Credit to CryptAxe for writing the foundational layer of software for drivechains so I could implement OP_BRIBEVERIFY.
  ==References==
  Blind Merge Mined Sidechains - http://www.truthcoin.info/blog/blind-merged-mining/
  Mailing list discussion - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014408.html
  ==Copyright==
  This document is placed in the public domain.
  
  [-- Attachment #2: Type: text/html, Size: 10619 bytes --]
  
  ^ permalink raw reply	[flat|nested] 25+ messages in thread

• • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
      2017-06-28  8:26 ` ZmnSCPxj
    @ 2017-06-28 22:20   ` Paul Sztorc
      2017-06-28 22:49     ` Russell O'Connor
      2017-06-30  4:00     ` ZmnSCPxj
      0 siblings, 2 replies; 25+ messages in thread
    From: Paul Sztorc @ 2017-06-28 22:20 UTC (permalink / raw)
      To: ZmnSCPxj, Chris Stewart; +Cc: Bitcoin Protocol Discussion
    
    Hi ZmnSCPxj,
    
    It seems that, in your version, the "bribers" would react to the scheme
    in inefficient ways, particularly when the mainchain's tx-fee-rate (ie
    fee per Kb) is low.
    
    In short, there would be many bribe-attempts (each of which would take
    up space in mainchain blocks), almost all of which would be unsuccessful.
    
    In turn, miners would likely react to this, and try to improve the state
    of affairs by offering users the privilege of occupying transaction slot
    #2 (ie, the one right after the coinbase). Users would need to trust
    miners for this, which introduces a cost friction which is pure
    deadweight loss. And, it might be easier for larger/older miners to be
    trustworthy than smaller/newer ones.
    
    Your way is actually very similar to mine. Mine _forces_ the bribe to be
    in the earliest txn (the coinbase) and to only occur once. Yours doesn't
    do anything to refund the briber, if the sidechain (but not the
    mainchain) reorganizes (as it can easily do, if an older sidechain
    parent is extended while the mainchain proceeds normally). This creates
    additional risk.
    
    I think mine is also much more space-efficient. Even if ours each had
    exactly one h* per sidechain per block, it seems that I only require one
    hash to be communicated (plus an indicator byte, and a ~2 byte counter
    for the ratchet), whereas you require two. Since its overhead per
    sidechain per block, it actually might really add up.
    
    Thanks,
    Paul
    
    
    
    On 6/28/2017 4:26 AM, ZmnSCPxj via bitcoin-dev wrote:
    > Good morning.
    > 
    > I still do not see what this does that cannot be done by:
    > 
    > OP_RETURN <sidechain-id> <sidechain-block-id>
    > 
    > A transaction with such an output would allow sidechain-miners to bribe
    > mainchain-miners by paying a transaction fee if the transaction
    > containing this OP_RETURN is included in a block and committed to by a
    > mainchain-miner in the Merkle tree root.
    > 
    > It would not require a softfork.
    > 
    > --
    > 
    > I have an alternate proposal that sidechains and altcoins that want to
    > do "blinded" merge mining can use without a softfork:
    > 
    > 1.  Encode a block header as a simple cons-pair, with the head as the
    > block and the tail as the parent cons-pair.
    > 1.1.  This can be encoded as a 32-byte hash of the block including its
    > header, and the 32-byte hash of the parent cons-pair.
    > 1.2.  This is now the actual "chain" in the sidecoin/altcoin blockchain.
    > 2.  When a sidechain-node wants to know the consensus, it downloads
    > mainchain-blocks and looks for OP_RETURN's.
    > 2.1.  Starting with its genesis cons-pair hash (equivalent to the empty
    > list) as the current cons-pair, it scans each OP_RETURN transaction.
    > 2.1.1.  If an OP_RETURN is 64-byte and has the parent cons-pair equal to
    > the current cons-pair, look for the side block indicated and confirm its
    > correctness.  If correct, update the current cons-pair for the hash of
    > the OP_RETURN data.
    > 2.2.  When reaching the latest mainchain block, the current cons-pair is
    > now the sidecoin/altcoin latest block.
    > 2.3.  Note that if multiple OP_RETURN in a block match the current
    > cons-pair, the first one is considered the correct chain.  This property
    > means that the sidechain/altchain can only have a chainsplit if the
    > mainchain has a chainsplit.
    > 3.  When a sidechain-miner wants to create a side-block, it generates a
    > new cons-pair and creates an OP_RETURN transaction for it, paying a
    > mainchain-miner to include it in the next mainchain-block.
    > 3.1.  The sidechain-miner risks that its competitors will outbid it and
    > get its OP_RETURN earlier in a mainchain-block (or earlier in the order
    > of transactions).  It can mitigate this risk by updating itself to
    > become a mainchain-miner, it can then keep its OP_RETURN transaction
    > private and put it earlier in the block, ensuring it will "win" the
    > sidechain-consensus if it wins the mainchain-consensus.
    > 
    > Regards,
    > ZmnSCPxj
    > 
    > -------- Original Message --------
    > Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
    > Merge Mined drivechains
    > Local Time: June 28, 2017 8:37 AM
    > UTC Time: June 28, 2017 12:37 AM
    > From: bitcoin-dev@lists•linuxfoundation.org
    > To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
    > 
    > <pre> 
    >   BIP: <BIP number>
    >   Layer: Consensus (Soft fork)
    >   Title: OP_BRIBEVERIFY
    >   Author: Chris Stewart <chris@suredbits•com>
    >   Status: Draft
    >   Type: Standards Track
    >   Created: 2017-06-27
    > </pre>
    > 
    > 
    > ==Abstract==
    > 
    > This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin
    > scripting system that allows for a user to bribe a miner to include a hash
    > in the coinbase transaction's output.
    > 
    > 
    > ==Summary==
    > 
    > BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
    > critical hash is included at the given vout index in the coinbase
    > transaction
    > the script evaluates to true. Otherwise, the script will fail.
    > 
    > This allows sidechains to be merged mined against
    > bitcoin without burdening bitcoin miners with extra resource requirements.
    > 
    > ==Motivation==
    > 
    > The current political climate of bitcoin is extremely contentious. Many
    > community members
    > have different visions of what bitcoin is. This op code is meant to
    > enable [http://www.truthcoin.info/blog/blind-merged-mining/ Blind Merge
    > Mining].
    > This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains
    > miners can
    > bribe bitcoin miners to to include their block hash in the bitcoin
    > blockchain. If their block
    > is included in the coinbase transaction's vout, it is assumed that block
    > is a mined block on the sidechain.
    > 
    > This will allow various factions of the community to realize their
    > vision on their own separate
    > blockchain that is interoperable with the bitcoin blockchain. This
    > allows those factions to use
    > bitcoin as a 'reserve currency' for their own network.
    > 
    > 
    > ===Commitment Structure===
    > 
    > A new block rule is added which requires that the miner's coinbase
    > reward be at index 0 in the coinbase transaction's output vector.
    > 
    > It also fixes the witness commitment output to be at index 1 of the
    > coinbase transaction's output vector.
    > 
    > This is needed so we can reliably tell what vout corresponds to what
    > drivechain. For instance, the mimblewimble sidechain
    > could correspond to index 2 of the vector outputs on the coinbase
    > transaction.
    > 
    > The commitment is recorded in a <code>scriptPubKey</code> of the
    > coinbase transaction. It must be at least 34 bytes in size
    >    1-byte - OP_RETURN (0x6a)
    >    1-byte - Push the following 32 bytes (0x20)
    >   32-byte - block hash
    > 
    > the 35th byte and onward have no consensus meaning.
    > 
    > ===OP_BRIBEVERIFY op code===
    > 
    > This op code reads two arguments from the stack. The stack top is
    > expected to be a sidechain id for which this user attempting to blind
    > merge mine for.
    > The next element on the stack is expected to be a block hash. This op
    > code looks into the coinbase transaction's output vector at the given
    > index (which is derived from the sidechain id) and checks
    > to see if the hash in the block matches the hash inside of the
    > BRIBEVERIFY program. If the hashes match, the OP_BRIBEVERIFY acts as an
    > OP_NOP. If the
    > comparison between the two hashes fail, the script fails.
    > 
    > ===BRIBEVERIFY program===
    > 
    > A standard BRIBEVERIFY program has the format:
    >   1-byte - Push the following 32 bytes (0x20)
    >  32-byte - block hash
    >   1 byte - Push operation? (needed if number can't be encoded as OP_0 -
    > OP_16)
    >   1 byte - sidechain id
    >   1 byte - OP_BRIBEVERIFY op code
    > 
    > ==Detailed Specification==
    > 
    > Refer to the reference implementation, reproduced below, for the precise
    > semantics and detailed rationale for those semantics.
    > 
    >  
    >  case OP_NOP4:
    >  {
    >     //format: block_hash sidechain_id OP_BRIBEVERIFY
    >     if (!(flags & SCRIPT_VERIFY_BRIBEVERIFY)) {
    >         // not enabled; treat as a NOP4
    >         if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
    >             return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
    >         }
    >         break;
    >     }
    >    
    >     if (stack.size() < 2)
    >         return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
    >  
    >     const CScriptNum scriptNumSidechainId(stacktop(-1),fRequireMinimal);
    >     uint8_t nSidechainId; 
    >     if (!checker.CheckSidechainId(scriptNumSidechainId,nSidechainId)) {
    >         return set_error(serror, SCRIPT_ERR_UNKNOWN_SIDECHAIN);
    >     }
    >  
    >     // Check block hash
    >     bool fHashCritical =
    > checker.CheckCriticalHash(stacktop(-2),nSidechainId);
    >     if (!fHashCritical) {
    >         return set_error(serror, SCRIPT_ERR_UNSATISFIED_BRIBE);
    >     }
    >     break;
    >  }
    > 
    > 
    > 
    > https://github.com/Christewart/bitcoin/blob/94b6f33f2278c42d4d8758a3c8ffe2078e4ec933/src/script/interpreter.cpp#L427
    > 
    > https://github.com/drivechain-project/bitcoin/pull/13
    > 
    > ==Deployment==
    > 
    > TODO
    > 
    > ==Credits==
    > 
    > Credit to Paul Sztorc for the original idea of Blind Merge Mined sidechains.
    > 
    > Credit to CryptAxe for writing the foundational layer of software for
    > drivechains so I could implement OP_BRIBEVERIFY.
    > 
    > 
    > ==References==
    > 
    > Blind Merge Mined Sidechains -
    > http://www.truthcoin.info/blog/blind-merged-mining/
    > Mailing list discussion -
    > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014408.html
    > 
    > ==Copyright==
    > 
    > This document is placed in the public domain.
    > 
    > 
    > _______________________________________________
    > bitcoin-dev mailing list
    > bitcoin-dev@lists•linuxfoundation.org
    > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    > 
    
    
    ^ permalink raw reply	[flat|nested] 25+ messages in thread

  • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
        2017-06-28 22:20   ` Paul Sztorc
      @ 2017-06-28 22:49     ` Russell O'Connor
        2017-06-28 23:47       ` Chris Stewart
        2017-06-30  4:00     ` ZmnSCPxj
        1 sibling, 1 reply; 25+ messages in thread
      From: Russell O'Connor @ 2017-06-28 22:49 UTC (permalink / raw)
        To: Paul Sztorc; +Cc: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 11947 bytes --]
      
      I haven't really been following the drivechain discussion; I have found the
      documentation about how drivechains are supposed to work scattered and
      difficult to follow. So, without advocating for or against this proposal,
      I'd also suggest that adding an opcode is not the best way to implement
      this bribe.
      
      The problem I see is that to send a bribe one must first post a transaction
      to a script that uses the OP_BRIBE code that fixes the critical hash (and
      the sidechain id), and then a second transaction is needed to pay the bribe
      to the miner.
      
      I suggest instead to use a 0 output value with some currently non-standard
      OP_RETURN output script that specifies the critical hash (and the sidechain
      id), similar to ZmnSCPxj's idea.  The difference is that I we would
      soft-fork a rule that says that such an output is only legal when a miner
      places the same critical hash suitably in their coinbase output.
      
      OP_RETURN outputs are prunable from the UTXO set.  The special bribe output
      can be fixed to 0 value because the bribe will be paid using the
      transaction's fees.  To perform a bribe, a user creates and signs a
      transaction containing one (or more) of these special bribe outputs.  The
      fee of this transaction constitutes the bribe, and any change the user has
      can be sent back to themselves.  This way only a single transaction is
      required to make a bribe.  I didn't really understand the bribe refund
      mechanism, but I think the fact that the bribe can be done in a single
      transaction this way alleviates any need for bribe refunds.
      
      Hopefully I have understood the goal of this proposal.
      
      
      On Wed, Jun 28, 2017 at 6:20 PM, Paul Sztorc via bitcoin-dev <
      bitcoin-dev@lists•linuxfoundation.org> wrote:
      
      > Hi ZmnSCPxj,
      >
      > It seems that, in your version, the "bribers" would react to the scheme
      > in inefficient ways, particularly when the mainchain's tx-fee-rate (ie
      > fee per Kb) is low.
      >
      > In short, there would be many bribe-attempts (each of which would take
      > up space in mainchain blocks), almost all of which would be unsuccessful.
      >
      > In turn, miners would likely react to this, and try to improve the state
      > of affairs by offering users the privilege of occupying transaction slot
      > #2 (ie, the one right after the coinbase). Users would need to trust
      > miners for this, which introduces a cost friction which is pure
      > deadweight loss. And, it might be easier for larger/older miners to be
      > trustworthy than smaller/newer ones.
      >
      > Your way is actually very similar to mine. Mine _forces_ the bribe to be
      > in the earliest txn (the coinbase) and to only occur once. Yours doesn't
      > do anything to refund the briber, if the sidechain (but not the
      > mainchain) reorganizes (as it can easily do, if an older sidechain
      > parent is extended while the mainchain proceeds normally). This creates
      > additional risk.
      >
      > I think mine is also much more space-efficient. Even if ours each had
      > exactly one h* per sidechain per block, it seems that I only require one
      > hash to be communicated (plus an indicator byte, and a ~2 byte counter
      > for the ratchet), whereas you require two. Since its overhead per
      > sidechain per block, it actually might really add up.
      >
      > Thanks,
      > Paul
      >
      >
      >
      > On 6/28/2017 4:26 AM, ZmnSCPxj via bitcoin-dev wrote:
      > > Good morning.
      > >
      > > I still do not see what this does that cannot be done by:
      > >
      > > OP_RETURN <sidechain-id> <sidechain-block-id>
      > >
      > > A transaction with such an output would allow sidechain-miners to bribe
      > > mainchain-miners by paying a transaction fee if the transaction
      > > containing this OP_RETURN is included in a block and committed to by a
      > > mainchain-miner in the Merkle tree root.
      > >
      > > It would not require a softfork.
      > >
      > > --
      > >
      > > I have an alternate proposal that sidechains and altcoins that want to
      > > do "blinded" merge mining can use without a softfork:
      > >
      > > 1.  Encode a block header as a simple cons-pair, with the head as the
      > > block and the tail as the parent cons-pair.
      > > 1.1.  This can be encoded as a 32-byte hash of the block including its
      > > header, and the 32-byte hash of the parent cons-pair.
      > > 1.2.  This is now the actual "chain" in the sidecoin/altcoin blockchain.
      > > 2.  When a sidechain-node wants to know the consensus, it downloads
      > > mainchain-blocks and looks for OP_RETURN's.
      > > 2.1.  Starting with its genesis cons-pair hash (equivalent to the empty
      > > list) as the current cons-pair, it scans each OP_RETURN transaction.
      > > 2.1.1.  If an OP_RETURN is 64-byte and has the parent cons-pair equal to
      > > the current cons-pair, look for the side block indicated and confirm its
      > > correctness.  If correct, update the current cons-pair for the hash of
      > > the OP_RETURN data.
      > > 2.2.  When reaching the latest mainchain block, the current cons-pair is
      > > now the sidecoin/altcoin latest block.
      > > 2.3.  Note that if multiple OP_RETURN in a block match the current
      > > cons-pair, the first one is considered the correct chain.  This property
      > > means that the sidechain/altchain can only have a chainsplit if the
      > > mainchain has a chainsplit.
      > > 3.  When a sidechain-miner wants to create a side-block, it generates a
      > > new cons-pair and creates an OP_RETURN transaction for it, paying a
      > > mainchain-miner to include it in the next mainchain-block.
      > > 3.1.  The sidechain-miner risks that its competitors will outbid it and
      > > get its OP_RETURN earlier in a mainchain-block (or earlier in the order
      > > of transactions).  It can mitigate this risk by updating itself to
      > > become a mainchain-miner, it can then keep its OP_RETURN transaction
      > > private and put it earlier in the block, ensuring it will "win" the
      > > sidechain-consensus if it wins the mainchain-consensus.
      > >
      > > Regards,
      > > ZmnSCPxj
      > >
      > > -------- Original Message --------
      > > Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
      > > Merge Mined drivechains
      > > Local Time: June 28, 2017 8:37 AM
      > > UTC Time: June 28, 2017 12:37 AM
      > > From: bitcoin-dev@lists•linuxfoundation.org
      > > To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
      > >
      > > <pre>
      > >   BIP: <BIP number>
      > >   Layer: Consensus (Soft fork)
      > >   Title: OP_BRIBEVERIFY
      > >   Author: Chris Stewart <chris@suredbits•com>
      > >   Status: Draft
      > >   Type: Standards Track
      > >   Created: 2017-06-27
      > > </pre>
      > >
      > >
      > > ==Abstract==
      > >
      > > This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin
      > > scripting system that allows for a user to bribe a miner to include a
      > hash
      > > in the coinbase transaction's output.
      > >
      > >
      > > ==Summary==
      > >
      > > BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the
      > given
      > > critical hash is included at the given vout index in the coinbase
      > > transaction
      > > the script evaluates to true. Otherwise, the script will fail.
      > >
      > > This allows sidechains to be merged mined against
      > > bitcoin without burdening bitcoin miners with extra resource
      > requirements.
      > >
      > > ==Motivation==
      > >
      > > The current political climate of bitcoin is extremely contentious. Many
      > > community members
      > > have different visions of what bitcoin is. This op code is meant to
      > > enable [http://www.truthcoin.info/blog/blind-merged-mining/ Blind Merge
      > > Mining].
      > > This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains
      > > miners can
      > > bribe bitcoin miners to to include their block hash in the bitcoin
      > > blockchain. If their block
      > > is included in the coinbase transaction's vout, it is assumed that block
      > > is a mined block on the sidechain.
      > >
      > > This will allow various factions of the community to realize their
      > > vision on their own separate
      > > blockchain that is interoperable with the bitcoin blockchain. This
      > > allows those factions to use
      > > bitcoin as a 'reserve currency' for their own network.
      > >
      > >
      > > ===Commitment Structure===
      > >
      > > A new block rule is added which requires that the miner's coinbase
      > > reward be at index 0 in the coinbase transaction's output vector.
      > >
      > > It also fixes the witness commitment output to be at index 1 of the
      > > coinbase transaction's output vector.
      > >
      > > This is needed so we can reliably tell what vout corresponds to what
      > > drivechain. For instance, the mimblewimble sidechain
      > > could correspond to index 2 of the vector outputs on the coinbase
      > > transaction.
      > >
      > > The commitment is recorded in a <code>scriptPubKey</code> of the
      > > coinbase transaction. It must be at least 34 bytes in size
      > >    1-byte - OP_RETURN (0x6a)
      > >    1-byte - Push the following 32 bytes (0x20)
      > >   32-byte - block hash
      > >
      > > the 35th byte and onward have no consensus meaning.
      > >
      > > ===OP_BRIBEVERIFY op code===
      > >
      > > This op code reads two arguments from the stack. The stack top is
      > > expected to be a sidechain id for which this user attempting to blind
      > > merge mine for.
      > > The next element on the stack is expected to be a block hash. This op
      > > code looks into the coinbase transaction's output vector at the given
      > > index (which is derived from the sidechain id) and checks
      > > to see if the hash in the block matches the hash inside of the
      > > BRIBEVERIFY program. If the hashes match, the OP_BRIBEVERIFY acts as an
      > > OP_NOP. If the
      > > comparison between the two hashes fail, the script fails.
      > >
      > > ===BRIBEVERIFY program===
      > >
      > > A standard BRIBEVERIFY program has the format:
      > >   1-byte - Push the following 32 bytes (0x20)
      > >  32-byte - block hash
      > >   1 byte - Push operation? (needed if number can't be encoded as OP_0 -
      > > OP_16)
      > >   1 byte - sidechain id
      > >   1 byte - OP_BRIBEVERIFY op code
      > >
      > > ==Detailed Specification==
      > >
      > > Refer to the reference implementation, reproduced below, for the precise
      > > semantics and detailed rationale for those semantics.
      > >
      > >
      > >  case OP_NOP4:
      > >  {
      > >     //format: block_hash sidechain_id OP_BRIBEVERIFY
      > >     if (!(flags & SCRIPT_VERIFY_BRIBEVERIFY)) {
      > >         // not enabled; treat as a NOP4
      > >         if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
      > >             return set_error(serror, SCRIPT_ERR_DISCOURAGE_
      > UPGRADABLE_NOPS);
      > >         }
      > >         break;
      > >     }
      > >
      > >     if (stack.size() < 2)
      > >         return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
      > >
      > >     const CScriptNum scriptNumSidechainId(stacktop(-1),fRequireMinimal);
      > >     uint8_t nSidechainId;
      > >     if (!checker.CheckSidechainId(scriptNumSidechainId,nSidechainId)) {
      > >         return set_error(serror, SCRIPT_ERR_UNKNOWN_SIDECHAIN);
      > >     }
      > >
      > >     // Check block hash
      > >     bool fHashCritical =
      > > checker.CheckCriticalHash(stacktop(-2),nSidechainId);
      > >     if (!fHashCritical) {
      > >         return set_error(serror, SCRIPT_ERR_UNSATISFIED_BRIBE);
      > >     }
      > >     break;
      > >  }
      > >
      > >
      > >
      > > https://github.com/Christewart/bitcoin/blob/
      > 94b6f33f2278c42d4d8758a3c8ffe2078e4ec933/src/script/interpreter.cpp#L427
      > >
      > > https://github.com/drivechain-project/bitcoin/pull/13
      > >
      > > ==Deployment==
      > >
      > > TODO
      > >
      > > ==Credits==
      > >
      > > Credit to Paul Sztorc for the original idea of Blind Merge Mined
      > sidechains.
      > >
      > > Credit to CryptAxe for writing the foundational layer of software for
      > > drivechains so I could implement OP_BRIBEVERIFY.
      > >
      > >
      > > ==References==
      > >
      > > Blind Merge Mined Sidechains -
      > > http://www.truthcoin.info/blog/blind-merged-mining/
      > > Mailing list discussion -
      > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
      > 2017-May/014408.html
      > >
      > > ==Copyright==
      > >
      > > This document is placed in the public domain.
      > >
      > >
      > > _______________________________________________
      > > bitcoin-dev mailing list
      > > bitcoin-dev@lists•linuxfoundation.org
      > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      > >
      > _______________________________________________
      > bitcoin-dev mailing list
      > bitcoin-dev@lists•linuxfoundation.org
      > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      >
      
      [-- Attachment #2: Type: text/html, Size: 15392 bytes --]
      
      ^ permalink raw reply	[flat|nested] 25+ messages in thread

    • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
          2017-06-28 22:49     ` Russell O'Connor
        @ 2017-06-28 23:47       ` Chris Stewart
          2017-06-29  1:09         ` Russell O'Connor
          0 siblings, 1 reply; 25+ messages in thread
        From: Chris Stewart @ 2017-06-28 23:47 UTC (permalink / raw)
          To: Russell O'Connor; +Cc: Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 14950 bytes --]
        
        Hi Russell,
        
        >I haven't really been following the drivechain discussion; I have found
        the documentation about how drivechains are supposed to work scattered and
        difficult to follow. So, without advocating for or against this proposal,
        I'd also suggest that adding an opcode is not the best way to implement
        this bribe.
        
        Despite the flaws in this draft BIP, the goal is to start consolidating
        this information into a more compact format. This BIP is *only*
        meant to address the Blind Merging Mining Process of drivechains. It does
        *not* address the withdrawal process from drivechain -> bitcoin.
        
        >The problem I see is that to send a bribe one must first post a
        transaction to a script that uses the OP_BRIBE code that fixes the critical
        hash (and the sidechain id), and then a second transaction is needed to pay
        the bribe to the miner.
        
        That is intentional, this allows for a competitive process (like bitcoin
        mining) for a block to be 'found' on the sidechain. The OP_BV output that
        rewards
        the bitcoin miner the most amount of money should be the one that is
        included in the bitcoin blockchain. If I understand your scheme correctly,
        you are
        assuming the the bitcoin miner is *also* following the sidechain --
        Sztorc's scheme does not make this assumption. The *number one goal* of BMM
        is to *minimize* the resource burden on bitcoin miners for mining on a
        drivechain.
        
        To gmaxwell/luke-jr,
        
        I agree my commitment scheme is flawed. Thanks for pointing it out. Is
        there any way we could manipulate a coinbase transaction
        into spending these OP_BV outputs? According to instagibbs, and AFIACT he
        is right, we cannot have coinbase transactions
        spend any outputs in previous blocks without a hard fork. This is
        unfortunate because it might make more sense for the coinbase transaction
        to spend these OP_BV outputs. We could design the coinbase transaction's
        scriptSig to push the critical hash onto the stack and
        place an OP_EQUAL on the OP_BV output to verify they were equal.
        If I understand gmaxwell's concern about 'monotone' (or stateless) blocks
        correctly, I *think*
        this solution might fix that as well.
        
        Another way we could fix this is by *fixing* the drivechain indices.
        Therefore the mining rewards and witness commitments must
        *not* occupy one of those indices -- but can occupy any other indice in the
        coinbase output.
        This would give us future flexibility for committing to new soft forks. For
        instance, we would say
        the mining reward must *not* be index 0 of the coinbase transaction, but
        can occupy index 1 - 256. The same would apply for witness commitments.
        
        -Chris
        
        On Wed, Jun 28, 2017 at 5:49 PM, Russell O'Connor <roconnor@blockstream•io>
        wrote:
        
        > I haven't really been following the drivechain discussion; I have found
        > the documentation about how drivechains are supposed to work scattered and
        > difficult to follow. So, without advocating for or against this proposal,
        > I'd also suggest that adding an opcode is not the best way to implement
        > this bribe.
        >
        > The problem I see is that to send a bribe one must first post a
        > transaction to a script that uses the OP_BRIBE code that fixes the critical
        > hash (and the sidechain id), and then a second transaction is needed to pay
        > the bribe to the miner.
        >
        > I suggest instead to use a 0 output value with some currently non-standard
        > OP_RETURN output script that specifies the critical hash (and the sidechain
        > id), similar to ZmnSCPxj's idea.  The difference is that I we would
        > soft-fork a rule that says that such an output is only legal when a miner
        > places the same critical hash suitably in their coinbase output.
        >
        > OP_RETURN outputs are prunable from the UTXO set.  The special bribe
        > output can be fixed to 0 value because the bribe will be paid using the
        > transaction's fees.  To perform a bribe, a user creates and signs a
        > transaction containing one (or more) of these special bribe outputs.  The
        > fee of this transaction constitutes the bribe, and any change the user has
        > can be sent back to themselves.  This way only a single transaction is
        > required to make a bribe.  I didn't really understand the bribe refund
        > mechanism, but I think the fact that the bribe can be done in a single
        > transaction this way alleviates any need for bribe refunds.
        >
        > Hopefully I have understood the goal of this proposal.
        >
        >
        > On Wed, Jun 28, 2017 at 6:20 PM, Paul Sztorc via bitcoin-dev <
        > bitcoin-dev@lists•linuxfoundation.org> wrote:
        >
        >> Hi ZmnSCPxj,
        >>
        >> It seems that, in your version, the "bribers" would react to the scheme
        >> in inefficient ways, particularly when the mainchain's tx-fee-rate (ie
        >> fee per Kb) is low.
        >>
        >> In short, there would be many bribe-attempts (each of which would take
        >> up space in mainchain blocks), almost all of which would be unsuccessful.
        >>
        >> In turn, miners would likely react to this, and try to improve the state
        >> of affairs by offering users the privilege of occupying transaction slot
        >> #2 (ie, the one right after the coinbase). Users would need to trust
        >> miners for this, which introduces a cost friction which is pure
        >> deadweight loss. And, it might be easier for larger/older miners to be
        >> trustworthy than smaller/newer ones.
        >>
        >> Your way is actually very similar to mine. Mine _forces_ the bribe to be
        >> in the earliest txn (the coinbase) and to only occur once. Yours doesn't
        >> do anything to refund the briber, if the sidechain (but not the
        >> mainchain) reorganizes (as it can easily do, if an older sidechain
        >> parent is extended while the mainchain proceeds normally). This creates
        >> additional risk.
        >>
        >> I think mine is also much more space-efficient. Even if ours each had
        >> exactly one h* per sidechain per block, it seems that I only require one
        >> hash to be communicated (plus an indicator byte, and a ~2 byte counter
        >> for the ratchet), whereas you require two. Since its overhead per
        >> sidechain per block, it actually might really add up.
        >>
        >> Thanks,
        >> Paul
        >>
        >>
        >>
        >> On 6/28/2017 4:26 AM, ZmnSCPxj via bitcoin-dev wrote:
        >> > Good morning.
        >> >
        >> > I still do not see what this does that cannot be done by:
        >> >
        >> > OP_RETURN <sidechain-id> <sidechain-block-id>
        >> >
        >> > A transaction with such an output would allow sidechain-miners to bribe
        >> > mainchain-miners by paying a transaction fee if the transaction
        >> > containing this OP_RETURN is included in a block and committed to by a
        >> > mainchain-miner in the Merkle tree root.
        >> >
        >> > It would not require a softfork.
        >> >
        >> > --
        >> >
        >> > I have an alternate proposal that sidechains and altcoins that want to
        >> > do "blinded" merge mining can use without a softfork:
        >> >
        >> > 1.  Encode a block header as a simple cons-pair, with the head as the
        >> > block and the tail as the parent cons-pair.
        >> > 1.1.  This can be encoded as a 32-byte hash of the block including its
        >> > header, and the 32-byte hash of the parent cons-pair.
        >> > 1.2.  This is now the actual "chain" in the sidecoin/altcoin blockchain.
        >> > 2.  When a sidechain-node wants to know the consensus, it downloads
        >> > mainchain-blocks and looks for OP_RETURN's.
        >> > 2.1.  Starting with its genesis cons-pair hash (equivalent to the empty
        >> > list) as the current cons-pair, it scans each OP_RETURN transaction.
        >> > 2.1.1.  If an OP_RETURN is 64-byte and has the parent cons-pair equal to
        >> > the current cons-pair, look for the side block indicated and confirm its
        >> > correctness.  If correct, update the current cons-pair for the hash of
        >> > the OP_RETURN data.
        >> > 2.2.  When reaching the latest mainchain block, the current cons-pair is
        >> > now the sidecoin/altcoin latest block.
        >> > 2.3.  Note that if multiple OP_RETURN in a block match the current
        >> > cons-pair, the first one is considered the correct chain.  This property
        >> > means that the sidechain/altchain can only have a chainsplit if the
        >> > mainchain has a chainsplit.
        >> > 3.  When a sidechain-miner wants to create a side-block, it generates a
        >> > new cons-pair and creates an OP_RETURN transaction for it, paying a
        >> > mainchain-miner to include it in the next mainchain-block.
        >> > 3.1.  The sidechain-miner risks that its competitors will outbid it and
        >> > get its OP_RETURN earlier in a mainchain-block (or earlier in the order
        >> > of transactions).  It can mitigate this risk by updating itself to
        >> > become a mainchain-miner, it can then keep its OP_RETURN transaction
        >> > private and put it earlier in the block, ensuring it will "win" the
        >> > sidechain-consensus if it wins the mainchain-consensus.
        >> >
        >> > Regards,
        >> > ZmnSCPxj
        >> >
        >> > -------- Original Message --------
        >> > Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
        >> > Merge Mined drivechains
        >> > Local Time: June 28, 2017 8:37 AM
        >> > UTC Time: June 28, 2017 12:37 AM
        >> > From: bitcoin-dev@lists•linuxfoundation.org
        >> > To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
        >> >
        >> > <pre>
        >> >   BIP: <BIP number>
        >> >   Layer: Consensus (Soft fork)
        >> >   Title: OP_BRIBEVERIFY
        >> >   Author: Chris Stewart <chris@suredbits•com>
        >> >   Status: Draft
        >> >   Type: Standards Track
        >> >   Created: 2017-06-27
        >> > </pre>
        >> >
        >> >
        >> > ==Abstract==
        >> >
        >> > This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin
        >> > scripting system that allows for a user to bribe a miner to include a
        >> hash
        >> > in the coinbase transaction's output.
        >> >
        >> >
        >> > ==Summary==
        >> >
        >> > BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the
        >> given
        >> > critical hash is included at the given vout index in the coinbase
        >> > transaction
        >> > the script evaluates to true. Otherwise, the script will fail.
        >> >
        >> > This allows sidechains to be merged mined against
        >> > bitcoin without burdening bitcoin miners with extra resource
        >> requirements.
        >> >
        >> > ==Motivation==
        >> >
        >> > The current political climate of bitcoin is extremely contentious. Many
        >> > community members
        >> > have different visions of what bitcoin is. This op code is meant to
        >> > enable [http://www.truthcoin.info/blog/blind-merged-mining/ Blind Merge
        >> > Mining].
        >> > This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains
        >> > miners can
        >> > bribe bitcoin miners to to include their block hash in the bitcoin
        >> > blockchain. If their block
        >> > is included in the coinbase transaction's vout, it is assumed that block
        >> > is a mined block on the sidechain.
        >> >
        >> > This will allow various factions of the community to realize their
        >> > vision on their own separate
        >> > blockchain that is interoperable with the bitcoin blockchain. This
        >> > allows those factions to use
        >> > bitcoin as a 'reserve currency' for their own network.
        >> >
        >> >
        >> > ===Commitment Structure===
        >> >
        >> > A new block rule is added which requires that the miner's coinbase
        >> > reward be at index 0 in the coinbase transaction's output vector.
        >> >
        >> > It also fixes the witness commitment output to be at index 1 of the
        >> > coinbase transaction's output vector.
        >> >
        >> > This is needed so we can reliably tell what vout corresponds to what
        >> > drivechain. For instance, the mimblewimble sidechain
        >> > could correspond to index 2 of the vector outputs on the coinbase
        >> > transaction.
        >> >
        >> > The commitment is recorded in a <code>scriptPubKey</code> of the
        >> > coinbase transaction. It must be at least 34 bytes in size
        >> >    1-byte - OP_RETURN (0x6a)
        >> >    1-byte - Push the following 32 bytes (0x20)
        >> >   32-byte - block hash
        >> >
        >> > the 35th byte and onward have no consensus meaning.
        >> >
        >> > ===OP_BRIBEVERIFY op code===
        >> >
        >> > This op code reads two arguments from the stack. The stack top is
        >> > expected to be a sidechain id for which this user attempting to blind
        >> > merge mine for.
        >> > The next element on the stack is expected to be a block hash. This op
        >> > code looks into the coinbase transaction's output vector at the given
        >> > index (which is derived from the sidechain id) and checks
        >> > to see if the hash in the block matches the hash inside of the
        >> > BRIBEVERIFY program. If the hashes match, the OP_BRIBEVERIFY acts as an
        >> > OP_NOP. If the
        >> > comparison between the two hashes fail, the script fails.
        >> >
        >> > ===BRIBEVERIFY program===
        >> >
        >> > A standard BRIBEVERIFY program has the format:
        >> >   1-byte - Push the following 32 bytes (0x20)
        >> >  32-byte - block hash
        >> >   1 byte - Push operation? (needed if number can't be encoded as OP_0 -
        >> > OP_16)
        >> >   1 byte - sidechain id
        >> >   1 byte - OP_BRIBEVERIFY op code
        >> >
        >> > ==Detailed Specification==
        >> >
        >> > Refer to the reference implementation, reproduced below, for the precise
        >> > semantics and detailed rationale for those semantics.
        >> >
        >> >
        >> >  case OP_NOP4:
        >> >  {
        >> >     //format: block_hash sidechain_id OP_BRIBEVERIFY
        >> >     if (!(flags & SCRIPT_VERIFY_BRIBEVERIFY)) {
        >> >         // not enabled; treat as a NOP4
        >> >         if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
        >> >             return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADAB
        >> LE_NOPS);
        >> >         }
        >> >         break;
        >> >     }
        >> >
        >> >     if (stack.size() < 2)
        >> >         return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
        >> >
        >> >     const CScriptNum scriptNumSidechainId(stacktop(
        >> -1),fRequireMinimal);
        >> >     uint8_t nSidechainId;
        >> >     if (!checker.CheckSidechainId(scriptNumSidechainId,nSidechainId)) {
        >> >         return set_error(serror, SCRIPT_ERR_UNKNOWN_SIDECHAIN);
        >> >     }
        >> >
        >> >     // Check block hash
        >> >     bool fHashCritical =
        >> > checker.CheckCriticalHash(stacktop(-2),nSidechainId);
        >> >     if (!fHashCritical) {
        >> >         return set_error(serror, SCRIPT_ERR_UNSATISFIED_BRIBE);
        >> >     }
        >> >     break;
        >> >  }
        >> >
        >> >
        >> >
        >> > https://github.com/Christewart/bitcoin/blob/94b6f33f2278c42d
        >> 4d8758a3c8ffe2078e4ec933/src/script/interpreter.cpp#L427
        >> >
        >> > https://github.com/drivechain-project/bitcoin/pull/13
        >> >
        >> > ==Deployment==
        >> >
        >> > TODO
        >> >
        >> > ==Credits==
        >> >
        >> > Credit to Paul Sztorc for the original idea of Blind Merge Mined
        >> sidechains.
        >> >
        >> > Credit to CryptAxe for writing the foundational layer of software for
        >> > drivechains so I could implement OP_BRIBEVERIFY.
        >> >
        >> >
        >> > ==References==
        >> >
        >> > Blind Merge Mined Sidechains -
        >> > http://www.truthcoin.info/blog/blind-merged-mining/
        >> > Mailing list discussion -
        >> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
        >> -May/014408.html
        >> >
        >> > ==Copyright==
        >> >
        >> > This document is placed in the public domain.
        >> >
        >> >
        >> > _______________________________________________
        >> > bitcoin-dev mailing list
        >> > bitcoin-dev@lists•linuxfoundation.org
        >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >> >
        >> _______________________________________________
        >> bitcoin-dev mailing list
        >> bitcoin-dev@lists•linuxfoundation.org
        >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >>
        >
        >
        
        [-- Attachment #2: Type: text/html, Size: 18725 bytes --]
        
        ^ permalink raw reply	[flat|nested] 25+ messages in thread

      • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
            2017-06-28 23:47       ` Chris Stewart
          @ 2017-06-29  1:09         ` Russell O'Connor
            0 siblings, 0 replies; 25+ messages in thread
          From: Russell O'Connor @ 2017-06-29  1:09 UTC (permalink / raw)
            To: Chris Stewart; +Cc: Bitcoin Protocol Discussion
          
          [-- Attachment #1: Type: text/plain, Size: 16223 bytes --]
          
          HI Chris,
          
          My proposal isn't intended to assume that the bitcoin miner is also
          following the sidechain.  In line with my understanding of your proposal,
          I'm only proposing to bribe miners to put particular data into the coinbase
          output regardless of any semantics that doing so may entail. By my proposed
          soft-fork rules, only one of these Bribe TXOs can be included per coinbase
          slot (except unless there are identical Bribe TXOs), so there is a
          competition of which one of a set of conflicting Bribe TXOs will be
          included in the next block.  (That said, the losing set Bribe TXOs can be
          included in the later blocks; I don't know what this means semantically for
          sidechains; however, the same thing occurs with your proposal as well.)
          
          On Wed, Jun 28, 2017 at 7:47 PM, Chris Stewart <chris@suredbits•com> wrote:
          
          > Hi Russell,
          >
          > >I haven't really been following the drivechain discussion; I have found
          > the documentation about how drivechains are supposed to work scattered and
          > difficult to follow. So, without advocating for or against this proposal,
          > I'd also suggest that adding an opcode is not the best way to implement
          > this bribe.
          >
          > Despite the flaws in this draft BIP, the goal is to start consolidating
          > this information into a more compact format. This BIP is *only*
          > meant to address the Blind Merging Mining Process of drivechains. It does
          > *not* address the withdrawal process from drivechain -> bitcoin.
          >
          > >The problem I see is that to send a bribe one must first post a
          > transaction to a script that uses the OP_BRIBE code that fixes the critical
          > hash (and the sidechain id), and then a second transaction is needed to pay
          > the bribe to the miner.
          >
          > That is intentional, this allows for a competitive process (like bitcoin
          > mining) for a block to be 'found' on the sidechain. The OP_BV output that
          > rewards
          > the bitcoin miner the most amount of money should be the one that is
          > included in the bitcoin blockchain. If I understand your scheme correctly,
          > you are
          > assuming the the bitcoin miner is *also* following the sidechain --
          > Sztorc's scheme does not make this assumption. The *number one goal* of BMM
          > is to *minimize* the resource burden on bitcoin miners for mining on a
          > drivechain.
          >
          > To gmaxwell/luke-jr,
          >
          > I agree my commitment scheme is flawed. Thanks for pointing it out. Is
          > there any way we could manipulate a coinbase transaction
          > into spending these OP_BV outputs? According to instagibbs, and AFIACT he
          > is right, we cannot have coinbase transactions
          > spend any outputs in previous blocks without a hard fork. This is
          > unfortunate because it might make more sense for the coinbase transaction
          > to spend these OP_BV outputs. We could design the coinbase transaction's
          > scriptSig to push the critical hash onto the stack and
          > place an OP_EQUAL on the OP_BV output to verify they were equal.
          > If I understand gmaxwell's concern about 'monotone' (or stateless) blocks
          > correctly, I *think*
          > this solution might fix that as well.
          >
          > Another way we could fix this is by *fixing* the drivechain indices.
          > Therefore the mining rewards and witness commitments must
          > *not* occupy one of those indices -- but can occupy any other indice in
          > the coinbase output.
          > This would give us future flexibility for committing to new soft forks.
          > For instance, we would say
          > the mining reward must *not* be index 0 of the coinbase transaction, but
          > can occupy index 1 - 256. The same would apply for witness commitments.
          >
          > -Chris
          >
          > On Wed, Jun 28, 2017 at 5:49 PM, Russell O'Connor <roconnor@blockstream•io
          > > wrote:
          >
          >> I haven't really been following the drivechain discussion; I have found
          >> the documentation about how drivechains are supposed to work scattered and
          >> difficult to follow. So, without advocating for or against this proposal,
          >> I'd also suggest that adding an opcode is not the best way to implement
          >> this bribe.
          >>
          >> The problem I see is that to send a bribe one must first post a
          >> transaction to a script that uses the OP_BRIBE code that fixes the critical
          >> hash (and the sidechain id), and then a second transaction is needed to pay
          >> the bribe to the miner.
          >>
          >> I suggest instead to use a 0 output value with some currently
          >> non-standard OP_RETURN output script that specifies the critical hash (and
          >> the sidechain id), similar to ZmnSCPxj's idea.  The difference is that I we
          >> would soft-fork a rule that says that such an output is only legal when a
          >> miner places the same critical hash suitably in their coinbase output.
          >>
          >> OP_RETURN outputs are prunable from the UTXO set.  The special bribe
          >> output can be fixed to 0 value because the bribe will be paid using the
          >> transaction's fees.  To perform a bribe, a user creates and signs a
          >> transaction containing one (or more) of these special bribe outputs.  The
          >> fee of this transaction constitutes the bribe, and any change the user has
          >> can be sent back to themselves.  This way only a single transaction is
          >> required to make a bribe.  I didn't really understand the bribe refund
          >> mechanism, but I think the fact that the bribe can be done in a single
          >> transaction this way alleviates any need for bribe refunds.
          >>
          >> Hopefully I have understood the goal of this proposal.
          >>
          >>
          >> On Wed, Jun 28, 2017 at 6:20 PM, Paul Sztorc via bitcoin-dev <
          >> bitcoin-dev@lists•linuxfoundation.org> wrote:
          >>
          >>> Hi ZmnSCPxj,
          >>>
          >>> It seems that, in your version, the "bribers" would react to the scheme
          >>> in inefficient ways, particularly when the mainchain's tx-fee-rate (ie
          >>> fee per Kb) is low.
          >>>
          >>> In short, there would be many bribe-attempts (each of which would take
          >>> up space in mainchain blocks), almost all of which would be unsuccessful.
          >>>
          >>> In turn, miners would likely react to this, and try to improve the state
          >>> of affairs by offering users the privilege of occupying transaction slot
          >>> #2 (ie, the one right after the coinbase). Users would need to trust
          >>> miners for this, which introduces a cost friction which is pure
          >>> deadweight loss. And, it might be easier for larger/older miners to be
          >>> trustworthy than smaller/newer ones.
          >>>
          >>> Your way is actually very similar to mine. Mine _forces_ the bribe to be
          >>> in the earliest txn (the coinbase) and to only occur once. Yours doesn't
          >>> do anything to refund the briber, if the sidechain (but not the
          >>> mainchain) reorganizes (as it can easily do, if an older sidechain
          >>> parent is extended while the mainchain proceeds normally). This creates
          >>> additional risk.
          >>>
          >>> I think mine is also much more space-efficient. Even if ours each had
          >>> exactly one h* per sidechain per block, it seems that I only require one
          >>> hash to be communicated (plus an indicator byte, and a ~2 byte counter
          >>> for the ratchet), whereas you require two. Since its overhead per
          >>> sidechain per block, it actually might really add up.
          >>>
          >>> Thanks,
          >>> Paul
          >>>
          >>>
          >>>
          >>> On 6/28/2017 4:26 AM, ZmnSCPxj via bitcoin-dev wrote:
          >>> > Good morning.
          >>> >
          >>> > I still do not see what this does that cannot be done by:
          >>> >
          >>> > OP_RETURN <sidechain-id> <sidechain-block-id>
          >>> >
          >>> > A transaction with such an output would allow sidechain-miners to bribe
          >>> > mainchain-miners by paying a transaction fee if the transaction
          >>> > containing this OP_RETURN is included in a block and committed to by a
          >>> > mainchain-miner in the Merkle tree root.
          >>> >
          >>> > It would not require a softfork.
          >>> >
          >>> > --
          >>> >
          >>> > I have an alternate proposal that sidechains and altcoins that want to
          >>> > do "blinded" merge mining can use without a softfork:
          >>> >
          >>> > 1.  Encode a block header as a simple cons-pair, with the head as the
          >>> > block and the tail as the parent cons-pair.
          >>> > 1.1.  This can be encoded as a 32-byte hash of the block including its
          >>> > header, and the 32-byte hash of the parent cons-pair.
          >>> > 1.2.  This is now the actual "chain" in the sidecoin/altcoin
          >>> blockchain.
          >>> > 2.  When a sidechain-node wants to know the consensus, it downloads
          >>> > mainchain-blocks and looks for OP_RETURN's.
          >>> > 2.1.  Starting with its genesis cons-pair hash (equivalent to the empty
          >>> > list) as the current cons-pair, it scans each OP_RETURN transaction.
          >>> > 2.1.1.  If an OP_RETURN is 64-byte and has the parent cons-pair equal
          >>> to
          >>> > the current cons-pair, look for the side block indicated and confirm
          >>> its
          >>> > correctness.  If correct, update the current cons-pair for the hash of
          >>> > the OP_RETURN data.
          >>> > 2.2.  When reaching the latest mainchain block, the current cons-pair
          >>> is
          >>> > now the sidecoin/altcoin latest block.
          >>> > 2.3.  Note that if multiple OP_RETURN in a block match the current
          >>> > cons-pair, the first one is considered the correct chain.  This
          >>> property
          >>> > means that the sidechain/altchain can only have a chainsplit if the
          >>> > mainchain has a chainsplit.
          >>> > 3.  When a sidechain-miner wants to create a side-block, it generates a
          >>> > new cons-pair and creates an OP_RETURN transaction for it, paying a
          >>> > mainchain-miner to include it in the next mainchain-block.
          >>> > 3.1.  The sidechain-miner risks that its competitors will outbid it and
          >>> > get its OP_RETURN earlier in a mainchain-block (or earlier in the order
          >>> > of transactions).  It can mitigate this risk by updating itself to
          >>> > become a mainchain-miner, it can then keep its OP_RETURN transaction
          >>> > private and put it earlier in the block, ensuring it will "win" the
          >>> > sidechain-consensus if it wins the mainchain-consensus.
          >>> >
          >>> > Regards,
          >>> > ZmnSCPxj
          >>> >
          >>> > -------- Original Message --------
          >>> > Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for
          >>> Blind
          >>> > Merge Mined drivechains
          >>> > Local Time: June 28, 2017 8:37 AM
          >>> > UTC Time: June 28, 2017 12:37 AM
          >>> > From: bitcoin-dev@lists•linuxfoundation.org
          >>> > To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org
          >>> >
          >>> >
          >>> > <pre>
          >>> >   BIP: <BIP number>
          >>> >   Layer: Consensus (Soft fork)
          >>> >   Title: OP_BRIBEVERIFY
          >>> >   Author: Chris Stewart <chris@suredbits•com>
          >>> >   Status: Draft
          >>> >   Type: Standards Track
          >>> >   Created: 2017-06-27
          >>> > </pre>
          >>> >
          >>> >
          >>> > ==Abstract==
          >>> >
          >>> > This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin
          >>> > scripting system that allows for a user to bribe a miner to include a
          >>> hash
          >>> > in the coinbase transaction's output.
          >>> >
          >>> >
          >>> > ==Summary==
          >>> >
          >>> > BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the
          >>> given
          >>> > critical hash is included at the given vout index in the coinbase
          >>> > transaction
          >>> > the script evaluates to true. Otherwise, the script will fail.
          >>> >
          >>> > This allows sidechains to be merged mined against
          >>> > bitcoin without burdening bitcoin miners with extra resource
          >>> requirements.
          >>> >
          >>> > ==Motivation==
          >>> >
          >>> > The current political climate of bitcoin is extremely contentious. Many
          >>> > community members
          >>> > have different visions of what bitcoin is. This op code is meant to
          >>> > enable [http://www.truthcoin.info/blog/blind-merged-mining/ Blind
          >>> Merge
          >>> > Mining].
          >>> > This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains
          >>> > miners can
          >>> > bribe bitcoin miners to to include their block hash in the bitcoin
          >>> > blockchain. If their block
          >>> > is included in the coinbase transaction's vout, it is assumed that
          >>> block
          >>> > is a mined block on the sidechain.
          >>> >
          >>> > This will allow various factions of the community to realize their
          >>> > vision on their own separate
          >>> > blockchain that is interoperable with the bitcoin blockchain. This
          >>> > allows those factions to use
          >>> > bitcoin as a 'reserve currency' for their own network.
          >>> >
          >>> >
          >>> > ===Commitment Structure===
          >>> >
          >>> > A new block rule is added which requires that the miner's coinbase
          >>> > reward be at index 0 in the coinbase transaction's output vector.
          >>> >
          >>> > It also fixes the witness commitment output to be at index 1 of the
          >>> > coinbase transaction's output vector.
          >>> >
          >>> > This is needed so we can reliably tell what vout corresponds to what
          >>> > drivechain. For instance, the mimblewimble sidechain
          >>> > could correspond to index 2 of the vector outputs on the coinbase
          >>> > transaction.
          >>> >
          >>> > The commitment is recorded in a <code>scriptPubKey</code> of the
          >>> > coinbase transaction. It must be at least 34 bytes in size
          >>> >    1-byte - OP_RETURN (0x6a)
          >>> >    1-byte - Push the following 32 bytes (0x20)
          >>> >   32-byte - block hash
          >>> >
          >>> > the 35th byte and onward have no consensus meaning.
          >>> >
          >>> > ===OP_BRIBEVERIFY op code===
          >>> >
          >>> > This op code reads two arguments from the stack. The stack top is
          >>> > expected to be a sidechain id for which this user attempting to blind
          >>> > merge mine for.
          >>> > The next element on the stack is expected to be a block hash. This op
          >>> > code looks into the coinbase transaction's output vector at the given
          >>> > index (which is derived from the sidechain id) and checks
          >>> > to see if the hash in the block matches the hash inside of the
          >>> > BRIBEVERIFY program. If the hashes match, the OP_BRIBEVERIFY acts as an
          >>> > OP_NOP. If the
          >>> > comparison between the two hashes fail, the script fails.
          >>> >
          >>> > ===BRIBEVERIFY program===
          >>> >
          >>> > A standard BRIBEVERIFY program has the format:
          >>> >   1-byte - Push the following 32 bytes (0x20)
          >>> >  32-byte - block hash
          >>> >   1 byte - Push operation? (needed if number can't be encoded as OP_0 -
          >>> > OP_16)
          >>> >   1 byte - sidechain id
          >>> >   1 byte - OP_BRIBEVERIFY op code
          >>> >
          >>> > ==Detailed Specification==
          >>> >
          >>> > Refer to the reference implementation, reproduced below, for the
          >>> precise
          >>> > semantics and detailed rationale for those semantics.
          >>> >
          >>> >
          >>> >  case OP_NOP4:
          >>> >  {
          >>> >     //format: block_hash sidechain_id OP_BRIBEVERIFY
          >>> >     if (!(flags & SCRIPT_VERIFY_BRIBEVERIFY)) {
          >>> >         // not enabled; treat as a NOP4
          >>> >         if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
          >>> >             return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADAB
          >>> LE_NOPS);
          >>> >         }
          >>> >         break;
          >>> >     }
          >>> >
          >>> >     if (stack.size() < 2)
          >>> >         return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
          >>> >
          >>> >     const CScriptNum scriptNumSidechainId(stacktop(
          >>> -1),fRequireMinimal);
          >>> >     uint8_t nSidechainId;
          >>> >     if (!checker.CheckSidechainId(scriptNumSidechainId,nSidechainId))
          >>> {
          >>> >         return set_error(serror, SCRIPT_ERR_UNKNOWN_SIDECHAIN);
          >>> >     }
          >>> >
          >>> >     // Check block hash
          >>> >     bool fHashCritical =
          >>> > checker.CheckCriticalHash(stacktop(-2),nSidechainId);
          >>> >     if (!fHashCritical) {
          >>> >         return set_error(serror, SCRIPT_ERR_UNSATISFIED_BRIBE);
          >>> >     }
          >>> >     break;
          >>> >  }
          >>> >
          >>> >
          >>> >
          >>> > https://github.com/Christewart/bitcoin/blob/94b6f33f2278c42d
          >>> 4d8758a3c8ffe2078e4ec933/src/script/interpreter.cpp#L427
          >>> >
          >>> > https://github.com/drivechain-project/bitcoin/pull/13
          >>> >
          >>> > ==Deployment==
          >>> >
          >>> > TODO
          >>> >
          >>> > ==Credits==
          >>> >
          >>> > Credit to Paul Sztorc for the original idea of Blind Merge Mined
          >>> sidechains.
          >>> >
          >>> > Credit to CryptAxe for writing the foundational layer of software for
          >>> > drivechains so I could implement OP_BRIBEVERIFY.
          >>> >
          >>> >
          >>> > ==References==
          >>> >
          >>> > Blind Merge Mined Sidechains -
          >>> > http://www.truthcoin.info/blog/blind-merged-mining/
          >>> > Mailing list discussion -
          >>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
          >>> -May/014408.html
          >>> >
          >>> > ==Copyright==
          >>> >
          >>> > This document is placed in the public domain.
          >>> >
          >>> >
          >>> > _______________________________________________
          >>> > bitcoin-dev mailing list
          >>> > bitcoin-dev@lists•linuxfoundation.org
          >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          >>> >
          >>> _______________________________________________
          >>> bitcoin-dev mailing list
          >>> bitcoin-dev@lists•linuxfoundation.org
          >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          >>>
          >>
          >>
          >
          
          [-- Attachment #2: Type: text/html, Size: 20172 bytes --]
          
          ^ permalink raw reply	[flat|nested] 25+ messages in thread

    • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
        2017-06-28 22:20   ` Paul Sztorc
        2017-06-28 22:49     ` Russell O'Connor
      @ 2017-06-30  4:00     ` ZmnSCPxj
        2017-06-30 14:12       ` Chris Stewart
                               ` (2 more replies)
        1 sibling, 3 replies; 25+ messages in thread
      From: ZmnSCPxj @ 2017-06-30  4:00 UTC (permalink / raw)
        To: Paul Sztorc; +Cc: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 2335 bytes --]
      
      Good Morning Paul,
      >It seems that, in your version, the "bribers" would react to the scheme
      >in inefficient ways, particularly when the mainchain"s tx-fee-rate (ie
      >fee per Kb) is low.
      >
      >In short, there would be many bribe-attempts (each of which would take
      >up space in mainchain blocks), almost all of which would be unsuccessful.
      >
      >In turn, miners would likely react to this, and try to improve the state
      >of affairs by offering users the privilege of occupying transaction slot
      >#2 (ie, the one right after the coinbase). Users would need to trust
      >miners for this, which introduces a cost friction which is pure
      >deadweight loss. And, it might be easier for larger/older miners to be
      >trustworthy than smaller/newer ones.
      I understand.
      >Your way is actually very similar to mine. Mine _forces_ the bribe to be
      >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
      >do anything to refund the briber, if the sidechain (but not the
      >mainchain) reorganizes (as it can easily do, if an older sidechain
      >parent is extended while the mainchain proceeds normally). This creates
      >additional risk.
      I don't understand this part. In my scheme, a sidechain cannot reorganize unless the mainchain reorganizes, since the consensus loop only cares about matching the current block; it ignores splits and does not consider them valid.
      But I suppose you are considering something like the Ethereum mutability feature, which I do not think is something you would want in a sidechain.
      >I think mine is also much more space-efficient. Even if ours each had
      >exactly one h* per sidechain per block, it seems that I only require one
      >hash to be communicated (plus an indicator byte, and a ~2 byte counter
      >for the ratchet), whereas you require two. Since its overhead per
      >sidechain per block, it actually might really add up.
      Do you not provide a single sidechain's h* twice in the block? Once in the coinbase and once in the briber's separate transaction?
      In my scheme at least there is no indicator byte -- the "previous block" hash is the indicator of which sidechain it is extending. From your other emails on this list, it seems the ratchet is for withdrawals from sidechain to mainchain? If so, should it not only appear in only some of the sidechains (the ones which are currently doing some withdrawal?)?
      Regards,
      ZmnSCPxj
      
      [-- Attachment #2: Type: text/html, Size: 3030 bytes --]
      
      ^ permalink raw reply	[flat|nested] 25+ messages in thread

    • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
          2017-06-30  4:00     ` ZmnSCPxj
        @ 2017-06-30 14:12       ` Chris Stewart
          2017-06-30 16:51       ` CryptAxe
          2017-07-02 21:32       ` Paul Sztorc
          2 siblings, 0 replies; 25+ messages in thread
        From: Chris Stewart @ 2017-06-30 14:12 UTC (permalink / raw)
          To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 4444 bytes --]
        
        >I don't understand this part.  In my scheme, a sidechain cannot reorganize
        unless the mainchain reorganizes, since the consensus loop only cares about
        matching the current block; it ignores splits and does not consider them
        valid.
        
        Maybe I am misunderstanding you, but isn't this a flaw not a feature? What
        if a attacker pays a large fee to have his *invalid* block hash included in
        the bitcoin mainchain? Would this block *have* to be included in the
        sidechain's blockchain forever since *it was* included in bitcoin
        blockchain?
        
        >Do you not provide a single sidechain's h* twice in the block?  Once in
        the coinbase and once in the briber's separate transaction?
        
        Yes, my BIP proposal does this.
        
        >In my scheme at least there is no indicator byte -- the "previous block"
        hash is the indicator of which sidechain it is extending.  From your other
        emails on this list, it seems the ratchet is for withdrawals from sidechain
        to mainchain?  If so, should it not only appear in only some of the
        sidechains (the ones which are currently doing some withdrawal?)?
        
        Maybe I am missing something here, but why we do *explicitly* commit to the
        previous block hash? Isn't it implicitly committed to via SHA256(SHA256())?
        If a drivechain node tries to sync the drivechain from bitcoin's commitment
        headers, it will invalidate that block since
        the block hash does not correctly reference the previous block hash. AFAICT
        there is no need to explicitly specify the previous block hash in the OP_BV
        output. In general, I don't think we should assume these commitment headers
        dictate the strict ordering of blocks on the sidechain -- only potential
        blocks that
        *might* be valid. To guarantee full validity drivechain nodes will have to
        download the full block and figure out if they follow all of the consensus
        rules.
        
        This is sort of like headers first sync in bitcoin core:
        
        https://bitcoin.org/en/developer-guide#headers-first
        
        -Chris
        
        On Thu, Jun 29, 2017 at 11:00 PM, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
        
        > Good Morning Paul,
        >
        > >It seems that, in your version, the "bribers" would react to the scheme
        > >in inefficient ways, particularly when the mainchain"s tx-fee-rate (ie
        > >fee per Kb) is low.
        > >
        > >In short, there would be many bribe-attempts (each of which would take
        > >up space in mainchain blocks), almost all of which would be unsuccessful.
        > >
        > >In turn, miners would likely react to this, and try to improve the state
        > >of affairs by offering users the privilege of occupying transaction slot
        > >#2 (ie, the one right after the coinbase). Users would need to trust
        > >miners for this, which introduces a cost friction which is pure
        > >deadweight loss. And, it might be easier for larger/older miners to be
        > >trustworthy than smaller/newer ones.
        >
        > I understand.
        >
        > >Your way is actually very similar to mine. Mine _forces_ the bribe to be
        > >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
        > >do anything to refund the briber, if the sidechain (but not the
        > >mainchain) reorganizes (as it can easily do, if an older sidechain
        > >parent is extended while the mainchain proceeds normally). This creates
        > >additional risk.
        >
        > I don't understand this part.  In my scheme, a sidechain cannot reorganize
        > unless the mainchain reorganizes, since the consensus loop only cares about
        > matching the current block; it ignores splits and does not consider them
        > valid.
        >
        > But I suppose you are considering something like the Ethereum mutability
        > feature, which I do not think is something you would want in a sidechain.
        >
        > >I think mine is also much more space-efficient. Even if ours each had
        > >exactly one h* per sidechain per block, it seems that I only require one
        > >hash to be communicated (plus an indicator byte, and a ~2 byte counter
        > >for the ratchet), whereas you require two. Since its overhead per
        > >sidechain per block, it actually might really add up.
        >
        > Do you not provide a single sidechain's h* twice in the block?  Once in
        > the coinbase and once in the briber's separate transaction?
        >
        > In my scheme at least there is no indicator byte -- the "previous block"
        > hash is the indicator of which sidechain it is extending.  From your other
        > emails on this list, it seems the ratchet is for withdrawals from sidechain
        > to mainchain?  If so, should it not only appear in only some of the
        > sidechains (the ones which are currently doing some withdrawal?)?
        >
        >
        > Regards,
        > ZmnSCPxj
        >
        
        [-- Attachment #2: Type: text/html, Size: 6068 bytes --]
        
        ^ permalink raw reply	[flat|nested] 25+ messages in thread

      • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
          2017-06-30  4:00     ` ZmnSCPxj
          2017-06-30 14:12       ` Chris Stewart
        @ 2017-06-30 16:51       ` CryptAxe
          2017-07-02 21:32       ` Paul Sztorc
          2 siblings, 0 replies; 25+ messages in thread
        From: CryptAxe @ 2017-06-30 16:51 UTC (permalink / raw)
          To: ZmnSCPxj; +Cc: bitcoin-dev
        
        [-- Attachment #1: Type: text/plain, Size: 1179 bytes --]
        
        To ZmnSCPxj:
        
        I don't understand this part.  In my scheme, a sidechain cannot reorganize
        unless the mainchain reorganizes, since the consensus loop only cares about
        matching the current block; it ignores splits and does not consider them
        valid.
        
        But I suppose you are considering something like the Ethereum mutability
        feature, which I do not think is something you would want in a sidechain.
        
        
        The goal was to allow for sidechain reorgs without effecting the mainchain
        at all. With the ratchet system (WIP) the sidechain miners can either move
        the side chain forward or start a split at some previous sidechain block
        height. This happens as the main chain moves forward normally.
        
        From your other emails on this list, it seems the ratchet is for
        withdrawals from sidechain to mainchain?  ...
        
        
        The ratchet system is actually what links the h* data from bribes to
        sidechain blocks. h*'s (which are sidechain block hashes) are added to the
        ratchet system if they move the sidechain forward or start a split like I
        mentioned before. Then a sidechain can request of their local mainchain
        node to verify the headers they have downloaded from sidechain peers and
        form the side chain.
        
        [-- Attachment #2: Type: text/html, Size: 2592 bytes --]
        
        ^ permalink raw reply	[flat|nested] 25+ messages in thread

      • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
          2017-06-30  4:00     ` ZmnSCPxj
          2017-06-30 14:12       ` Chris Stewart
          2017-06-30 16:51       ` CryptAxe
        @ 2017-07-02 21:32       ` Paul Sztorc
          2017-07-04  7:21         ` ZmnSCPxj
          2 siblings, 1 reply; 25+ messages in thread
        From: Paul Sztorc @ 2017-07-02 21:32 UTC (permalink / raw)
          To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
        
        Hi,
        
        Sorry for the delay, I overlooked this email until now. I see that Chris
        and CryptAxe both answered but I will also answer, because the message
        was addressed to me.
        
        On 6/30/2017 12:00 AM, ZmnSCPxj wrote:
        > >Your way is actually very similar to mine. Mine _forces_ the bribe to be
        > >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
        > >do anything to refund the briber, if the sidechain (but not the
        > >mainchain) reorganizes (as it can easily do, if an older sidechain
        > >parent is extended while the mainchain proceeds normally). This creates
        > >additional risk.
        >
        > I don't understand this part.  In my scheme, a sidechain cannot
        > reorganize unless the mainchain reorganizes, since the consensus loop
        > only cares about matching the current block; it ignores splits and
        > does not consider them valid.
        
        If I've understood you correctly, you have said that each OP Return
        links the (ex)-latest block to a brand new block, and that whichever
        message of this kind comes first (in the mainchain) wins and the rest
        are discarded.
        
        So what if I had a sidechain represented by a jumble of capital letters,
        discarded entries as lowercase letters.
        
        Mainchain Block #200001:  [0 --> Q], [0 -->v], [0 -->s], [0 -->b],
        Mainchain Block #200002:  [Q --> H], [Q --> z],
        Mainchain Block #200003:  [H --> F]
        Mainchain Block #200004:  [F --> J], [F -->w]
        Mainchain Block #200005:  [H --> P], [J -->x]
        Mainchain Block #200006:  [P --> D]
        
        Isn't the chain {{ Q --> H --> F --> J  }} now starting to reorg, with a
        competing chain {{ Q --> H --> P --> D  }} ?
        
        > But I suppose you are considering something like the Ethereum
        > mutability feature, which I do not think is something you would want
        > in a sidechain.
        
        What I do want to do, is retain the existing model to some extent.
        Specifically, to the degree where sidechains could salvage some bad
        situations (eg value overflow incident, or March 2013 incident).
        
        > >I think mine is also much more space-efficient. Even if ours each had
        > >exactly one h* per sidechain per block, it seems that I only require one
        > >hash to be communicated (plus an indicator byte, and a ~2 byte counter
        > >for the ratchet), whereas you require two. Since its overhead per
        > >sidechain per block, it actually might really add up.
        >
        > Do you not provide a single sidechain's h* twice in the block?  Once
        > in the coinbase and once in the briber's separate transaction?
        That is a good point. Technically, we do include it twice, but the
        second instance (briber-transaction) can be "shuffled" out if the
        counterparties are part of the same Lightning Network (which I expect to
        the be the case, in equilibrium).
        
        >
        > In my scheme at least there is no indicator byte -- the "previous
        > block" hash is the indicator of which sidechain it is extending.  From
        > your other emails on this list, it seems the ratchet is for
        > withdrawals from sidechain to mainchain?  If so, should it not only
        > appear in only some of the sidechains (the ones which are currently
        > doing some withdrawal?)?
        
        No, sorry. There are many tangled issues (Drivechain (total system);
        side-to-main withdrawals (OP CountACKs); individual Drivechains
        themselves; Blind Merged Mining (OP BribeVerify)). The ratchet is not
        about withdrawals, it is exclusively about Blind Merged Mining, and
        making a better OP BribeVerify that offers better guarantees to both sides.
        
        Paul
        
        
        
        ^ permalink raw reply	[flat|nested] 25+ messages in thread

      • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
            2017-07-02 21:32       ` Paul Sztorc
          @ 2017-07-04  7:21         ` ZmnSCPxj
            2017-07-04 15:06           ` Chris Stewart
            0 siblings, 1 reply; 25+ messages in thread
          From: ZmnSCPxj @ 2017-07-04  7:21 UTC (permalink / raw)
            To: Paul Sztorc; +Cc: Bitcoin Protocol Discussion
          
          [-- Attachment #1: Type: text/plain, Size: 7142 bytes --]
          
          Good morning Paul, Chris, and CryptAxe,
          @Paul
          >> >Your way is actually very similar to mine. Mine _forces_ the bribe to be
          >> >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
          >> >do anything to refund the briber, if the sidechain (but not the
          >> >mainchain) reorganizes (as it can easily do, if an older sidechain
          >> >parent is extended while the mainchain proceeds normally). This creates
          >> >additional risk.
          >>
          >> I don"t understand this part. In my scheme, a sidechain cannot
          >> reorganize unless the mainchain reorganizes, since the consensus loop
          >> only cares about matching the current block; it ignores splits and
          >> does not consider them valid.
          >
          >If I"ve understood you correctly, you have said that each OP Return
          >links the (ex)-latest block to a brand new block, and that whichever
          >message of this kind comes first (in the mainchain) wins and the rest
          >are discarded.
          >
          >So what if I had a sidechain represented by a jumble of capital letters,
          >discarded entries as lowercase letters.
          >
          >Mainchain Block #200001: [0 --> Q], [0 -->v], [0 -->s], [0 -->b],
          >Mainchain Block #200002: [Q --> H], [Q --> z],
          >Mainchain Block #200003: [H --> F]
          >Mainchain Block #200004: [F --> J], [F -->w]
          >Mainchain Block #200005: [H --> P], [J -->x]
          >Mainchain Block #200006: [P --> D]
          >
          >Isn"t the chain {{ Q --> H --> F --> J }} now starting to reorg, with a
          >competing chain {{ Q --> H --> P --> D }} ?
          No, because at block #20005, the topmost sidechain block is J, not H, and the H->P will not be considered as valid -- only the J->x is valid, even though H->P comes first.
          Please see the pseudocode I sent before in detail and consider how it will work with your given mainchain blocks example.
          >> But I suppose you are considering something like the Ethereum
          >> mutability feature, which I do not think is something you would want
          >> in a sidechain.
          >
          >What I do want to do, is retain the existing model to some extent.
          >Specifically, to the degree where sidechains could salvage some bad
          >situations (eg value overflow incident, or March 2013 incident).
          I suppose some kinds of mutability are desirable. In my model, a sidechain reorg can be forced if the sidechain code is forked to specifically force some previously-valid block to become invalid, by developer fiat. In the example you gave, basically, if you want to reorg from Q->H->F->J to Q->H->P->D then you would fork the sidechain consensus code to declare that block F is invalid.
          I am hesitant to make mutability something that is easy to force, however.
          >> >I think mine is also much more space-efficient. Even if ours each had
          >> >exactly one h* per sidechain per block, it seems that I only require one
          >> >hash to be communicated (plus an indicator byte, and a ~2 byte counter
          >> >for the ratchet), whereas you require two. Since its overhead per
          >> >sidechain per block, it actually might really add up.
          >>
          >> Do you not provide a single sidechain"s h* twice in the block? Once
          >> in the coinbase and once in the briber"s separate transaction?
          >
          >That is a good point. Technically, we do include it twice, but the
          >second instance (briber-transaction) can be "shuffled" out if the
          >counterparties are part of the same Lightning Network (which I expect to
          >the be the case, in equilibrium).
          Payments on LN are finalized when the payee provides a preimage for a hashlock, whether by chain or by LN. Although I suppose you can use a bribelocked timelocked contract instead of a hashlocked timelocked contract. I suppose it would be almost the same, except the bribelock is provided off-chain as a proof of existence in a mainblock coinbase.
          In addition, it may be possible to create a payment channel specifically between a sidechain operator and a mainchain miner.
          >> In my scheme at least there is no indicator byte -- the "previous
          >> block" hash is the indicator of which sidechain it is extending. From
          >> your other emails on this list, it seems the ratchet is for
          >> withdrawals from sidechain to mainchain? If so, should it not only
          >> appear in only some of the sidechains (the ones which are currently
          >> doing some withdrawal?)?
          >
          >No, sorry. There are many tangled issues (Drivechain (total system);
          >side-to-main withdrawals (OP CountACKs); individual Drivechains
          >themselves; Blind Merged Mining (OP BribeVerify)). The ratchet is not
          >about withdrawals, it is exclusively about Blind Merged Mining, and
          >making a better OP BribeVerify that offers better guarantees to both sides.
          Can you describe the ratchet better? I am sorry but when I first heard of "blind" merge mining, the first thing that came to mind was the use of OP_RETURN. This is truly blind as the mainchain miner is given what is effectively a blob of data, and the mainchain miner cannot expect any kind of format from OP_RETURN. This has the tremendous advantage of not even requiring a softfork.
          @Chris
          >What if a attacker pays a large fee to have his *invalid* block hash included in the bitcoin mainchain? Would this block *have* to be included in the sidechain's blockchain forever since *it was* included in bitcoin blockchain?
          In my scheme, if you read carefully through the pseudocode, a block list node is valid only if its block is valid.
          Basically, in my scheme, the OP_RETURN data *is* the sidechain block headers stored on the mainchain. To save space, the sidechain block headers are reduced to only the previous-block-header commitment and the current-block-data commitment. All of the other data you would want to put in the block header (e.g. UTXO set commitment, signalling bits, time-of-day...) would be part of the current-block-data instead of the block header. Thus if the current-block-data is invalid the sidechain block header is invalid and another sidechain block header based on the previous block header will be searched for.
          My understanding is that your attack scenario is not helped by OP_BRIBEVERIFY alone, as a rich sidechain attacker can provide a bigger bribe to an invalid h* especially since the mainchain miner will not even check the h*, just insert it into the coinbase.
          >Maybe I am missing something here, but why we do *explicitly* commit to the previous block hash? Isn't it implicitly committed to via SHA256(SHA256())?
          In order to eliminate having to specify a sidechain index, and to remove sidechain indexes altogether. Instead the sidechain is identified by its topmost block header hash.
          @CryptAxe
          >The ratchet system is actually what links the h* data from bribes to sidechain blocks. h*'s (which are sidechain block hashes) are added to the ratchet system if they move the sidechain forward or start a split like I mentioned before. Then a sidechain can request of their local mainchain node to verify the headers they have downloaded from sidechain peers and form the side chain.
          I see. However, then, I propose that my OP_RETURN scheme is superior as the sidechain block headers are indeed visible directly on the mainchain, and the mainchain node does not even need to be "local", but can be sourced anywhere, without requiring a ratchet structure (whose purpose I still have not managed to grok).
          Regards,
          ZmnSCPxj
          
          [-- Attachment #2: Type: text/html, Size: 9187 bytes --]
          
          ^ permalink raw reply	[flat|nested] 25+ messages in thread

        • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
              2017-07-04  7:21         ` ZmnSCPxj
            @ 2017-07-04 15:06           ` Chris Stewart
              2017-07-12  8:50             ` ZmnSCPxj
              0 siblings, 1 reply; 25+ messages in thread
            From: Chris Stewart @ 2017-07-04 15:06 UTC (permalink / raw)
              To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
            
            [-- Attachment #1: Type: text/plain, Size: 10517 bytes --]
            
            Hi ZmnSCPxj,
            
            
            In my scheme, if you read carefully through the pseudocode, a block list
            > node is valid only if its block is valid.
            >
            
            It seems this is a contradiction against the "blind" part of blind merge
            mining. How can a bitcoin blockchain node enforce this without tracking the
            sidechain?
            
            Basically, in my scheme, the OP_RETURN data *is* the sidechain block
            > headers stored on the mainchain.  To save space, the sidechain block
            > headers are reduced to only the previous-block-header commitment and the
            > current-block-data commitment.  All of the other data you would want to put
            > in the block header (e.g. UTXO set commitment, signalling bits,
            > time-of-day...) would be part of the current-block-data instead of the
            > block header.  Thus if the current-block-data is invalid the sidechain
            > block header is invalid and another sidechain block header based on the
            > previous block header will be searched for.
            
            
            It seems both of our schemes need to include 2 32 bit hashes in the
            blockchain. Your scheme needs a previous block header hash and the current
            block header hash, while mine includes the current block header hash
            twice.  We can just commit to all that information via the block header
            hash and if a sidechain node lies to us will we are doing IBD the hashes
            won't match with what was included in the bitcoin blockchain.
            
            I'll follow your discussion with Paul about sidechain reorgs, but I think
            his proposal is more desirable -- it follows what actually happens in the
            bitcoin mining process where we *can* have chain splits when miners
            simultaneously find a block. Other miners will pick one of the two blocks
            to mine on top of and eventually one chain will become longer than the
            other. Therefore that chain will have it's block's orphaned and the
            miners/nodes following the dead chain will reorg on top of the longest
            chain.
            
            In Paul's scheme, we replace PoW with a bribe. At the conceptual level
            these are somewhat similar. In PoW a miner is willing to pay a certain
            amount of money (on electricity) to try to find a bitcoin block. With
            OP_BRIBEVERIFY a sidechain miner is willing pay a certain amount of money
            to find a block.
            
            In PoW, there is nothing at the software level that says a miner cannot
            just decide to build on a old block. I could decide to build on the genesis
            block if I wanted to. Obviously this is a stupid idea as I'll never
            overtake the bitcoin blockchain with 8 years of PoW behind it -- but it
            doesn't mean I couldn't try if I wanted too. Your scheme from what I
            understand prevents this from happening -- and I don't think that is
            desirable. You might be able to make an argument that a rich attacker can
            *stall* mining progress on the drivechain, but I think the same argument
            can be made with a rich miner on the bitcoin blockchain as well. I think
            miners have threatened to do that if BIP148 caused a chain split.
            
            Can you link to the aforementioned pseudocode? I must have missed it on the
            mailing list.
            
            -Chris
            
            On Tue, Jul 4, 2017 at 2:21 AM, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
            
            > Good morning Paul, Chris, and CryptAxe,
            >
            > @Paul
            >
            > >> >Your way is actually very similar to mine. Mine _forces_ the bribe to
            > be
            > >> >in the earliest txn (the coinbase) and to only occur once. Yours
            > doesn"t
            > >> >do anything to refund the briber, if the sidechain (but not the
            > >> >mainchain) reorganizes (as it can easily do, if an older sidechain
            > >> >parent is extended while the mainchain proceeds normally). This creates
            > >> >additional risk.
            > >>
            > >> I don"t understand this part. In my scheme, a sidechain cannot
            > >> reorganize unless the mainchain reorganizes, since the consensus loop
            > >> only cares about matching the current block; it ignores splits and
            > >> does not consider them valid.
            > >
            > >If I"ve understood you correctly, you have said that each OP Return
            > >links the (ex)-latest block to a brand new block, and that whichever
            > >message of this kind comes first (in the mainchain) wins and the rest
            > >are discarded.
            > >
            > >So what if I had a sidechain represented by a jumble of capital letters,
            > >discarded entries as lowercase letters.
            > >
            > >Mainchain Block #200001: [0 --> Q], [0 -->v], [0 -->s], [0 -->b],
            > >Mainchain Block #200002: [Q --> H], [Q --> z],
            > >Mainchain Block #200003: [H --> F]
            > >Mainchain Block #200004: [F --> J], [F -->w]
            > >Mainchain Block #200005: [H --> P], [J -->x]
            > >Mainchain Block #200006: [P --> D]
            > >
            > >Isn"t the chain {{ Q --> H --> F --> J }} now starting to reorg, with a
            > >competing chain {{ Q --> H --> P --> D }} ?
            >
            > No, because at block #20005, the topmost sidechain block is J, not H, and
            > the H->P will not be considered as valid -- only the J->x is valid, even
            > though H->P comes first.
            >
            > Please see the pseudocode I sent before in detail and consider how it will
            > work with your given mainchain blocks example.
            >
            >
            > >> But I suppose you are considering something like the Ethereum
            > >> mutability feature, which I do not think is something you would want
            > >> in a sidechain.
            > >
            > >What I do want to do, is retain the existing model to some extent.
            > >Specifically, to the degree where sidechains could salvage some bad
            > >situations (eg value overflow incident, or March 2013 incident).
            >
            > I suppose some kinds of mutability are desirable.  In my model, a
            > sidechain reorg can be forced if the sidechain code is forked to
            > specifically force some previously-valid block to become invalid, by
            > developer fiat.  In the example you gave, basically, if you want to reorg
            > from Q->H->F->J to Q->H->P->D then you would fork the sidechain consensus
            > code to declare that block F is invalid.
            >
            > I am hesitant to make mutability something that is easy to force, however.
            >
            > >> >I think mine is also much more space-efficient. Even if ours each had
            > >> >exactly one h* per sidechain per block, it seems that I only require
            > one
            > >> >hash to be communicated (plus an indicator byte, and a ~2 byte counter
            > >> >for the ratchet), whereas you require two. Since its overhead per
            > >> >sidechain per block, it actually might really add up.
            > >>
            > >> Do you not provide a single sidechain"s h* twice in the block? Once
            > >> in the coinbase and once in the briber"s separate transaction?
            > >
            > >That is a good point. Technically, we do include it twice, but the
            > >second instance (briber-transaction) can be "shuffled" out if the
            > >counterparties are part of the same Lightning Network (which I expect to
            > >the be the case, in equilibrium).
            >
            > Payments on LN are finalized when the payee provides a preimage for a
            > hashlock, whether by chain or by LN.  Although I suppose you can use a
            > bribelocked timelocked contract instead of a hashlocked timelocked
            > contract.  I suppose it would be almost the same, except the bribelock is
            > provided off-chain as a proof of existence in a mainblock coinbase.
            >
            > In addition, it may be possible to create a payment channel specifically
            > between a sidechain operator and a mainchain miner.
            >
            > >> In my scheme at least there is no indicator byte -- the "previous
            > >> block" hash is the indicator of which sidechain it is extending. From
            > >> your other emails on this list, it seems the ratchet is for
            > >> withdrawals from sidechain to mainchain? If so, should it not only
            > >> appear in only some of the sidechains (the ones which are currently
            > >> doing some withdrawal?)?
            > >
            > >No, sorry. There are many tangled issues (Drivechain (total system);
            > >side-to-main withdrawals (OP CountACKs); individual Drivechains
            > >themselves; Blind Merged Mining (OP BribeVerify)). The ratchet is not
            > >about withdrawals, it is exclusively about Blind Merged Mining, and
            > >making a better OP BribeVerify that offers better guarantees to both
            > sides.
            >
            > Can you describe the ratchet better?  I am sorry but when I first heard of
            > "blind" merge mining, the first thing that came to mind was the use of
            > OP_RETURN.  This is truly blind as the mainchain miner is given what is
            > effectively a blob of data, and the mainchain miner cannot expect any kind
            > of format from OP_RETURN.  This has the tremendous advantage of not even
            > requiring a softfork.
            >
            >
            > @Chris
            >
            > >What if a attacker pays a large fee to have his *invalid* block hash
            > included in the bitcoin mainchain? Would this block *have* to be included
            > in the sidechain's blockchain forever since *it was* included in bitcoin
            > blockchain?
            >
            > In my scheme, if you read carefully through the pseudocode, a block list
            > node is valid only if its block is valid.
            >
            > Basically, in my scheme, the OP_RETURN data *is* the sidechain block
            > headers stored on the mainchain.  To save space, the sidechain block
            > headers are reduced to only the previous-block-header commitment and the
            > current-block-data commitment.  All of the other data you would want to put
            > in the block header (e.g. UTXO set commitment, signalling bits,
            > time-of-day...) would be part of the current-block-data instead of the
            > block header.  Thus if the current-block-data is invalid the sidechain
            > block header is invalid and another sidechain block header based on the
            > previous block header will be searched for.
            >
            > My understanding is that your attack scenario is not helped by
            > OP_BRIBEVERIFY alone, as a rich sidechain attacker can provide a bigger
            > bribe to an invalid h* especially since the mainchain miner will not even
            > check the h*, just insert it into the coinbase.
            >
            > >Maybe I am missing something here, but why we do *explicitly* commit to
            > the previous block hash? Isn't it implicitly committed to via
            > SHA256(SHA256())?
            >
            > In order to eliminate having to specify a sidechain index, and to remove
            > sidechain indexes altogether.  Instead the sidechain is identified by its
            > topmost block header hash.
            >
            >
            > @CryptAxe
            >
            > >The ratchet system is actually what links the h* data from bribes to
            > sidechain blocks. h*'s (which are sidechain block hashes) are added to the
            > ratchet system if they move the sidechain forward or start a split like I
            > mentioned before. Then a sidechain can request of their local mainchain
            > node to verify the headers they have downloaded from sidechain peers and
            > form the side chain.
            >
            > I see.  However, then, I propose that my OP_RETURN scheme is superior as
            > the sidechain block headers are indeed visible directly on the mainchain,
            > and the mainchain node does not even need to be "local", but can be sourced
            > anywhere, without requiring a ratchet structure (whose purpose I still have
            > not managed to grok).
            >
            > Regards,
            > ZmnSCPxj
            >
            >
            
            [-- Attachment #2: Type: text/html, Size: 13239 bytes --]
            
            ^ permalink raw reply	[flat|nested] 25+ messages in thread

          • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
                2017-07-04 15:06           ` Chris Stewart
              @ 2017-07-12  8:50             ` ZmnSCPxj
                2017-07-12 13:39               ` Russell O'Connor
                2017-07-12 23:31               ` Paul Sztorc
                0 siblings, 2 replies; 25+ messages in thread
              From: ZmnSCPxj @ 2017-07-12  8:50 UTC (permalink / raw)
                To: Chris Stewart; +Cc: Bitcoin Protocol Discussion
              
              [-- Attachment #1: Type: text/plain, Size: 4091 bytes --]
              
              >>In my scheme, if you read carefully through the pseudocode, a block list node is valid only if its block is valid.
              >
              >It seems this is a contradiction against the "blind" part of blind merge mining. How can a bitcoin blockchain node enforce this without tracking the sidechain?
              From: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014668.html
              >>>>2. When a sidechain-node wants to know the consensus, it downloads mainchain-blocks and looks for OP_RETURN's.
              >>>>2.1. Starting with its genesis cons-pair hash (equivalent to the empty list) as the current cons-pair, it scans each OP_RETURN transaction.
              >>>>2.1.1. If an OP_RETURN is 64-byte and has the parent cons-pair equal to the current cons-pair, look for the side block indicated and confirm its correctness. If correct, update the current cons-pair for the hash of the OP_RETURN data.
              >>>>2.2. When reaching the latest mainchain block, the current cons-pair is now the sidecoin/altcoin latest block.
              >>>>2.3. Note that if multiple OP_RETURN in a block match the current cons-pair, the first one is considered the correct chain. This property means that the sidechain/altchain can only have a chainsplit if the mainchain has a chainsplit.
              It's the sidechain node which needs to learn about the sidechain blockchain anyway. So it's the one that does the checking of this.
              For that matter, a mainchain miner can be bribed to commit to a random number rather than a valid h* block, and it will still lead all the sidechain nodes on a random chase to look for the indicated block.
              >I'll follow your discussion with Paul about sidechain reorgs, but I think his proposal is more desirable -- it follows what actually happens in the bitcoin mining process where we *can* have chain splits when
              >miners simultaneously find a block. Other miners will pick one of the two blocks to mine on top of and eventually one chain will become longer than the other. Therefore that chain will have it's block's
              >orphaned and the miners/nodes following the dead chain will reorg on top of the longest chain.
              In this paper: http://diyhpl.us/~bryan/papers2/bitcoin/On%20the%20instability%20of%20Bitcoin%20without%20the%20block%20reward%20-%202016.pdf
              As far as I understood that paper, it means that if the block reward no longer exists, miners can profitably attempt to undercut any full blocks.
              Sidechains do not have block rewards (unless the sidechain issues its own asset type that is separate from and not convertible to mainchain bitcoins).
              Thus, to protect against undercutting attacks in the sidechain, we would need to ensure that the sidechain cannot be reorged without the mainchain (which currently still has a block reward) being reorged.
              At least, this is my consideration. Perhaps the paper is wrong?
              ---
              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.
              3. Don't number sidechain_id from 0, 1, 2, 3..., because people will fight over the small numbers. Instead identify sidechains by, for example, the hash of their names or the hash of their genesis block or whatever. This allows true permissionless creation of sidechains, without some authority existing that centrally allocates sidechain ID's.
              Regards,
              ZmnSCPxj
              
              [-- Attachment #2: Type: text/html, Size: 5131 bytes --]
              
              ^ permalink raw reply	[flat|nested] 25+ messages in thread

            • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
                  2017-07-12  8:50             ` ZmnSCPxj
                @ 2017-07-12 13:39               ` Russell O'Connor
                       [not found]                 ` <CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>
                  2017-07-12 23:31               ` Paul Sztorc
                  1 sibling, 1 reply; 25+ messages in thread
                From: Russell O'Connor @ 2017-07-12 13:39 UTC (permalink / raw)
                  To: ZmnSCPxj, Bitcoin Protocol Discussion
                
                [-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
                
                On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <
                bitcoin-dev@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.
                
                [-- Attachment #2: Type: text/html, Size: 1803 bytes --]
                
                ^ permalink raw reply	[flat|nested] 25+ messages in thread

              • • [parent not found: <CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>]

                • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
                           [not found]                 ` <CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>
                    @ 2017-07-12 18:02                   ` Chris Stewart
                      2017-07-13  0:00                     ` Paul Sztorc
                      0 siblings, 1 reply; 25+ messages in thread
                    From: Chris Stewart @ 2017-07-12 18:02 UTC (permalink / raw)
                      To: Russell O'Connor, Bitcoin Protocol Discussion
                    
                    [-- Attachment #1: Type: text/plain, Size: 4618 bytes --]
                    
                    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@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@lists•linuxfoundation.org> wrote:
                    >
                    >>
                    >>
                    >> On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <
                    >> bitcoin-dev@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@lists•linuxfoundation.org
                    >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                    >>
                    >>
                    >
                    
                    [-- Attachment #2: Type: text/html, Size: 6531 bytes --]
                    
                    ^ permalink raw reply	[flat|nested] 25+ messages in thread

                  • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
                        2017-07-12 18:02                   ` Chris Stewart
                      @ 2017-07-13  0:00                     ` Paul Sztorc
                        2017-07-13 20:22                       ` Chris Stewart
                        0 siblings, 1 reply; 25+ messages in thread
                      From: Paul Sztorc @ 2017-07-13  0:00 UTC (permalink / raw)
                        To: Chris Stewart, Bitcoin Protocol Discussion, Russell O'Connor
                      
                      [-- Attachment #1: Type: text/plain, Size: 2183 bytes --]
                      
                      I still think it may be more inefficient, in equilibrium. (In other
                      words, in the future steady state of Bitcoin that includes LN or
                      something LN-like).
                      
                      Assume there are N sidechains.
                      
                      In the coinbase version:
                      1. There is some single event, per N, that causes nodes to notice that a
                      new sidechain has been created.
                      2. Per block, there are N hash commitments (32 bytes) and N instances of
                      the ratchet's block counter (2 bytes).
                      3. Per block, some node operator _may_ have BMMed the block, and a miner
                      therefore might want redeem an OP Bribe that pays BTC from a sidechain
                      node operator to the miner. But they are likely to negotiate the payment
                      through the Lightning Network (when this is possible).
                      4. Sidechains running in SPV mode know exactly where to find the
                      information they need in order to discover the "longest" chain.
                      
                      In the OP RETURN version:
                      1. [same] There is some single event, per N, that causes nodes to notice
                      that a new sidechain has been created.
                      2. [+30 bytes (+more?)] Per block, there are N hash commitments (32
                      bytes) and also N prevBlockHashes (32 bytes). Also, to make this
                      transaction, someone needs to spend something in the UTXO set (or select
                      no inputs in a kind of 'hollow transaction'), whereas one coinbase will
                      always exist per block.
                      3. [same] No need for a new transaction.
                      4. [same?] Due to Rusty's soft fork rule of only one h* per sidechain
                      per block, sidechains need just a merkle tree path, but they don't
                      necessarily know where it is. They must store extra [?] data to help
                      them find the data's location?
                      
                      
                      On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev 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.
                      
                      I think that that is the purpose of Rusty's soft fork rule about only
                      including one per sidechain -- miners would have one "slot" per
                      sidechain, and they would therefore have an incentive to make the slot
                      count, and would be only selecting the highest fee txn to fill each slot.
                      
                      [-- Attachment #2: Type: text/html, Size: 3215 bytes --]
                      
                      ^ permalink raw reply	[flat|nested] 25+ messages in thread

                    • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
                          2017-07-13  0:00                     ` Paul Sztorc
                        @ 2017-07-13 20:22                       ` Chris Stewart
                          2017-07-13 20:45                         ` Paul Sztorc
                          0 siblings, 1 reply; 25+ messages in thread
                        From: Chris Stewart @ 2017-07-13 20:22 UTC (permalink / raw)
                          To: Paul Sztorc; +Cc: Bitcoin Protocol Discussion
                        
                        [-- Attachment #1: Type: text/plain, Size: 3092 bytes --]
                        
                        I'm interested in hearing a reply from Russell/ZmnSCPxj in what they think
                        about lightning bribes. I hadn't given much thought about those while
                        writing my original BIP, but it does seem like my original BIP (minus the
                        fixed indexes in the coinbase output) fits this pretty well. If I
                        understand Paul correctly the OP_BV output will never hit the blockchain
                        then -- only the commitment in the coinbase transaction. This means no
                        extra data (if use lightning) has to be added to the blockchain *except*
                        the drivechain commitment (34 bytes in the coinbase tx vout). If this is
                        used for the vast majority bribes it may make the op code worth it.
                        
                        In general though, I'm still unclear of what purpose the 'Ratchet' serves.
                        Can you either link to documentation about it or write something up quick?
                        
                        -Chris
                        
                        On Wed, Jul 12, 2017 at 7:00 PM, Paul Sztorc <truthcoin@gmail•com> wrote:
                        
                        > I still think it may be more inefficient, in equilibrium. (In other words,
                        > in the future steady state of Bitcoin that includes LN or something
                        > LN-like).
                        >
                        > Assume there are N sidechains.
                        >
                        > In the coinbase version:
                        > 1. There is some single event, per N, that causes nodes to notice that a
                        > new sidechain has been created.
                        > 2. Per block, there are N hash commitments (32 bytes) and N instances of
                        > the ratchet's block counter (2 bytes).
                        > 3. Per block, some node operator _may_ have BMMed the block, and a miner
                        > therefore might want redeem an OP Bribe that pays BTC from a sidechain node
                        > operator to the miner. But they are likely to negotiate the payment through
                        > the Lightning Network (when this is possible).
                        > 4. Sidechains running in SPV mode know exactly where to find the
                        > information they need in order to discover the "longest" chain.
                        >
                        > In the OP RETURN version:
                        > 1. [same] There is some single event, per N, that causes nodes to notice
                        > that a new sidechain has been created.
                        > 2. [+30 bytes (+more?)] Per block, there are N hash commitments (32 bytes)
                        > and also N prevBlockHashes (32 bytes). Also, to make this transaction,
                        > someone needs to spend something in the UTXO set (or select no inputs in a
                        > kind of 'hollow transaction'), whereas one coinbase will always exist per
                        > block.
                        > 3. [same] No need for a new transaction.
                        > 4. [same?] Due to Rusty's soft fork rule of only one h* per sidechain per
                        > block, sidechains need just a merkle tree path, but they don't necessarily
                        > know where it is. They must store extra [?] data to help them find the
                        > data's location?
                        >
                        >
                        > On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev 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.
                        >
                        >
                        > I think that that is the purpose of Rusty's soft fork rule about only
                        > including one per sidechain -- miners would have one "slot" per sidechain,
                        > and they would therefore have an incentive to make the slot count, and
                        > would be only selecting the highest fee txn to fill each slot.
                        >
                        
                        [-- Attachment #2: Type: text/html, Size: 4460 bytes --]
                        
                        ^ permalink raw reply	[flat|nested] 25+ messages in thread

                      • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
                            2017-07-13 20:22                       ` Chris Stewart
                          @ 2017-07-13 20:45                         ` Paul Sztorc
                            0 siblings, 0 replies; 25+ messages in thread
                          From: Paul Sztorc @ 2017-07-13 20:45 UTC (permalink / raw)
                            To: Chris Stewart; +Cc: Bitcoin Protocol Discussion
                          
                          On 7/13/2017 4:22 PM, Chris Stewart wrote:
                          > In general though, I'm still unclear of what purpose the 'Ratchet'
                          > serves. Can you either link to documentation about it or write
                          > something up quick?
                          >
                          > -Chris
                          
                          In Bitcoin, new coins are held for 100 blocks. One result of this is
                          that the coins can't be spent until there is at least 100 blocks worth
                          of evidence that they actually are in the longest chain, and are
                          unlikely to be orphaned.
                          
                          In BMM, we are concerned about exactly this. For example, imagine that I
                          bribe you $20 to find my side:block (and, in that block I earn $20.50
                          worth of side:BTC tx fees), which you do. But then, moments later, you
                          (or some other miner) orphans the block! So I don't get my $20.50, but
                          you still keep my $20!
                          
                          And yet, we want the mainchain to validate as little as possible about
                          each sidechain. We want a "light touch". So we force the h* to be
                          accompanied by the modulus of its sidechain block number (we call it
                          "BlockMod"). The sidechain has a new rule that requires h* to be
                          included AND that the BlockMod be accurate, in order for the sidechain
                          block to meet the "synthetic" difficulty requirement. The mainchain has
                          a new rule forcing each new BlockMod to be in range [-X000,+1] relative
                          to the old BlockMod (ie, "no skipping ahead, but you can reorg by
                          starting a new chain from up to a=-X000 blocks ago" ... likely values of
                          X might be 2 or 4). And finally, BMM has a new rule that the bribe isn't
                          paid unless the sidechain block in question has been buried by [for
                          example] 100 sidechain blocks.
                          
                          Hope that helps,
                          Paul
                          
                          
                          
                          ^ permalink raw reply	[flat|nested] 25+ messages in thread

              • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
                  2017-07-12  8:50             ` ZmnSCPxj
                  2017-07-12 13:39               ` Russell O'Connor
                @ 2017-07-12 23:31               ` Paul Sztorc
                       [not found]                 ` <CAF5CFkg+mJQ75ps7f3Xa=j2eBDoNwFEdL-vFrFV5y_FqF3qGRA@mail.gmail.com>
                  1 sibling, 1 reply; 25+ messages in thread
                From: Paul Sztorc @ 2017-07-12 23:31 UTC (permalink / raw)
                  To: ZmnSCPxj, Chris Stewart; +Cc: Bitcoin Protocol Discussion
                
                On 7/12/2017 4:50 AM, ZmnSCPxj wrote:
                >
                > >>In my scheme, if you read carefully through the pseudocode, a block
                > list node is valid only if its block is valid.
                > >
                > >It seems this is a contradiction against the "blind" part of blind
                > merge mining. How can a bitcoin blockchain node enforce this without
                > tracking the sidechain?
                >
                > From:
                > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014668.html
                > >>>>2. When a sidechain-node wants to know the consensus, it downloads
                > mainchain-blocks and looks for OP_RETURN's.
                > >>>>2.1. Starting with its genesis cons-pair hash (equivalent to the
                > empty list) as the current cons-pair, it scans each OP_RETURN transaction.
                > >>>>2.1.1. If an OP_RETURN is 64-byte and has the parent cons-pair
                > equal to the current cons-pair, look for the side block indicated and
                > confirm its correctness. If correct, update the current cons-pair for
                > the hash of the OP_RETURN data.
                > >>>>2.2. When reaching the latest mainchain block, the current
                > cons-pair is now the sidecoin/altcoin latest block.
                > >>>>2.3. Note that if multiple OP_RETURN in a block match the current
                > cons-pair, the first one is considered the correct chain. This
                > property means that the sidechain/altchain can only have a chainsplit
                > if the mainchain has a chainsplit.
                >
                > It's the sidechain node which needs to learn about the sidechain
                > blockchain anyway.  So it's the one that does the checking of this.
                >
                > For that matter, a mainchain miner can be bribed to commit to a random
                > number rather than a valid h* block, and it will still lead all the
                > sidechain nodes on a random chase to look for the indicated block.
                
                I do agree with this description. And I am not exactly comfortable with
                it, but theoretically the random chase would serve no direct benefit to
                any attacker (and thus be a ~purposeless use of attacker's money), and
                empirically I do not recall anyone complaining about this happening in
                Namecoin. And I think it is generally agreed that low-conf transactions
                are of categorically lower reliability -- and therefore that we are
                relatively less interested in taking care of users who want the
                blockchain to provide them with...immediate gratification (for lack of a
                better term).
                
                
                > >I'll follow your discussion with Paul about sidechain reorgs, but I
                > think his proposal is more desirable -- it follows what actually
                > happens in the bitcoin mining process where we *can* have chain splits
                > when
                > >miners simultaneously find a block. Other miners will pick one of the
                > two blocks to mine on top of and eventually one chain will become
                > longer than the other. Therefore that chain will have it's block's
                > >orphaned and the miners/nodes following the dead chain will reorg on
                > top of the longest chain.
                >
                > In this paper:
                > http://diyhpl.us/~bryan/papers2/bitcoin/On%20the%20instability%20of%20Bitcoin%20without%20the%20block%20reward%20-%202016.pdf
                > <http://diyhpl.us/%7Ebryan/papers2/bitcoin/On%20the%20instability%20of%20Bitcoin%20without%20the%20block%20reward%20-%202016.pdf>
                >
                > As far as I understood that paper, it means that if the block reward
                > no longer exists, miners can profitably attempt to undercut any full
                > blocks.
                >
                > Sidechains do not have block rewards (unless the sidechain issues its
                > own asset type that is separate from and not convertible to mainchain
                > bitcoins).
                >
                > Thus, to protect against undercutting attacks in the sidechain, we
                > would need to ensure that the sidechain cannot be reorged without the
                > mainchain (which currently still has a block reward) being reorged.
                >
                > At least, this is my consideration.  Perhaps the paper is wrong?
                
                Yes, it is a valid concern. I'm glad you brought this up. My view is
                that there will be no undercutting attempts in the future, if Bitcoin is
                popular enough and transactions are constantly arriving.
                
                In short, the reason I feel that way is because miners will be both [1]
                willing and [2] able, to maximize their fee income by imposing a
                blocksize limit on themselves. They would do this by orphaning
                non-compliants -- this would be something softfork-esque, but not
                necessarily enforced by non-mining nodes as it is limited to miner
                tx-acceptance policy.
                
                Here is a link to a presentation of my thoughts on the issue:
                https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4
                
                As I say there, I believe that miners currently have no significant
                reason to fee-maximize today, which is why we haven't seen this
                behavior. (Also, someone would need to write the fee-maximization code
                for this, and that not only would take time, but it would require a
                person with a very complex intersection of skills.)
                
                The paper you mention was written 1.5 months after my presentation was
                recorded. My conclusion contradicts the first sentence of the last
                paragraph of "3.1 Model of the system" which reads: "We also assume that
                miners always have space to include all available transactions." In my
                model miners do NOT always (or, really, ever) have space to include all
                available transactions. And miners are happy that they do not, because
                all of them make more total money as a result (both per block and overall).
                
                I think the arguments of the presentation were original, so I would be
                grateful to you if you offered me your thoughts on it.
                
                
                > 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.
                
                I don't understand the word "anyway" in the second sentence. Is that a
                summary of my proposal, or an assertion of yours. Because as it stands,
                the bribe part is quite optional -- miners could just mine both chains
                themselves, and then they would know which h* to include, paying
                themselves the sidechain's tx fees. (Of course, under what you propose
                here, miners could also mine it themselves, by placing it in an
                OP_BRIBEVERIFY). However, if it is limited to a coinbase, then there is
                at most only 1 hash to process every 10 minutes, which I think is desirable.
                
                I like your idea as it is simpler. But a second concern I have is that
                if a sidechain user wants to use SPV mode, the software will want to
                know exactly where to find the sidechain headers. If they are always in
                a known part of the coinbase, then the spv sidechain wallet knows where
                to look.
                
                Re: impose ordering on coinbase outputs, what do you think of a scheme
                which searches index 1 for an OP RETURN, and if it finds something it
                interprets that as the root hash of merkle tree of merged mined
                sidechain h*'s ? If it doesn't find a hash commitment in index 1 it just
                assumes that no sidechains were mined in this ~10 minute period.
                
                > 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.
                >
                > 3.  Don't number sidechain_id from 0, 1, 2, 3..., because people will
                > fight over the small numbers.  Instead identify sidechains by, for
                > example, the hash of their names or the hash of their genesis block or
                > whatever.  This allows true permissionless creation of sidechains,
                > without some authority existing that centrally allocates sidechain ID's.
                
                I am actually not in favor of permiessionless creation of sidechains,
                because the sidechains can interfere with each other to a degree that
                impacts their usefulness. We do not allow "permissionless creation of
                transactions", because we do not allow invalid or double-spent
                transactions. I feel the same logic should apply to the chains themselves.
                
                Another youtube presenation about this:
                https://www.youtube.com/watch?v=xGu0o8HH10U&list=PLw8-6ARlyVciMH79ZyLOpImsMug3LgNc4&index=1
                (Much shorter) written post: http://www.truthcoin.info/blog/wise-contracts/
                
                That said, I am fully in favor of forcing the sidechain's permanent
                deposit address to be equal to some deterministic function of the sha256
                hash of its version 0.1 release.
                
                Paul
                
                
                
                ^ permalink raw reply	[flat|nested] 25+ messages in thread

              • • [parent not found: <CAF5CFkg+mJQ75ps7f3Xa=j2eBDoNwFEdL-vFrFV5y_FqF3qGRA@mail.gmail.com>]

                • • * Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
                           [not found]                 ` <CAF5CFkg+mJQ75ps7f3Xa=j2eBDoNwFEdL-vFrFV5y_FqF3qGRA@mail.gmail.com>
                    @ 2017-07-12 23:58                   ` CryptAxe
                      0 siblings, 0 replies; 25+ messages in thread
                    From: CryptAxe @ 2017-07-12 23:58 UTC (permalink / raw)
                      To: Paul Sztorc, bitcoin-dev
                    
                    [-- Attachment #1: Type: text/plain, Size: 869 bytes --]
                    
                    In case anyone wants to do this, I added the CSidechainAddress class to the
                    mainchainBMM branch of the Drivechain project a long time ago. The only
                    purpose it serves right now is to show that sidechain deposit addresses can
                    start with a '4'. We could simply add the sha256 hash described by Paul to
                    a script with OP_RETURN at the front and make that the standard.
                    
                    On Jul 12, 2017 4:47 PM, "Paul Sztorc via bitcoin-dev" <
                    bitcoin-dev@lists•linuxfoundation.org> wrote:
                    
                    On 7/12/2017 4:50 AM, ZmnSCPxj wrote:
                    
                    ...
                    
                    
                    That said, I am fully in favor of forcing the sidechain's permanent
                    deposit address to be equal to some deterministic function of the sha256
                    hash of its version 0.1 release.
                    
                    Paul
                    
                    _______________________________________________
                    bitcoin-dev mailing list
                    bitcoin-dev@lists•linuxfoundation.org
                    https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
                    
                    [-- Attachment #2: Type: text/html, Size: 1751 bytes --]
                    
                    ^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2017-07-13 20:45 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-28  0:37 [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains Chris Stewart
2017-06-28  4:07 ` Gregory Maxwell
2017-06-28 16:35   ` Paul Sztorc
2017-06-28  5:20 ` Luke Dashjr
2017-06-28  5:28   ` Adam Back
2017-06-28 16:43   ` Paul Sztorc
2017-06-28  8:26 ` ZmnSCPxj
2017-06-28 22:20   ` Paul Sztorc
2017-06-28 22:49     ` Russell O'Connor
2017-06-28 23:47       ` Chris Stewart
2017-06-29  1:09         ` Russell O'Connor
2017-06-30  4:00     ` ZmnSCPxj
2017-06-30 14:12       ` Chris Stewart
2017-06-30 16:51       ` CryptAxe
2017-07-02 21:32       ` Paul Sztorc
2017-07-04  7:21         ` ZmnSCPxj
2017-07-04 15:06           ` Chris Stewart
2017-07-12  8:50             ` ZmnSCPxj
2017-07-12 13:39               ` Russell O'Connor
     [not found]                 ` <CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>
2017-07-12 18:02                   ` Chris Stewart
2017-07-13  0:00                     ` Paul Sztorc
2017-07-13 20:22                       ` Chris Stewart
2017-07-13 20:45                         ` Paul Sztorc
2017-07-12 23:31               ` Paul Sztorc
     [not found]                 ` <CAF5CFkg+mJQ75ps7f3Xa=j2eBDoNwFEdL-vFrFV5y_FqF3qGRA@mail.gmail.com>
2017-07-12 23:58                   ` CryptAxe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox