1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
|
Return-Path: <gcbd-bitcoin-development-2@m.gmane.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DC1A910D8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 14:37:24 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E044212E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 14:37:23 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development-2@m.gmane.org>)
id 1aO4k3-0005js-Ie for bitcoin-dev@lists.linuxfoundation.org;
Tue, 26 Jan 2016 15:37:11 +0100
Received: from f055101112.adsl.alicedsl.de ([78.55.101.112])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 15:37:11 +0100
Received: from andreas by f055101112.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 15:37:11 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-dev@lists.linuxfoundation.org
From: Andreas Schildbach <andreas@schildbach.de>
Date: Tue, 26 Jan 2016 15:37:15 +0100
Message-ID: <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: f055101112.adsl.alicedsl.de
X-Enigmail-Draft-Status: N1110
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.5.1
In-Reply-To: <CAGcHOzziBsF6DhX=TrgDJdYiOLHT-zwwX3FAUUkvfi1_4OmPKw@mail.gmail.com>
X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL,
RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, URIBL_SBL autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
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 14:37:25 -0000
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
>
|
