To: Chris Stewart <chris@suredbits.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Russell O'Connor <roconnor@blockstream.io>
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>
	<CAMZUoK==7OATOJ=46CYJWkq=WAXnJ8-JjvL25E1ijhnRbqj_Jg@mail.gmail.com>
	<CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>
	<CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <7fc82c47-c03a-f489-55c2-b7d6830c1a74@gmail.com>
Date: Wed, 12 Jul 2017 20:00:29 -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: <CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------7706548FCFD2FF1F5F7FE708"
Content-Language: en-US
Subject: Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
Precedence: list

This is a multi-part message in MIME format.
--------------7706548FCFD2FF1F5F7FE708
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I still think it may be more inefficient, in equilibrium. (In other
words, in the future steady state of Bitcoin that includes LN or
something LN-like).

Assume there are N sidechains.

In the coinbase version:
1. There is some single event, per N, that causes nodes to notice that a
new sidechain has been created.
2. Per block, there are N hash commitments (32 bytes) and N instances of
the ratchet's block counter (2 bytes).
3. Per block, some node operator _may_ have BMMed the block, and a miner
therefore might want redeem an OP Bribe that pays BTC from a sidechain
node operator to the miner. But they are likely to negotiate the payment
through the Lightning Network (when this is possible).
4. Sidechains running in SPV mode know exactly where to find the
information they need in order to discover the "longest" chain.

In the OP RETURN version:
1. [same] There is some single event, per N, that causes nodes to notice
that a new sidechain has been created.
2. [+30 bytes (+more?)] Per block, there are N hash commitments (32
bytes) and also N prevBlockHashes (32 bytes). Also, to make this
transaction, someone needs to spend something in the UTXO set (or select
no inputs in a kind of 'hollow transaction'), whereas one coinbase will
always exist per block.
3. [same] No need for a new transaction.
4. [same?] Due to Rusty's soft fork rule of only one h* per sidechain
per block, sidechains need just a merkle tree path, but they don't
necessarily know where it is. They must store extra [?] data to help
them find the data's location?


On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev wrote:
> Hi Russell/ZmnSCPxj,
>
> I think you guys are right. The only problem I can see with it is
> replaceability of the bribe transaction. If the 'Bribe' is the fee on
> the transaction it isn't clear to me what the best way to
> replace/remove it is.

I think that that is the purpose of Rusty's soft fork rule about only
including one per sidechain -- miners would have one "slot" per
sidechain, and they would therefore have an incentive to make the slot
count, and would be only selecting the highest fee txn to fill each slot.=


--------------7706548FCFD2FF1F5F7FE708
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I still think it may be more
      inefficient, in equilibrium. (In other words, in the future steady
      state of Bitcoin that includes LN or something LN-like).<br>
      <br>
      Assume there are N sidechains.<br>
      <br>
      In the coinbase version:<br>
      1. There is some single event, per N, that causes nodes to notice
      that a new sidechain has been created.<br>
      2. Per block, there are N hash commitments (32 bytes) and N
      instances of the ratchet's block counter (2 bytes).<br>
      3. Per block, some node operator _may_ have BMMed the block, and a
      miner therefore might want redeem an OP Bribe that pays BTC from a
      sidechain node operator to the miner. But they are likely to
      negotiate the payment through the Lightning Network (when this is
      possible).<br>
      4. Sidechains running in SPV mode know exactly where to find the
      information they need in order to discover the "longest" chain.<br>
      <br>
      In the OP RETURN version:<br>
      1. [same] There is some single event, per N, that causes nodes to
      notice that a new sidechain has been created.<br>
      2. [+30 bytes (+more?)] Per block, there are N hash commitments
      (32 bytes) and also N prevBlockHashes (32 bytes). Also, to make
      this transaction, someone needs to spend something in the UTXO set
      (or select no inputs in a kind of 'hollow transaction'), whereas
      one coinbase will always exist per block.<br>
      3. [same] No need for a new transaction.<br>
      4. [same?] Due to Rusty's soft fork rule of only one h* per
      sidechain per block, sidechains need just a merkle tree path, but
      they don't necessarily know where it is. They must store extra [?]
      data to help them find the data's location?<br>
      <br>
      <br>
      On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail-ajy" tabindex="0"><img class="gmail-ajz"
            id="gmail-:25p"
            src="https://mail.google.com/mail/u/0/images/cleardot.gif"
            alt="" moz-do-not-send="true"></div>
        <div>
          <div>
            <div>Hi Russell/ZmnSCPxj,<br>
              <br>
            </div>
            <div>I think you guys are right. The only problem I can see
              with it is replaceability of the bribe transaction. If the
              'Bribe' is the fee on the transaction it isn't clear to me
              what the best way to replace/remove it is. <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I think that that is the purpose of Rusty's soft fork rule about
    only including one per sidechain -- miners would have one "slot" per
    sidechain, and they would therefore have an incentive to make the
    slot count, and would be only selecting the highest fee txn to fill
    each slot.<br>
  </body>
</html>

--------------7706548FCFD2FF1F5F7FE708--