diff options
| author | Paul Sztorc <truthcoin@gmail.com> | 2017-07-12 20:00:29 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-07-13 00:00:29 +0000 |
| commit | 36361b01165884e8cf5be1cc9feb286a7a4cc614 (patch) | |
| tree | c0ea8ed3177c3e0d66b9c92b6bd31b9a1cca4f55 | |
| parent | 06da7ff84e29b7e5bc0e98a7d4151d1e024440f7 (diff) | |
| download | pi-bitcoindev-36361b01165884e8cf5be1cc9feb286a7a4cc614.tar.gz pi-bitcoindev-36361b01165884e8cf5be1cc9feb286a7a4cc614.zip | |
Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
| -rw-r--r-- | e9/4f69700af1524371296e3dbd52b8a3d62fa659 | 220 |
1 files changed, 220 insertions, 0 deletions
diff --git a/e9/4f69700af1524371296e3dbd52b8a3d62fa659 b/e9/4f69700af1524371296e3dbd52b8a3d62fa659 new file mode 100644 index 000000000..2991b66c9 --- /dev/null +++ b/e9/4f69700af1524371296e3dbd52b8a3d62fa659 @@ -0,0 +1,220 @@ +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 56ADA414 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 13 Jul 2017 00:00:29 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com + [209.85.216.177]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8310AC + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 13 Jul 2017 00:00:28 +0000 (UTC) +Received: by mail-qt0-f177.google.com with SMTP id i2so25789882qta.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 12 Jul 2017 17:00:28 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=subject:to:references:from:message-id:date:user-agent:mime-version + :in-reply-to:content-language; + bh=rldDsvQWkRipqHsAF+51TsvAT1qlcxx7v9NEitI5clw=; + b=c9eN8TeVIXq0mxBQZZUiDAwtVvJ/7byIzIT3604qyWj0CkNg4xH1ty57JeApJRmRms + 6UjhIUdZHDo1isfeGVko0f5vnygjcgwTxoOqNW/D/oIZLrdKS7RI0ZzmQSLUuVT0dSUV + m4o38T4yxg0OnCtThliz+38WXZy6IQ+yv7QV7QN4ut2Rmjn15+aDnrltRe3kEx86IqBR + 1LRSdpEnrmzitkLaK/SbaXuXkPqnXu2HfkfhQJU661sun6mMZ87RNhyyaQe6IUnMaeDi + YMaq0udTUZuWmq36CKcSxCxFsCNZdZlPOjYZCujh+3rZ8JBvI8AVMwwAHzhL8spSZzkM + IB3Q== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:subject:to:references:from:message-id:date + :user-agent:mime-version:in-reply-to:content-language; + bh=rldDsvQWkRipqHsAF+51TsvAT1qlcxx7v9NEitI5clw=; + b=DJl9ZF6EI2rsMtx25S3RYiIWWuvvbYb5zEpIRsBZvOFORxR1VLlIhMl9T3nVriVLf+ + RcIQhnsFFGMzwxtpLp2MFpQUYxSONVX+x8QyiHSUgC3us4Yawxoa827045VhdMq5AN0L + JHyMka7Kaum9aEFV5WPZv7QQJRqYqfq2TDENAXPch6LiFpHfr6azhb0Fbx+Rwfuk3fMY + OuxMv4ZlcuqjFXhGfmytSnEi15uZdkyzuuu5TEZSELjdxa55P3TRAwAaQJOR9cNVxAdG + Gu2lGOt5MXW0gM52O27af9T6mGGDOf7kaC7gwcEVGzL3ekSbpin0qRh1ulMpp+tN0Cq5 + MxHQ== +X-Gm-Message-State: AIVw112QOEfRq94jj10/HBTWx6cx1gbDUvZx0cSE8RMWamtPhzbMr5mB + 4KlWGaclwryKNQ== +X-Received: by 10.200.9.55 with SMTP id t52mr1444111qth.107.1499904027498; + Wed, 12 Jul 2017 17:00:27 -0700 (PDT) +Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net. + [69.114.110.251]) by smtp.googlemail.com with ESMTPSA id + q40sm3213022qtf.42.2017.07.12.17.00.26 + (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Wed, 12 Jul 2017 17:00:26 -0700 (PDT) +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 +X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, + 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: Thu, 13 Jul 2017 00:05:18 +0000 +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: Thu, 13 Jul 2017 00:00:29 -0000 + +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-- + |