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
|
Return-Path: <kristovatlas.lists@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8EEB925A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Oct 2015 21:05:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com
[209.85.218.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0B27D147
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Oct 2015 21:05:40 +0000 (UTC)
Received: by oiad129 with SMTP id d129so55178790oia.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Oct 2015 14:05:39 -0700 (PDT)
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:to
:cc:content-type;
bh=Fv6Q+6/B4HpT4wJNEcyb64eStTQFUTTsdk/M+o5XPXk=;
b=mxQX8wm4YcdDb1cATg0ZFyPx3QlLXJnPVhhFMs/4/tVY4RHlKMQBUqSc7cqxtXkDJX
UdBGG37pdoa+Of6m4QQtDkDb2LjhX3pGaTJDktZ8I5rIR68GIP+vEzRCGkIQp1p17I8j
mESzf8GDFvPUKQMLy39UP8W+B0i7foKe5SkiIRpuPICJBSWZPbB79jArXhfYPK+mPSeZ
GRuiRq6MlozM8X1cr2qlriCjYIh3NTHEKqIzjS1RsJsxg8aix+iHeGP5/B3TD1Wa3qnI
+6ZOroe0UDJ3PQloHoY+iiEnB3GHucXf1PDagS4rpqpVlrobbqYX0rYFIcjY236QfK+w
Qf8w==
MIME-Version: 1.0
X-Received: by 10.202.83.73 with SMTP id h70mr11816141oib.119.1445547939449;
Thu, 22 Oct 2015 14:05:39 -0700 (PDT)
Received: by 10.202.108.203 with HTTP; Thu, 22 Oct 2015 14:05:39 -0700 (PDT)
In-Reply-To: <201510222043.17582.luke@dashjr.org>
References: <201510220554.00367.luke@dashjr.org>
<5628F8D2.1010709@openbitcoinprivacyproject.org>
<201510222043.17582.luke@dashjr.org>
Date: Thu, 22 Oct 2015 17:05:39 -0400
Message-ID: <CAGH37SJfZC0AA1mvrfhj5r8-Vb4UBM66-bpx9w1MAec1NFKHpQ@mail.gmail.com>
From: Kristov Atlas <kristovatlas.lists@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a113d3d026fd03b0522b7db80
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: Thu, 22 Oct 2015 21:20:18 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes
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: Thu, 22 Oct 2015 21:05:40 -0000
--001a113d3d026fd03b0522b7db80
Content-Type: text/plain; charset=UTF-8
The consequence of previous ECDH address proposals "not designing around
current software" is a sustained ~70% of transactions reusing addresses, as
you saw in my Reddit post recently.
If you have a fear that an inferior proposal will gain popularity, you can
always propose a superior one. If it's *actually* superior, it will win out.
On Thu, Oct 22, 2015 at 4:43 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thursday, October 22, 2015 2:55:14 PM Justus Ranvier wrote:
> > On 22/10/15 00:53, Luke Dashjr wrote:
> > > Sorry for the late review. I'm concerned with the "notification
> address"
> > > requirement, which entails address reuse and blockchain spam. Since it
> > > entails address reuse, the recipient is forced to either leave them
> > > unspent forever (bloating the UTXO set), or spend it which potentially
> > > compromises the private key, and (combined with the payment code)
> > > possibly as much as the entire wallet.
> > >
> > > Instead, I suggest making it a single zero-value OP_RETURN output with
> > > two pushes: 1) a hash of the recipient's payment code, and 2) the
> > > encrypted payment code. This can be searched with standard bloom
> > > filters, or indexed with whatever other optimised algorithms are
> > > desired. At the same time, it never uses any space in the UTXO set, and
> > > never needs to be
> > > spent/mixed/dusted.
> >
> > The notification transaction portion is my least-favorite portion of the
> > spec, but I don't see any alternatives that provide an unambiguous
> > improvement, including your suggestion.
> >
> > One of the most highly-weighted goals of this proposal is to be usable
> > on as many mobile/light wallets as possible.
> >
> > I know for sure that all existing platforms for balance querying index
> > by address. Support for bloom filters or other querying methods is less
> > comprehensive, meaning the set of wallets that can support payment codes
> > would be smaller.
>
> No, they just need to improve their software, and only to support receiving
> with payment codes (not sending to them). BIPs should in general not be
> designed around current software, especially in this case where there is no
> benefit to doing so (since it requires software upgrades anyway).
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113d3d026fd03b0522b7db80
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>The consequence of previous ECDH address proposa=
ls "not designing around current software" is a sustained ~70% of=
transactions reusing addresses, as you saw in my Reddit post recently.<br>=
</div><br></div>If you have a fear that an inferior proposal will gain popu=
larity, you can always propose a superior one. If it's *actually* super=
ior, it will win out.<br></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">On Thu, Oct 22, 2015 at 4:43 PM, Luke Dashjr via bitcoin-dev =
<span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=
=3D"h5">On Thursday, October 22, 2015 2:55:14 PM Justus Ranvier wrote:<br>
> On 22/10/15 00:53, Luke Dashjr wrote:<br>
> > Sorry for the late review. I'm concerned with the "notif=
ication address"<br>
> > requirement, which entails address reuse and blockchain spam. Sin=
ce it<br>
> > entails address reuse, the recipient is forced to either leave th=
em<br>
> > unspent forever (bloating the UTXO set), or spend it which potent=
ially<br>
> > compromises the private key, and (combined with the payment code)=
<br>
> > possibly as much as the entire wallet.<br>
> ><br>
> > Instead, I suggest making it a single zero-value OP_RETURN output=
with<br>
> > two pushes: 1) a hash of the recipient's payment code, and 2)=
the<br>
> > encrypted payment code. This can be searched with standard bloom<=
br>
> > filters, or indexed with whatever other optimised algorithms are<=
br>
> > desired. At the same time, it never uses any space in the UTXO se=
t, and<br>
> > never needs to be<br>
> > spent/mixed/dusted.<br>
><br>
> The notification transaction portion is my least-favorite portion of t=
he<br>
> spec, but I don't see any alternatives that provide an unambiguous=
<br>
> improvement, including your suggestion.<br>
><br>
> One of the most highly-weighted goals of this proposal is to be usable=
<br>
> on as many mobile/light wallets as possible.<br>
><br>
> I know for sure that all existing platforms for balance querying index=
<br>
> by address. Support for bloom filters or other querying methods is les=
s<br>
> comprehensive, meaning the set of wallets that can support payment cod=
es<br>
> would be smaller.<br>
<br>
</div></div>No, they just need to improve their software, and only to suppo=
rt receiving<br>
with payment codes (not sending to them). BIPs should in general not be<br>
designed around current software, especially in this case where there is no=
<br>
benefit to doing so (since it requires software upgrades anyway).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Luke<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>
</div></div></blockquote></div><br></div>
--001a113d3d026fd03b0522b7db80--
|
