diff options
| author | Toby Padilla <tobypadilla@gmail.com> | 2016-01-25 17:02:44 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-01-26 01:02:46 +0000 |
| commit | 27f99975a179814f491521e9ef2db7663f1a96d6 (patch) | |
| tree | 6ef98b0e145c156eca3610838f56c38a2373e629 | |
| parent | 50ef2fddc547c2b2a700abb92f7e98c72211742c (diff) | |
| download | pi-bitcoindev-27f99975a179814f491521e9ef2db7663f1a96d6.tar.gz pi-bitcoindev-27f99975a179814f491521e9ef2db7663f1a96d6.zip | |
[bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol
| -rw-r--r-- | 1f/3c8bb041087584bc1b13f914101d8aad46d4d5 | 284 |
1 files changed, 284 insertions, 0 deletions
diff --git a/1f/3c8bb041087584bc1b13f914101d8aad46d4d5 b/1f/3c8bb041087584bc1b13f914101d8aad46d4d5 new file mode 100644 index 000000000..778b86387 --- /dev/null +++ b/1f/3c8bb041087584bc1b13f914101d8aad46d4d5 @@ -0,0 +1,284 @@ +Return-Path: <tobypadilla@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id A2948104C + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 26 Jan 2016 01:02:46 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com + [209.85.213.44]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6B67C137 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 26 Jan 2016 01:02:45 +0000 (UTC) +Received: by mail-vk0-f44.google.com with SMTP id k1so83791242vkb.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 25 Jan 2016 17:02:45 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:date:message-id:subject:from:to:cc:content-type; + bh=zXYnuN8STV8bVLAzBQxECshhY2eQS2nOzX5viNsDS/U=; + b=ok2ic+X5PMxYE0TPM3qd9WZseVc4SxTriN7N4SVjlvUvw2gY0wn3AGgqQtgr2o7lgC + mfIlv/py6V2f+BMiaA++ve8C30G/TgfOTgN6AqBkiUmjPN15tfwdpABl3OgFHXy0QII5 + iDw47yDG4JrciLakuxQtgGaCo3KAJHke+ISLsVTVO9jh2s1h1cDpPc4Hzxxqs6wcr9Dc + bL9thTwqlsy1MsmtOknqdv0mvOfUo46ZMltAayAbuxRKm1btd1hcRt9axwX918vMiOTK + yA7y8jCo74XcSp2YHnSsVaYq+3tdVtLcko9bv0PSCwr/xMV5RwG7RYTh9wPwQuOChcfI + XG2g== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc + :content-type; + bh=zXYnuN8STV8bVLAzBQxECshhY2eQS2nOzX5viNsDS/U=; + b=irp7eFnXTjfLL1KUgSmwT7u4EyNOqjfWyVI1MP1dUxSCSsA5McXdJJBvhYEK1353S3 + gjvGlU4K+u+6rXxYawpGfcpoIPxrHjhhY7xAg7gjIESz8nfF2xVvV95bjdqGFcm5jcpx + jY5VhPHDC2SD476ithHdVL9KtqSWuaQti9Ug2r+v5DDABAlzonnz9c7wEjlW4LRqJfa1 + tkjARV1HtOkZa+h6AKY17lNeDDoZfIiT7JgEBAIeQFyFbp+Ae6L1H6S0ZZFmaFidgjua + 7wdLM7G2LEBmKvrHq6Ovoo/V5UrRy/UdCQCwSzDOVbWDdCmH0M1Pnnk5I/VkaMvfmkUP + G5IA== +X-Gm-Message-State: AG10YOR8UWZwAeeCvad3y5KV5IObT2hqHvIdhPCGhSK63NV4IKX0ZZC8RpzfzhdG6QZplknUPUA2m9MDOuC+jA== +MIME-Version: 1.0 +X-Received: by 10.31.160.6 with SMTP id j6mr3362321vke.87.1453770164306; Mon, + 25 Jan 2016 17:02:44 -0800 (PST) +Received: by 10.31.96.85 with HTTP; Mon, 25 Jan 2016 17:02:44 -0800 (PST) +Date: Mon, 25 Jan 2016 17:02:44 -0800 +Message-ID: <CAGcHOzzde_T3xJwJL2Ehyw7U1FgxEEBJR30VBLdSZMj=W49hSg@mail.gmail.com> +From: Toby Padilla <tobypadilla@gmail.com> +To: bitcoin-dev@lists.linuxfoundation.org +Content-Type: multipart/alternative; boundary=001a11430cb43a8997052a323e96 +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Tue, 26 Jan 2016 02:56:12 +0000 +Cc: luke_bipeditor@dashjr.org +Subject: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment + Protocol +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development 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: Tue, 26 Jan 2016 01:02:46 -0000 + +--001a11430cb43a8997052a323e96 +Content-Type: text/plain; charset=UTF-8 + +Hi all, + +I'm submitting a new BIP draft for consideration and discussion. I've put a +pull request up on Github that implements this BIP (with discussion from +the Core team): + +https://github.com/bitcoin/bitcoin/pull/7376 + +My original discussion of this issue: + +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011874.html + +BIP draft as follows... + +-- + +``` +Title: Allow zero value OP_RETURN in Payment Protocol +Author: Toby Padilla <tobypadilla@gmail.com> +``` + +## Abstract + +This BIP alters the Payment Protocol to allow for zero value OP_RETURN +outputs in serialized PaymentRequests. + +## Motivation + +The Payment Protocol (defined in BIP70) gives merchants a way to build +sophisticated transactions by serializing one or more outputs in the form +of a PaymentRequest. The PaymentRequest is then served over http/https to a +customer's wallet where the serialized transaction can be executed. + +While the Payment Protocol allows for any valid script in its outputs, it +also ignores outputs with zero value. This means BIP70 implementations can +encode an OP_RETURN script but must provide a greater than dust value for +that output. The end result is a successful PaymentRequest transaction with +an OP_RETURN but the value assigned to that output is lost forever. + +This BIP allows for zero value OP_RETURN outputs in serialized +PaymentRequests. The change means that OP_RETURN scripts will work as they +were originally intended from within PaymentRequests without permanently +destroying Bitcoin value. Zero value non-OP_RETURN scripts should continue +to be ignored and positive value OP_RETURN outputs should now be rejected. + +In addition to fixing the issue of destroyed value, this change opens up +new use cases that were previously impossible. + +While storing data on the blockchain is controversial, when used +responsibly OP_RETURN provides a powerful mechanism for attaching metadata +to a transaction. This BIP effectively decouples the creation of +transactions containing OP_RETURN data from the execution of those +transactions. The result are positive benefits for both merchants and +wallets/customers. + +By supporting this BIP, wallets can participate in current and future, +unforeseen use cases that benefit from metadata stored in OP_RETURN. Until +now OP_RETURN transactions have typically been created and submitted by +custom software. If a wallet can process a PaymentRequest with OP_RETURN +data as proposed by this BIP, it will support potentially sophisticated +Bitcoin applications without the wallet developer having to have prior +knowledge of that application. + +An example might be a merchant that adds the hash of a plain text invoice +to the checkout transaction. The merchant could construct the +PaymentRequest with the invoice hash in an OP_RETURN and pass it to the +customer's wallet. The wallet could then submit the transaction, including +the invoice hash from the PaymentRequest. The wallet will have encoded a +proof of purchase to the blockchain without the wallet developer having to +coordinate with the merchant software or add features beyond this BIP. + +Merchants and Bitcoin application developers benefit from this BIP because +they can now construct transactions that include OP_RETURN data in a +keyless environment. Again, prior to this BIP, transactions that used +OP_RETURN (with zero value) needed to be constructed and executed in the +same software. By separating the two concerns, this BIP allows merchant +software to create transactions with OP_RETURN metadata on a server without +storing public or private Bitcoin keys. This greatly enhances security +where OP_RETURN applications currently need access to a private key to sign +transactions. + +## Specification + +The specification for this BIP is straightforward. BIP70 should be fully +implemented with two changes: + +1. Outputs where the script is an OP_RETURN and the value is zero should be +accepted by the wallet. +2. Outputs where the script is an OP_RETURN and the value is greater than +zero should be rejected. + +This is a change from the BIP70 requirement that all zero value outputs be +ignored. + +## Rationale + +As with the discussion around vanilla OP_RETURN, the practice of storing +data on the blockchain is controversial. While blockchain and network bloat +is an undeniable issue, the benefits that come from attaching metadata to +transactions has proven to be too powerful to dismiss entirely. In the +absence of OP_RETURN support the Bitcoin ecosystem has seen alternative, +less elegant and more wasteful methods employed for Blockchain data storage. + +As it exists today, BIP70 allows for OP_RETURN data storage at the expense +of permanently destroyed Bitcoin. Even fully removing support for OP_RETURN +values in the Payment Protocol would still leave the door open to +suboptimal data encoding via burning a larger than dust value to an output +with a false address designed to encode data. + +This BIP offers all of the same benefits that come from the OP_RETURN +compromise. Mainly that OP_RETURN scripts are provably unspendable and thus +can be pruned from the UTXO pool. Without supporting this BIP, wallets that +support BIP70 will allow for wasteful data storage. + +## Compatibility + +While not in widespread use, existing BIP70 PaymentRequest outputs that +have a greater than zero value with an OP_RETURN script (burning Bitcoin) +will need to have their values changed to zero or they will be rejected by +wallets implementing this BIP. + +--001a11430cb43a8997052a323e96 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi all,<div><br></div><div>I'm submitting a new BIP dr= +aft for consideration and discussion. I've put a pull request up on Git= +hub that implements this BIP (with discussion from the Core team):</div><di= +v><br></div><div><a href=3D"https://github.com/bitcoin/bitcoin/pull/7376">h= +ttps://github.com/bitcoin/bitcoin/pull/7376</a><br></div><div><br></div><di= +v>My original discussion of this issue:</div><div><br></div><div><a href=3D= +"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/0118= +74.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decem= +ber/011874.html</a><br></div><div><br></div><div>BIP draft as follows...</d= +iv><div><br></div><div>--</div><div><br></div><div><div>```</div><div>Title= +: Allow zero value OP_RETURN in Payment Protocol</div><div>Author: Toby Pad= +illa <<a href=3D"mailto:tobypadilla@gmail.com">tobypadilla@gmail.com</a>= +></div><div>```<br></div><div><br></div><div>## Abstract</div><div><br><= +/div><div>This BIP alters the Payment Protocol to allow for zero value OP_R= +ETURN outputs in serialized PaymentRequests.</div><div><br></div><div>## Mo= +tivation</div><div><br></div><div>The Payment Protocol (defined in BIP70) g= +ives merchants a way to build sophisticated transactions by serializing one= + or more outputs in the form of a PaymentRequest. The PaymentRequest is the= +n served over http/https to a customer's wallet where the serialized tr= +ansaction can be executed.</div><div><br></div><div>While the Payment Proto= +col allows for any valid script in its outputs, it also ignores outputs wit= +h zero value. This means BIP70 implementations can encode an OP_RETURN scri= +pt but must provide a greater than dust value for that output. The end resu= +lt is a successful PaymentRequest transaction with an OP_RETURN but the val= +ue assigned to that output is lost forever.</div><div><br></div><div>This B= +IP allows for zero value OP_RETURN outputs in serialized PaymentRequests. T= +he change means that OP_RETURN scripts will work as they were originally in= +tended from within PaymentRequests without permanently destroying Bitcoin v= +alue. Zero value non-OP_RETURN scripts should continue to be ignored and po= +sitive value OP_RETURN outputs should now be rejected.=C2=A0</div><div><br>= +</div><div>In addition to fixing the issue of destroyed value, this change = +opens up new use cases that were previously impossible.</div><div><br></div= +><div>While storing data on the blockchain is controversial, when used resp= +onsibly OP_RETURN provides a powerful mechanism for attaching metadata to a= + transaction. This BIP effectively decouples the creation of transactions c= +ontaining OP_RETURN data from the execution of those transactions. The resu= +lt are positive benefits for both merchants and wallets/customers.</div><di= +v><br></div><div>By supporting this BIP, wallets can participate in current= + and future, unforeseen use cases that benefit from metadata stored in OP_R= +ETURN. Until now OP_RETURN transactions have typically been created and sub= +mitted by custom software. If a wallet can process a PaymentRequest with OP= +_RETURN data as proposed by this BIP, it will support potentially sophistic= +ated Bitcoin applications without the wallet developer having to have prior= + knowledge of that application.</div><div><br></div><div>An example might b= +e a merchant that adds the hash of a plain text invoice to the checkout tra= +nsaction. The merchant could construct the PaymentRequest with the invoice = +hash in an OP_RETURN and pass it to the customer's wallet. The wallet c= +ould then submit the transaction, including the invoice hash from the Payme= +ntRequest. The wallet will have encoded a proof of purchase to the blockcha= +in without the wallet developer having to coordinate with the merchant soft= +ware or add features beyond this BIP.</div><div><br></div><div>Merchants an= +d Bitcoin application developers benefit from this BIP because they can now= + construct transactions that include OP_RETURN data in a keyless environmen= +t. Again, prior to this BIP, transactions that used OP_RETURN (with zero va= +lue) needed to be constructed and executed in the same software. By separat= +ing the two concerns, this BIP allows merchant software to create transacti= +ons with OP_RETURN metadata on a server without storing public or private B= +itcoin keys. This greatly enhances security where OP_RETURN applications cu= +rrently need access to a private key to sign transactions.</div><div><br></= +div><div>## Specification</div><div><br></div><div>The specification for th= +is BIP is straightforward. BIP70 should be fully implemented with two chang= +es:</div><div><br></div><div>1. Outputs where the script is an OP_RETURN an= +d the value is zero should be accepted by the wallet.</div><div>2. Outputs = +where the script is an OP_RETURN and the value is greater than zero should = +be rejected.</div><div><br></div><div>This is a change from the BIP70 requi= +rement that all zero value outputs be ignored.</div><div><br></div><div>## = +Rationale</div><div><br></div><div>As with the discussion around vanilla OP= +_RETURN, the practice of storing data on the blockchain is controversial. W= +hile blockchain and network bloat is an undeniable issue, the benefits that= + come from attaching metadata to transactions has proven to be too powerful= + to dismiss entirely. In the absence of OP_RETURN support the Bitcoin ecosy= +stem has seen alternative, less elegant and more wasteful methods employed = +for Blockchain data storage.</div><div><br></div><div>As it exists today, B= +IP70 allows for OP_RETURN data storage at the expense of permanently destro= +yed Bitcoin. Even fully removing support for OP_RETURN values in the Paymen= +t Protocol would still leave the door open to suboptimal data encoding via = +burning a larger than dust value to an output with a false address designed= + to encode data.</div><div><br></div><div>This BIP offers all of the same b= +enefits that come from the OP_RETURN compromise. Mainly that OP_RETURN scri= +pts are provably unspendable and thus can be pruned from the UTXO pool. Wit= +hout supporting this BIP, wallets that support BIP70 will allow for wastefu= +l data storage.</div><div><br></div><div>## Compatibility</div><div><br></d= +iv><div>While not in widespread use, existing BIP70 PaymentRequest outputs = +that have a greater than zero value with an OP_RETURN script (burning Bitco= +in) will need to have their values changed to zero or they will be rejected= + by wallets implementing this BIP.</div></div><div><br></div></div> + +--001a11430cb43a8997052a323e96-- + |