To: ZmnSCPxj <ZmnSCPxj@protonmail.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>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
Date: Sun, 2 Jul 2017 17:32:50 -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: <lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@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

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 create=
s
> >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 o=
ne
> >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 side=
s.

Paul