From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A2948104C for ; 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 ; Tue, 26 Jan 2016 01:02:45 +0000 (UTC) Received: by mail-vk0-f44.google.com with SMTP id k1so83791242vkb.2 for ; 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: From: Toby Padilla 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ``` ## 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
Hi all,

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):


My original discussion of this issue:


BIP draft as follows...

--

```
Title= : Allow zero value OP_RETURN in Payment Protocol
Author: Toby Pad= illa <tobypadilla@gmail.com= >
```

## Abstract

<= /div>
This BIP alters the Payment Protocol to allow for zero value OP_R= ETURN outputs in serialized PaymentRequests.

## Mo= tivation

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.

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.

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

=
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 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.

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.

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.

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.

## Specification

The specification for th= is BIP is straightforward. BIP70 should be fully implemented with two chang= es:

1. Outputs where the script is an OP_RETURN an= d 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 requi= rement 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. 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.

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.

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.

## Compatibility

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.

--001a11430cb43a8997052a323e96--