path: root/55/d6df763c510d4ed54f59bd25047e60082a47fa

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 5488DF3F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Jan 2016 17:41:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com
	[209.85.213.49])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 30256129
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Jan 2016 17:41:02 +0000 (UTC)
Received: by mail-vk0-f49.google.com with SMTP id e64so96973432vkg.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Jan 2016 09:41:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
	:content-type; bh=sJlTzxfRZT6GseIjWSpRXcxnFEr+BIH/6MaK4RQTbCE=;
	b=lYkz98nkuZplx9IMpxa3TLjBVpqRouDCC9MKa+hHiJGa/5DgwL2ZDcOwnKCledbJUG
	TMqPTKGjOT/vjFfJzysTLasLkMIKpQqfWxEpUgHWUtI1ZVYW8NYbhIM0/3rOUSoRQZ0B
	5O2V2xuG1c/SDQqJbyuidCVIlE6yNhduOQCi2eEv5+WbJIkXu6niUcMZLdw0AFaUPTPo
	VBpSd7fLLmBSLh+rMmUmNpDSTObMFIpTWC9G1ptkDHUtEOWhZbJyBSYrVLKK6JLciuyr
	3ZiNXaO4jAuhfRgmjQ/p1fbrN1klgk9GA6jlGTNSMjbxzw/OXf7M2AneM8wiUd629dRR
	Q2aA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:cc:content-type;
	bh=sJlTzxfRZT6GseIjWSpRXcxnFEr+BIH/6MaK4RQTbCE=;
	b=idjwq9JpocWLRhhv1vwwAIcNMAY8xnV3dOWIW48eJnmva4SePNHWV9FvhY5/vQr0E8
	jh5ptd5G9k2yKFyq2ZRnHWya6ww2Gvl8weWhagQ43x2S9i6CNSPABjqpw8c+S/XOzxgO
	PkcJckFVyIAUospbPVOCuBs0Vw10yMMUPZPLA14cByox4MJkfMgjnHuTcOJTCo/eSeYm
	4tPdH9xgskvQ45fZYTYEePepzL/0HxUyCPXCJHObzBoT9Gc7wJ5snKIYG8yiqpwdD5DI
	rWDrI7NaDDjTNDgIWUfDnE+Tir8gRaECl4mld8Z0krxHxzJS0eDSzQUjg3FLericujvK
	vYeQ==
X-Gm-Message-State: AG10YOQLQrJ0HZ3XMXiiVqZ6QMf2fyPycV6VJg9E/Gjh3iXWPZC2p4rBpZIka8gF3deW+Hqx+BYafpobQ1YpGA==
MIME-Version: 1.0
X-Received: by 10.31.52.73 with SMTP id b70mr13805984vka.16.1453830061258;
	Tue, 26 Jan 2016 09:41:01 -0800 (PST)
Received: by 10.31.96.85 with HTTP; Tue, 26 Jan 2016 09:41:01 -0800 (PST)
In-Reply-To: <n880a6$i5v$1@ger.gmane.org>
References: <CAGcHOzzde_T3xJwJL2Ehyw7U1FgxEEBJR30VBLdSZMj=W49hSg@mail.gmail.com>
	<201601260224.16917.luke@dashjr.org>
	<CAGcHOzziBsF6DhX=TrgDJdYiOLHT-zwwX3FAUUkvfi1_4OmPKw@mail.gmail.com>
	<n880a6$i5v$1@ger.gmane.org>
Date: Tue, 26 Jan 2016 09:41:01 -0800
Message-ID: <CAGcHOzyQ4d_oPey=7bMcm8mA4QWAcBrkCu3CY=_BVjrbbd03Sw@mail.gmail.com>
From: Toby Padilla <tobypadilla@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1143fa4c5d7c6b052a40309a
X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
	RCVD_IN_DNSWL_LOW,URIBL_SBL 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: Tue, 26 Jan 2016 17:43:31 +0000
Subject: Re: [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 17:41:03 -0000

--001a1143fa4c5d7c6b052a40309a
Content-Type: text/plain; charset=UTF-8

The wording is a little strange and I think it *should* work as you state,
but Bitcoin Core will actually reject any output that has zero value (even
a single OP_RETURN output -- I just tested again to make sure).

Here's the blocking code:

https://github.com/bitcoin/bitcoin/blob/master/src/qt/paymentserver.cpp#L584

I agree that this should be made more clear in my BIP though, I'll clean up
the language.

On Tue, Jan 26, 2016 at 6:37 AM, Andreas Schildbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Discussion about reasoning of OP_RETURN aside, I think your
> specification needs to be more precise/less ambiguous.
>
> Here is what BIP70 currently says about PaymentDetails.outputs:
>
> "one or more outputs where Bitcoins are to be sent. If the sum of
> outputs.amount is zero, the customer will be asked how much to pay, and
> the bitcoin client may choose any or all of the Outputs (if there are
> more than one) for payment. If the sum of outputs.amount is non-zero,
> then the customer will be asked to pay the sum, and the payment shall be
> split among the Outputs with non-zero amounts (if there are more than
> one; Outputs with zero amounts shall be ignored)."
>
> As you can see, zero outputs are not ignored at all. They are used as an
> indication to allow the user to set an amount. So if you'd come up with
> one zero-amount OP_RETURN output, it would pop up an amount dialog.
> Certainly not what you want, right?
>
>
> On 01/26/2016 03:54 AM, Toby Padilla via bitcoin-dev wrote:
> > It looks like my draft hasn't been approved by the mailing list so if
> > anyone would like to read it it's also on Gist:
> >
> > https://gist.github.com/toby/9e71811d387923a71a53
> >
> > Luke - As stated in the Github thread, I totally understand where you're
> > coming from but the fact is people *will* encode data on the blockchain
> > using worse methods. For all of the reasons that OP_RETURN was a good
> > idea in the first place, it's a good idea to support it in
> PaymentRequests.
> >
> > As for keyless - there's no way (that I know of) to construct a
> > transaction with a zero value OP_RETURN in an environment without keys
> > since the Payment Protocol is what defines the method for getting a
> > transaction from a server to a wallet. You can make a custom transaction
> > and execute it in the same application but without Payments there's no
> > way to move transactions between two applications. You need to build the
> > transaction where you execute it and thus need a key.
> >
> >
> >
> > On Mon, Jan 25, 2016 at 6:24 PM, Luke Dashjr <luke@dashjr.org
> > <mailto:luke@dashjr.org>> wrote:
> >
> >     This is a bad idea. OP_RETURN attachments are tolerated (not
> >     encouraged!) for
> >     the sake of the network, since the spam cannot be outright stopped.
> >     If it
> >     could be outright stopped, it would not be reasonable to allow
> >     OP_RETURN. When
> >     it comes to the payment protocol, however, changing the current
> >     behaviour has
> >     literally no benefit to the network at all, and the changes proposed
> >     herein
> >     are clearly detrimental since it would both encourage spam, and
> >     potentially
> >     make users unwilling (maybe even unaware) participants in it. For
> these
> >     reasons, *I highly advise against publishing or implementing this
> >     BIP, even if
> >     the later mentioned issues are fixed.*
> >
> >     On Tuesday, January 26, 2016 1:02:44 AM Toby Padilla wrote:
> >     > 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.
> >
> >     Such a "proof" is useless without wallet support. Even if you argue
> >     it could
> >     be implemented later on, it stands to reason that a scammer will
> >     simply encode
> >     garbage if the wallet is not checking the proof-of-purchase upfront.
> >     To check
> >     it, you would also need further protocol extensions which are not
> >     included in
> >     this draft.
> >
> >     > 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.
> >
> >     I don't see how this has any relevance to keys at all...
> >
> >     > ## 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.
> >
> >     This does not appear to be backward nor even forward compatible. Old
> >     clients
> >     will continue to use the previous behaviour and transparently omit
> any
> >     commitments. New clients on the other hand will fail to include
> >     commitments
> >     produced by old servers. In other words, it is impossible to produce
> >     software
> >     compatible with both BIP 70 and this draft, and implementing either
> >     would
> >     result in severe consequences.
> >
> >     > As it exists today, BIP70 allows for OP_RETURN data storage at the
> expense
> >     > of permanently destroyed Bitcoin.
> >
> >     It is better for the spammers to lose burned bitcoins, than have a
> >     way to
> >     avoid them.
> >
> >     Luke
> >
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a1143fa4c5d7c6b052a40309a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"font-size:12.8px">The wording is a little s=
trange and I think it *should* work as you state, but Bitcoin Core will act=
ually reject any output that has zero value (even a single OP_RETURN output=
 -- I just tested again to make sure).</span><div style=3D"font-size:12.8px=
"><br></div><div style=3D"font-size:12.8px">Here&#39;s the blocking code:</=
div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8p=
x"><a href=3D"https://github.com/bitcoin/bitcoin/blob/master/src/qt/payment=
server.cpp#L584" target=3D"_blank">https://github.com/bitcoin/bitcoin/blob/=
master/src/qt/paymentserver.cpp#L584</a><br></div><div style=3D"font-size:1=
2.8px"><br></div><div style=3D"font-size:12.8px">I agree that this should b=
e made more clear in my BIP though, I&#39;ll clean up the language.</div></=
div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jan 2=
6, 2016 at 6:37 AM, Andreas Schildbach via bitcoin-dev <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">Discussion about reasoning of OP_RETURN aside, I think=
 your<br>
specification needs to be more precise/less ambiguous.<br>
<br>
Here is what BIP70 currently says about PaymentDetails.outputs:<br>
<br>
&quot;one or more outputs where Bitcoins are to be sent. If the sum of<br>
outputs.amount is zero, the customer will be asked how much to pay, and<br>
the bitcoin client may choose any or all of the Outputs (if there are<br>
more than one) for payment. If the sum of outputs.amount is non-zero,<br>
then the customer will be asked to pay the sum, and the payment shall be<br=
>
split among the Outputs with non-zero amounts (if there are more than<br>
one; Outputs with zero amounts shall be ignored).&quot;<br>
<br>
As you can see, zero outputs are not ignored at all. They are used as an<br=
>
indication to allow the user to set an amount. So if you&#39;d come up with=
<br>
one zero-amount OP_RETURN output, it would pop up an amount dialog.<br>
Certainly not what you want, right?<br>
<span class=3D""><br>
<br>
On 01/26/2016 03:54 AM, Toby Padilla via bitcoin-dev wrote:<br>
&gt; It looks like my draft hasn&#39;t been approved by the mailing list so=
 if<br>
&gt; anyone would like to read it it&#39;s also on Gist:<br>
&gt;<br>
&gt; <a href=3D"https://gist.github.com/toby/9e71811d387923a71a53" rel=3D"n=
oreferrer" target=3D"_blank">https://gist.github.com/toby/9e71811d387923a71=
a53</a><br>
&gt;<br>
&gt; Luke - As stated in the Github thread, I totally understand where you&=
#39;re<br>
&gt; coming from but the fact is people *will* encode data on the blockchai=
n<br>
&gt; using worse methods. For all of the reasons that OP_RETURN was a good<=
br>
&gt; idea in the first place, it&#39;s a good idea to support it in Payment=
Requests.<br>
&gt;<br>
&gt; As for keyless - there&#39;s no way (that I know of) to construct a<br=
>
&gt; transaction with a zero value OP_RETURN in an environment without keys=
<br>
&gt; since the Payment Protocol is what defines the method for getting a<br=
>
&gt; transaction from a server to a wallet. You can make a custom transacti=
on<br>
&gt; and execute it in the same application but without Payments there&#39;=
s no<br>
&gt; way to move transactions between two applications. You need to build t=
he<br>
&gt; transaction where you execute it and thus need a key.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Jan 25, 2016 at 6:24 PM, Luke Dashjr &lt;<a href=3D"mailto:luk=
e@dashjr.org">luke@dashjr.org</a><br>
</span><div><div class=3D"h5">&gt; &lt;mailto:<a href=3D"mailto:luke@dashjr=
.org">luke@dashjr.org</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0This is a bad idea. OP_RETURN attachments are toler=
ated (not<br>
&gt;=C2=A0 =C2=A0 =C2=A0encouraged!) for<br>
&gt;=C2=A0 =C2=A0 =C2=A0the sake of the network, since the spam cannot be o=
utright stopped.<br>
&gt;=C2=A0 =C2=A0 =C2=A0If it<br>
&gt;=C2=A0 =C2=A0 =C2=A0could be outright stopped, it would not be reasonab=
le to allow<br>
&gt;=C2=A0 =C2=A0 =C2=A0OP_RETURN. When<br>
&gt;=C2=A0 =C2=A0 =C2=A0it comes to the payment protocol, however, changing=
 the current<br>
&gt;=C2=A0 =C2=A0 =C2=A0behaviour has<br>
&gt;=C2=A0 =C2=A0 =C2=A0literally no benefit to the network at all, and the=
 changes proposed<br>
&gt;=C2=A0 =C2=A0 =C2=A0herein<br>
&gt;=C2=A0 =C2=A0 =C2=A0are clearly detrimental since it would both encoura=
ge spam, and<br>
&gt;=C2=A0 =C2=A0 =C2=A0potentially<br>
&gt;=C2=A0 =C2=A0 =C2=A0make users unwilling (maybe even unaware) participa=
nts in it. For these<br>
&gt;=C2=A0 =C2=A0 =C2=A0reasons, *I highly advise against publishing or imp=
lementing this<br>
&gt;=C2=A0 =C2=A0 =C2=A0BIP, even if<br>
&gt;=C2=A0 =C2=A0 =C2=A0the later mentioned issues are fixed.*<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0On Tuesday, January 26, 2016 1:02:44 AM Toby Padill=
a wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; An example might be a merchant that adds the h=
ash of a plain text invoice<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; to the checkout transaction. The merchant coul=
d construct the<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; PaymentRequest with the invoice hash in an OP_=
RETURN and pass it to the<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; customer&#39;s wallet. The wallet could then s=
ubmit the transaction, including<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; the invoice hash from the PaymentRequest. The =
wallet will have encoded a<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; proof of purchase to the blockchain without th=
e wallet developer having to<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; coordinate with the merchant software or add f=
eatures beyond this BIP.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0Such a &quot;proof&quot; is useless without wallet =
support. Even if you argue<br>
&gt;=C2=A0 =C2=A0 =C2=A0it could<br>
&gt;=C2=A0 =C2=A0 =C2=A0be implemented later on, it stands to reason that a=
 scammer will<br>
&gt;=C2=A0 =C2=A0 =C2=A0simply encode<br>
&gt;=C2=A0 =C2=A0 =C2=A0garbage if the wallet is not checking the proof-of-=
purchase upfront.<br>
&gt;=C2=A0 =C2=A0 =C2=A0To check<br>
&gt;=C2=A0 =C2=A0 =C2=A0it, you would also need further protocol extensions=
 which are not<br>
&gt;=C2=A0 =C2=A0 =C2=A0included in<br>
&gt;=C2=A0 =C2=A0 =C2=A0this draft.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; Merchants and Bitcoin application developers b=
enefit from this BIP because<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; they can now construct transactions that inclu=
de OP_RETURN data in a<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; keyless environment. Again, prior to this BIP,=
 transactions that used<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; OP_RETURN (with zero value) needed to be const=
ructed and executed in the<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; same software. By separating the two concerns,=
 this BIP allows merchant<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; software to create transactions with OP_RETURN=
 metadata on a server without<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; storing public or private Bitcoin keys. This g=
reatly enhances security<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; where OP_RETURN applications currently need ac=
cess to a private key to sign<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; transactions.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0I don&#39;t see how this has any relevance to keys =
at all...<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; ## Specification<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; The specification for this BIP is straightforw=
ard. BIP70 should be fully<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; implemented with two changes:<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; 1. Outputs where the script is an OP_RETURN an=
d the value is zero should be<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; accepted by the wallet.<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; 2. Outputs where the script is an OP_RETURN an=
d the value is greater than<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; zero should be rejected.<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; This is a change from the BIP70 requirement th=
at all zero value outputs be<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; ignored.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0This does not appear to be backward nor even forwar=
d compatible. Old<br>
&gt;=C2=A0 =C2=A0 =C2=A0clients<br>
&gt;=C2=A0 =C2=A0 =C2=A0will continue to use the previous behaviour and tra=
nsparently omit any<br>
&gt;=C2=A0 =C2=A0 =C2=A0commitments. New clients on the other hand will fai=
l to include<br>
&gt;=C2=A0 =C2=A0 =C2=A0commitments<br>
&gt;=C2=A0 =C2=A0 =C2=A0produced by old servers. In other words, it is impo=
ssible to produce<br>
&gt;=C2=A0 =C2=A0 =C2=A0software<br>
&gt;=C2=A0 =C2=A0 =C2=A0compatible with both BIP 70 and this draft, and imp=
lementing either<br>
&gt;=C2=A0 =C2=A0 =C2=A0would<br>
&gt;=C2=A0 =C2=A0 =C2=A0result in severe consequences.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; As it exists today, BIP70 allows for OP_RETURN=
 data storage at the expense<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; of permanently destroyed Bitcoin.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0It is better for the spammers to lose burned bitcoi=
ns, than have a<br>
&gt;=C2=A0 =C2=A0 =C2=A0way to<br>
&gt;=C2=A0 =C2=A0 =C2=A0avoid them.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0Luke<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>

--001a1143fa4c5d7c6b052a40309a--