path: root/88/7a104d00d1330cb614e44baf0306f47e9e6251

Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 260ADAE1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 28 Jun 2017 22:20:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com
	[209.85.220.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1BE45CE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 28 Jun 2017 22:20:40 +0000 (UTC)
Received: by mail-qk0-f181.google.com with SMTP id d78so62679052qkb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 28 Jun 2017 15:20:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=subject:to:cc:references:from:message-id:date:user-agent
	:mime-version:in-reply-to:content-language:content-transfer-encoding;
	bh=ZNYQsHAS+HYX9wUe/m8GROBvQaOkZ08ACBgEXfmI/q4=;
	b=GuT9JNQbsZlW5C93SnuvBd+FT84v4p6/xNnjX4+CaQ/Ekz2BW57ZSZmq+ItfAt81qt
	hY8Q8GJqJAIfsj9CHVImXVElBJ8C5uB0AbGsFY1nDX7YhCMrr2L+b/9TDiVeTtvBclze
	tk/IX+50wCJItLBsCiy0ez2h88jdCt+3f0/AftosUrL3rtdfT2+jv7jJAZSfc8jcV4Zq
	m4I9QTdkewp5Hkh8hZwxm2yRa+CbIFOzPwA7bydWLRoAKtA8JOtVmiBdJIPUZOZsk3gC
	ql5oAJvX4WouHb3fNjOu5tu55i8e9uFfl4otMoLpijyz6Ny8Y88edGpTDDYLO/Oe5zVy
	yJ6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:cc:references:from:message-id:date
	:user-agent:mime-version:in-reply-to:content-language
	:content-transfer-encoding;
	bh=ZNYQsHAS+HYX9wUe/m8GROBvQaOkZ08ACBgEXfmI/q4=;
	b=lWlZC3ZPmW4Q0wdkWEuy0hPnw1aW2E0fv4NzInk/wHceBIzbm92ueg9pHHbIyjAkTI
	j4px4mhwGTd2z7EzV0GZhFb31ea0a6oXIWBJ+TexQCK69XQvi1Bizk90L4WAnLrX8vP6
	VfikXS/h73ZBdXPFFwoUvxDh9jwY5Dq8sETmNAdtCF4/lCTlEb9gKgsg+ccJCgsEylT5
	NKPf8taFx1P7Vlo6oHSzG5y020ULUQxXwZSg8l2rvamzUaJbR2CN3SNY5DA2SL3a5x1o
	KpQESz1j2CHX/52IcFi3lmLJ69tbT6gh6cQ0+u/jP2kYUoSrl8hVavqaNGWPtDU/QlLL
	oaWA==
X-Gm-Message-State: AKS2vOwW34IFS9zBkCXgNnV1/SzUzmI/V9jsTGSxZxqP3Rp7FMiOoPko
	QQ4Go7lGzDiwi2R/jXU=
X-Received: by 10.55.97.148 with SMTP id v142mr15914187qkb.107.1498688438901; 
	Wed, 28 Jun 2017 15:20:38 -0700 (PDT)
Received: from [192.168.1.100] (ool-45726efb.dyn.optonline.net.
	[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
	q90sm2653870qki.11.2017.06.28.15.20.36
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 28 Jun 2017 15:20:37 -0700 (PDT)
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, Chris Stewart <chris@suredbits.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
Date: Wed, 28 Jun 2017 18:20:35 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
	Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jun 2017 22:20:41 -0000

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
>