path: root/84/fa37391b06dc48ea5208912f353d7ca6d38861

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 AC65C8DC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Jul 2017 23:31:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com
	[209.85.220.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A0B2E10A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Jul 2017 23:31:17 +0000 (UTC)
Received: by mail-qk0-f171.google.com with SMTP id a66so23979927qkb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Jul 2017 16:31:17 -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-transfer-encoding:content-language;
	bh=v/IpJY7HUq0D3gCGf8VvI6ifhpOONls/NlFkU6qxX/A=;
	b=lrGZut5XZSQX2DcZprK/Y6tz4SByik8EDEuWnl6wm9NIF43p94w6UMdki1dJSSFSIr
	RglITSLoA8628Sps5omo2fxu3QWw9b6I8mlbKvpAjEMpgtq2PrdOxsop0QLOjmeKtT1A
	qiaDzjGUyQPLFvpek/vVy+GghhJ+i0sM8DtYrbIP2KArZ1eJb2DKmaZYxgflAEvGJwg3
	StNPKZc6MMOP5SbwhHgeqgFkjQ63JTtMoY0sdpx9ItXDW9Y2NGNplvjf8Cjj0I6PnGqW
	4/ZEsFgmVXbrDCwEcwlfBsGoT2BHt0Da298kbcM3ST55mjdx3WQ5porFk6IewubMXNsA
	dynA==
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-transfer-encoding
	:content-language;
	bh=v/IpJY7HUq0D3gCGf8VvI6ifhpOONls/NlFkU6qxX/A=;
	b=Vqb8JleqvJyVctega7Wcd0Q+ITaWG3Alq3gXxWlQDOdwblQMWYSSHpF9KmNYZVQGqk
	G6t6r8VSlF0iZtvKB0GzIs7wFd4NeO9vV2jCDz0vxxicQIwDn0cBp7X3PP+Ef/zI91AI
	sM8jMxWqchOkS1sAPPZKJGbNOqyENsd8gDXZ/1kNuRywAd4imXTcCMU99zqUxwYg5MQk
	IntnZAjgDNuba4/qp1EA/lRvAUf7iWvAtYwU6S0nuikb+tLcuvLqXWXG9NQ9CVRwG9sv
	y6cEERl8fvjx5O3gvvTX+005UBuICBCgVGZawQMWywOX9O3E95+COc+AUHhAOD3pcEPX
	RK9A==
X-Gm-Message-State: AIVw113sSN9QYDrkMeoY2SdEZbcHDkPIhoWRHnZDL+MoJ6Ydyi2l9FHC
	9zmtTuMHZnIanH8RFjA=
X-Received: by 10.55.142.67 with SMTP id q64mr1274631qkd.99.1499902276345;
	Wed, 12 Jul 2017 16:31:16 -0700 (PDT)
Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net.
	[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
	j65sm2742328qkf.38.2017.07.12.16.31.14
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 12 Jul 2017 16:31:15 -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>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
	<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
	<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
	<CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
	<hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <7e1d2d0a-d39b-2c97-c624-a6d0562f3843@gmail.com>
Date: Wed, 12 Jul 2017 19:31:18 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
	Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
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
X-Mailman-Approved-At: Wed, 12 Jul 2017 23:47:00 +0000
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, 12 Jul 2017 23:31:18 -0000

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/01466=
8.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 transacti=
on.
> >>>>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%20B=
itcoin%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=3DYErLEuOi3xU&list=3DPLw8-6ARlyVciNjgS_NF=
hAu-qt7HPf_dtg&index=3D4

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 desirab=
le.

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=
=2E

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=
=2E

Another youtube presenation about this:
https://www.youtube.com/watch?v=3DxGu0o8HH10U&list=3DPLw8-6ARlyVciMH79ZyL=
OpImsMug3LgNc4&index=3D1
(Much shorter) written post: http://www.truthcoin.info/blog/wise-contract=
s/

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