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
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
|
Return-Path: <rsomsen@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 10ECAC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Oct 2022 23:01:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id CC0458321B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Oct 2022 23:01:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org CC0458321B
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=NEQaHRiT
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 68iDj2YUnS7l
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Oct 2022 23:01:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 702FF83123
Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com
[IPv6:2001:4860:4864:20::2a])
by smtp1.osuosl.org (Postfix) with ESMTPS id 702FF83123
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Oct 2022 23:01:17 +0000 (UTC)
Received: by mail-oa1-x2a.google.com with SMTP id
586e51a60fabf-1329abb0ec6so2028696fac.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 03 Oct 2022 16:01:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date;
bh=0hfWflq7LK05wnpA8Zp7DrQokFZoabeWXxth83QC248=;
b=NEQaHRiT7LkttoAoQWG9yvViurlBplVCCOXF6SPZgfTs242IcB60HKkK3sfwsS3Rgz
T5FrSMMKafqyP4GhMUwdPiAgECLECu8I9RaggeucWZzD6eXfuxCseXBRRgQhQnOzy3eI
A3lzh+2h67B4CJpPpgusWAOulzeDB4dKAVB1yz2+g0ZlCc2Il8iu9OjZieRgUf5TXZaa
i6Lcy/QCsdmBHyu08xAklb+9Y7Y9LEBNwwSgcn+wJurAqYbhVuAHIWFYzY0GjWvK53pn
AzBwbr/GVhKcDm7Twx6WivTEkgVRn1+FRPfm4Y2Hcl23DzpsUl6Iyw6elEsxJuadbGn1
nPag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date;
bh=0hfWflq7LK05wnpA8Zp7DrQokFZoabeWXxth83QC248=;
b=GnNRAXs8xwzHEJx92Xat8Bv4Sn3x+39PR/hE07LKLSe6xdSpA7j0jtDjyUAnw5P74o
96C5hJ0DzsbUQGlw+bAF8ouN+Z1rBK5oBSvMQUuZW2z45cBJ2gS7xoz8WlS6uJbSFKv+
wqD8X1ipWIfhADy92JA2AIixu/O2cd4l+9ByFMKIB4PApC6altvGfGz+aLqQOJfszFXD
6VysSvs/6+OxlORuCbS2ccrhnJcI7+pPago6sHRKhPvnQhuZttNQWkXePlUpiS/WeEkc
LH17rZaP/25lG+7XoQw8Yo2mmm/8Y56HE3KX0yh97Ny4OPdeJUIkirShD7IQz63LXp4Z
1OnA==
X-Gm-Message-State: ACrzQf3y4qBHuQK6T84/LyDjW2i7Ofya2DTaSH9NcJNPKRIW4V0s8Qbs
L2coyt3BfKKDNe2R+1bXzi/btLqgqytuHNbLICmoQjDB
X-Google-Smtp-Source: AMsMyM4vd2r1823fohkuauXAtZ5oFVABKTu58aWedCy2C2RZjI/uz+LtWHViTSmh31iUVU7nnoz5hY9IjfdAg4VHlgI=
X-Received: by 2002:a05:6870:c0c9:b0:127:c4df:5b50 with SMTP id
e9-20020a056870c0c900b00127c4df5b50mr6494662oad.126.1664838076419; Mon, 03
Oct 2022 16:01:16 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjbOcH2mte8SWALc2o5aEKLO7qoZ-M_e1wHdGSp6EmMc2Q@mail.gmail.com>
<9f399e0c2713f2b1d2534cd754356bb5@dtrt.org>
In-Reply-To: <9f399e0c2713f2b1d2534cd754356bb5@dtrt.org>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Tue, 4 Oct 2022 01:01:06 +0200
Message-ID: <CAPv7TjY=35H2rmCxBavLwe3+8A9osao0QAMF_grb6WFA502b5Q@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="00000000000027510305ea2952b9"
X-Mailman-Approved-At: Mon, 03 Oct 2022 23:05:36 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev]
=?utf-8?q?Trustless_Address_Server_=E2=80=93_Outsou?=
=?utf-8?q?rcing_handing_out_addresses_to_prevent_address_reuse?=
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol 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: Mon, 03 Oct 2022 23:01:19 -0000
--00000000000027510305ea2952b9
Content-Type: text/plain; charset="UTF-8"
Hi David,
Thanks for the excellent suggestion, that makes the protocol much more
elegant and actually increases my optimism about its practicality. Also,
interesting observation that there is overlap with BIP78. From the
perspective of the recipient it does mean there's a potential privacy
reduction when a placeholder transaction goes through (these should perhaps
be marked in the wallet?), but I suppose this is still better than no
payment at all. I also like your point that it doubles as a way to
potentially bridge gaps.
Cheers,
Ruben
On Mon, Oct 3, 2022 at 12:48 AM David A. Harding <dave@dtrt.org> wrote:
> On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wrote:
> > An alternative mitigation (more user friendly, but more implementation
> > complexity) would be to require the sender to reveal their intended
> > transaction to the server prior to receiving the address[^9]. This is
> > not a privacy degradation, since the server could already learn this
> > information regardless. If the transaction doesn't end up getting
> > sent, any subsequent attempt to reuse one of the inputs should either
> > be (temporarily) blacklisted or responded to with the same address
> > that was given out earlier
> > [...]
> > [^9]: *This would essentially look like an incomplete but signed
> > transaction where the output address is still missing.*
>
> Hi Ruben,
>
> Instead of maintaining a database of inputs that should be blocked or
> mapped to addresses, have the spender submit to you (but not the
> network) a valid transaction paying a placeholder address and in return
> give them a guaranteed unique address. They can then broadcast a
> transaction using the same inputs to pay the guaranteed unique address.
> If you don't see that transaction within a reasonable amount of time,
> broadcast the transaction paying the placeholder address. This makes it
> cost the same to them whether they use the unique address or not. By
> placeholder address, I mean an address of yours that's never received a
> payment but which may have been provided in a previous invoice (e.g. to
> prevent exceeding the gap limit).
>
> In short, what I think I've described is the BIP78 payjoin protocol
> without any payjoining going on (which is allowed by BIP78). BTCPay
> already implements BIP78, as do several wallets, and I think it
> satisfies all the design constraints you've described.
>
> -Dave
>
--00000000000027510305ea2952b9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi David,<div><br></div><div>Thanks for the excellent sugg=
estion, that makes the=C2=A0protocol much more elegant and actually increas=
es my optimism=C2=A0about its practicality. Also, interesting observation t=
hat there is overlap with BIP78. From the perspective of the recipient it d=
oes mean there's a potential privacy reduction when a placeholder trans=
action goes through (these should perhaps be marked in the wallet?), but I =
suppose this is still better than no payment at all. I also like your point=
that it doubles=C2=A0as a way to potentially bridge gaps.</div><div><br></=
div><div>Cheers,</div><div>Ruben</div><div><br></div><div><br></div><div><b=
r></div><div><br></div><div><br></div><div><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Oct 3, 2022 =
at 12:48 AM David A. Harding <<a href=3D"mailto:dave@dtrt.org" target=3D=
"_blank">dave@dtrt.org</a>> wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wro=
te:<br>
> An alternative mitigation (more user friendly, but more implementation=
<br>
> complexity) would be to require the sender to reveal their intended<br=
>
> transaction to the server prior to receiving the address[^9]. This is<=
br>
> not a privacy degradation, since the server could already learn this<b=
r>
> information regardless. If the transaction doesn't end up getting<=
br>
> sent, any subsequent attempt to reuse one of the inputs should either<=
br>
> be (temporarily) blacklisted or responded to with the same address<br>
> that was given out earlier<br>
> [...]<br>
> [^9]: *This would essentially look like an incomplete but signed<br>
> transaction where the output address is still missing.*<br>
<br>
Hi Ruben,<br>
<br>
Instead of maintaining a database of inputs that should be blocked or <br>
mapped to addresses, have the spender submit to you (but not the <br>
network) a valid transaction paying a placeholder address and in return <br=
>
give them a guaranteed unique address.=C2=A0 They can then broadcast a <br>
transaction using the same inputs to pay the guaranteed unique address.=C2=
=A0 <br>
If you don't see that transaction within a reasonable amount of time, <=
br>
broadcast the transaction paying the placeholder address.=C2=A0 This makes =
it <br>
cost the same to them whether they use the unique address or not.=C2=A0 By =
<br>
placeholder address, I mean an address of yours that's never received a=
<br>
payment but which may have been provided in a previous invoice (e.g. to <br=
>
prevent exceeding the gap limit).<br>
<br>
In short, what I think I've described is the BIP78 payjoin protocol <br=
>
without any payjoining going on (which is allowed by BIP78).=C2=A0 BTCPay <=
br>
already implements BIP78, as do several wallets, and I think it <br>
satisfies all the design constraints you've described.<br>
<br>
-Dave<br>
</blockquote></div>
--00000000000027510305ea2952b9--
|