public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Chris Stewart <chris@suredbits•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
Date: Tue, 27 Jun 2017 19:37:13 -0500	[thread overview]
Message-ID: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com> (raw)

[-- 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 --]

             reply	other threads:[~2017-06-28  0:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-28  0:37 Chris Stewart [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com' \
    --to=chris@suredbits$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox