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
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
Precedence: list

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