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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5210B1014
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 02:24:51 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 4664E13E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 02:24:50 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 2904738A9923;
Tue, 26 Jan 2016 02:24:18 +0000 (UTC)
X-Hashcash: 1:25:160126:tobypadilla@gmail.com::R5atz4tZQ=o6oHLS:agd99
X-Hashcash: 1:25:160126:bitcoin-dev@lists.linuxfoundation.org::Cs20iZVw4VqI9tNJ:b5Aa/
From: Luke Dashjr <luke@dashjr.org>
To: Toby Padilla <tobypadilla@gmail.com>
Date: Tue, 26 Jan 2016 02:24:16 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; )
References: <CAGcHOzzde_T3xJwJL2Ehyw7U1FgxEEBJR30VBLdSZMj=W49hSg@mail.gmail.com>
In-Reply-To: <CAGcHOzzde_T3xJwJL2Ehyw7U1FgxEEBJR30VBLdSZMj=W49hSg@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201601260224.16917.luke@dashjr.org>
X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,RCVD_IN_SBL,
RP_MATCHES_RCVD autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.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 02:24:51 -0000
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
|
