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
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
|
Delivery-date: Sun, 05 May 2024 06:31:00 -0700
Received: from mail-yb1-f190.google.com ([209.85.219.190])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBCQ6HM7U3YGRBCUU32YQMGQEHS5H7JQ@googlegroups.com>)
id 1s3bxD-0006ie-10
for bitcoindev@gnusha.org; Sun, 05 May 2024 06:31:00 -0700
Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-dc6b26783b4sf1458853276.0
for <bitcoindev@gnusha.org>; Sun, 05 May 2024 06:30:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1714915853; x=1715520653; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=5BAY+17HINflt0JLKT0uuD+K9c7pan7+sO/7DMBqqSc=;
b=lw/Xsqq+zOxyLd6EWPVLPzoNeJFT+WYybDGwhSZGWqZ4cTS92VG5/dTnJg4dXNCsr+
9bI8LciA8lXuWExNFB0KdxBJ4OKaKyQFKsXrx3Jq3dbBsz9NmsER7V3Ou9P1XxTCdMwj
dyYKV45ScbmmYcxct0DZSD5iIdCkNMpJTOtnt86LHKChut9EwdDDWBmTAnaieGLB1kg2
enkiT/uwyigQZo4VFuvYHrr+B/xCGSYeT1ko17Tkf1mzf7/pJrsv08TyrpS4hehZfkl6
JjB0WsFERJA8B4znsi+RfoZaCtK8hkqJBUewROW2ku9hGe1u7oOoW/xr7f7QGwjYicme
YqlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1714915853; x=1715520653;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=5BAY+17HINflt0JLKT0uuD+K9c7pan7+sO/7DMBqqSc=;
b=oGvu/au2Y/W7LpwgkNOnnLLt2vICg3OkWFv5KG+HTaUwc11WdHI6sqJI56IUSK9aMR
LQ6SO93LJHNjOhdpXfVKoMelSSyicrdZbSrwJ+9K3SLR6PHBxoLyl7DzF5fyhyeFsVN+
k6JGj0Ml+qqysgOUwAHZvmWuwOkfUYP3ynfztvayNZZDxHRg5yq/RcTqH7Ujv11nne/c
j9PohwxMx4ZBf+BadnRhhkw1oHUmQ1YgWDAa9X3bSvYOVCpAsDA+1vZeT065uzJAc9KL
tDOZmINc36Zlb1r0RIIGGaMOm/uYyA6bn6uj3c6BxKmYZnpGfexibJqyc6zFh3K6ki6t
05zw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWPaNSsK9XfDw2n/tJUwlz1KYlMbf4NuBye4zZuc0fgNTPExKZcmH9FoZjSG/aQpqOI1r53PshEQXwRW8kUywi1ANe6FFg=
X-Gm-Message-State: AOJu0YxMYXNj9poC/jQOF5I2i8nFEH34z3UxquACrt9qTGmansOUT+fY
4GAD0xxzqg9ye4ozS5LeUJzy3UqTCUv/SGmilu+twQSKiPBrSLnb
X-Google-Smtp-Source: AGHT+IF937++d4AKCY61mKwqllkw1ONikodVU8vH99vMRiQju4GpgJZJDeuyXNIEpoWfj/IjrVhMDQ==
X-Received: by 2002:a25:74d7:0:b0:de5:4bb7:b237 with SMTP id p206-20020a2574d7000000b00de54bb7b237mr8003550ybc.39.1714915852197;
Sun, 05 May 2024 06:30:52 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:6891:0:b0:de6:10bb:1374 with SMTP id 3f1490d57ef6-de8b54f8c1als1932764276.2.-pod-prod-09-us;
Sun, 05 May 2024 06:30:50 -0700 (PDT)
X-Received: by 2002:a05:6902:110d:b0:dcd:875:4c40 with SMTP id o13-20020a056902110d00b00dcd08754c40mr2549726ybu.10.1714915850581;
Sun, 05 May 2024 06:30:50 -0700 (PDT)
Received: by 2002:a05:690c:108:b0:620:2f19:bc4e with SMTP id 00721157ae682-6202f19d91bms7b3;
Sun, 5 May 2024 05:09:47 -0700 (PDT)
X-Received: by 2002:a05:6902:1244:b0:dc7:68b5:4f21 with SMTP id t4-20020a056902124400b00dc768b54f21mr2431556ybu.9.1714910986677;
Sun, 05 May 2024 05:09:46 -0700 (PDT)
Date: Sun, 5 May 2024 05:09:46 -0700 (PDT)
From: Ali Sherief <ali@notatether.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <5fcc4168-b4fd-4efd-b11c-6bbf852871ccn@googlegroups.com>
In-Reply-To: <e617f6eb-dd11-4ca2-aba6-f80ace8863a8@dashjr.org>
References: <9004c5d4-6b9d-4ac1-834c-902ba4901e05n@googlegroups.com>
<e617f6eb-dd11-4ca2-aba6-f80ace8863a8@dashjr.org>
Subject: Re: [bitcoindev] BIP 322 use case
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_202540_1349781892.1714910986313"
X-Original-Sender: ali@notatether.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.7 (/)
------=_Part_202540_1349781892.1714910986313
Content-Type: multipart/alternative;
boundary="----=_Part_202541_45680655.1714910986313"
------=_Part_202541_45680655.1714910986313
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> But the feature with much higher demand is proof-of-funds and=20
proof-of-sender, which BIP322 began to address, but turns out to be much=20
more complicated than it seems at face value (I recently looked into this=
=20
again as part of relaunching OCEAN).
BIP322 is trying to figure two things: Collecting an authentic UTXO set for=
=20
a given list of addresses, and actually making the signed message. It=20
appears that only the latter of the two has been solved.
I think one of the things that would help unstuck this is an RPC for=20
getting the UTXO set of a list of addresses. I am aware that this is=20
already possible with some SPV implementations, but to have the=20
functionality directly in Core would make this BIP more viable.
> That being said, BIP322 as-is has already been adopted by at least some=
=20
wallets, despite its unfinished state. So if someone were to pick up this=
=20
task, it would probably need to be done as a new BIP
Probably the best solution would be to make a split, where the BIP322 draft=
=20
as it currently is can be used unofficially and then programmed into=20
software that needs it, and then you can have the actual=20
authentication/contract mechanism constructed in a new BIP. Actually, we=20
already have some of the framework for this in Core, since PSBTs can be=20
used to distribute and sign "message contracts". All that's needed is an=20
RPC to get the UTXO set and another to create an unsigned template=20
transaction for the message.
-Ali
On Saturday, May 4, 2024 at 12:14:53=E2=80=AFAM UTC Luke Dashjr wrote:
KYC is not an intended use case for signed messages, and attempts to use it=
=20
for that are probably one of the bigger reasons BIP322 has not moved=20
further - most people do not want to encourage nor enable such nonsense. If=
=20
you absolutely must only allow withdrawls to the user's own address, I=20
would suggest taking a more traditional approach of asking the user to=20
affirm it with a checkbox. (This is not legal advice, but it seems crazy to=
=20
demand cryptographic proof from Bitcoin companies, when traditional finance=
=20
is okay with a mere attestation)
Technically speaking, however, the biggest hurdle is that there is very=20
little apparent interest in the one limited use case it *is* meant for:=20
agreeing to a contract before funds are sent. To a limited extent, a=20
secondary use case has been simply using Bitcoin addresses as a kind of=20
login mechanism (eg, #Bitcoin-OTC and OCEAN). But the feature with much=20
higher demand is proof-of-funds and proof-of-sender, which BIP322 began to=
=20
address, but turns out to be much more complicated than it seems at face=20
value (I recently looked into this again as part of relaunching OCEAN).=20
That being said, BIP322 as-is has already been adopted by at least some=20
wallets, despite its unfinished state. So if someone were to pick up this=
=20
task, it would probably need to be done as a new BIP. :/
Luke
On 5/3/24 19:53, ProfEduStream wrote:
Hey,
As a Bitcoin association, we're currently facing an issue because we're=20
unable to sign an address with our multi-sig wallet.
After conducting some research, I came across BIP322 in these threads:=20
https://bitcointalk.org/index.php?topic=3D5408898.0 &=20
https://github.com/bitcoin/bips/pull/1347
*Explanation*:
As a Bitcoin association, we offer membership to everyone for a few=20
thousand sats per year. To facilitate this process, we utilize "Swiss=20
Bitcoin Pay". It's an application that allows us to easily manage our=20
accounting. Additionally, we onboard merchants with this app because of its=
=20
user-friendly interface and self-custodial capabilities, making it very=20
convenient. The accounting features are also highly beneficial.
To utilize this application in a self-custodial manner, users need to paste=
=20
a Bitcoin address on the "Swiss Bitcoin Pay" dashboard and then sign a=20
message with this address. This serves as a "Proof-of-Ownership" and is a=
=20
legal requirement in some regulated countries. "Swiss Bitcoin Pay" is not=
=20
the only application that requires signing a message as a=20
"Proof-of-Ownership". Peach, a non-KYC P2P Bitcoin application, is another=
=20
example.
Given our goal to decentralize our treasury, we naturally opt for a=20
multi-sig wallet, similar to many companies. However, as you know, BIP 322=
=20
hasn't been pushed and it's currently impossible to sign a message with a=
=20
multi-sig wallet.
*Conclusion*:
I'm unsure why BIP322 hasn't been pushed or addressed in the past few=20
months/years, but I want to highlight its necessity.
Additionally, I hope that this comment sheds light on a deficiency in our=
=20
Bitcoin ecosystem, and I trust that further improvements will be made to=20
enable people to sign a message with a multi-sig wallet.
I'm available to assist if needed.
@ProfEduStream
--=20
You received this message because you are subscribed to the Google Groups=
=20
"Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an=
=20
email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit=20
https://groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-4ac1-834c-902ba4=
901e05n%40googlegroups.com=20
<https://groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-4ac1-834c-902ba=
4901e05n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
.
=20
--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/5fcc4168-b4fd-4efd-b11c-6bbf852871ccn%40googlegroups.com.
------=_Part_202541_45680655.1714910986313
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div>>=C2=A0But the feature with much higher demand is proof-of-funds an=
d proof-of-sender, which BIP322 began to address, but turns out to be much =
more complicated than it seems at face value (I recently looked into this a=
gain as part of relaunching OCEAN).</div><div><br /></div><div>BIP322 is tr=
ying to figure two things: Collecting an authentic UTXO set for a given lis=
t of addresses, and actually making the signed message. It appears that onl=
y the latter of the two has been solved.</div><div><br /></div><div>I think=
one of the things that would help unstuck this is an RPC for getting the U=
TXO set of a list of addresses. I am aware that this is already possible wi=
th some SPV implementations, but to have the functionality directly in Core=
would make this BIP more viable.</div><div><br /></div>>=C2=A0That bein=
g said, BIP322 as-is has already been adopted by at least some wallets, des=
pite its unfinished state. So if someone were to pick up this task, it woul=
d probably need to be done as a new BIP<div><br /></div><div>Probably the b=
est solution would be to make a split, where the BIP322 draft as it current=
ly is can be used unofficially and then programmed into software that needs=
it, and then you can have the actual authentication/contract mechanism con=
structed in a new BIP. Actually, we already have some of the framework for =
this in Core, since PSBTs can be used to distribute and sign "message contr=
acts". All that's needed is an RPC to get the UTXO set and another to creat=
e an unsigned template transaction for the message.</div><div><br /></div><=
div>-Ali<br /><br /><div><div dir=3D"auto">On Saturday, May 4, 2024 at 12:1=
4:53=E2=80=AFAM UTC Luke Dashjr wrote:<br /></div><blockquote style=3D"marg=
in: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-l=
eft: 1ex;"><u></u>
=20
=20
=20
<div>
<p>KYC is not an intended use case for signed messages, and attempts
to use it for that are probably one of the bigger reasons BIP322
has not moved further - most people do not want to encourage nor
enable such nonsense. If you absolutely must only allow withdrawls
to the user's own address, I would suggest taking a more
traditional approach of asking the user to affirm it with a
checkbox. (This is not legal advice, but it seems crazy to demand
cryptographic proof from Bitcoin companies, when traditional
finance is okay with a mere attestation)<br />
</p>
<p>Technically speaking, however, the biggest hurdle is that there
is very little apparent interest in the one limited use case it
*is* meant for: agreeing to a contract before funds are sent. To a
limited extent, a secondary use case has been simply using Bitcoin
addresses as a kind of login mechanism (eg, #Bitcoin-OTC and
OCEAN). But the feature with much higher demand is proof-of-funds
and proof-of-sender, which BIP322 began to address, but turns out
to be much more complicated than it seems at face value (I
recently looked into this again as part of relaunching OCEAN).
That being said, BIP322 as-is has already been adopted by at least
some wallets, despite its unfinished state. So if someone were to
pick up this task, it would probably need to be done as a new BIP.
:/<br />
</p>
<p>Luke</p></div><div>
<p><br />
</p>
<div>On 5/3/24 19:53, ProfEduStream wrote:<br />
</div>
</div><div><blockquote type=3D"cite">
<p dir=3D"auto">Hey,</p>
<p dir=3D"auto">As a Bitcoin association, we're currently facing an
issue because we're unable to sign an address with our multi-sig
wallet.<br />
After conducting some research, I came across BIP322 in these
threads:<span> </span><a href=3D"https://bitcointalk.org/index.php?=
topic=3D5408898.0" target=3D"_blank" rel=3D"nofollow">https://bitcointalk.o=
rg/index.php?topic=3D5408898.0</a>
& <a href=3D"https://github.com/bitcoin/bips/pull/1347" target=
=3D"_blank" rel=3D"nofollow">https://github.com/bitcoin/bips/pull/1347</a><=
br />
<br />
</p>
<p dir=3D"auto"><u>Explanation</u>:</p>
<p dir=3D"auto">As a Bitcoin association, we offer membership to
everyone for a few thousand sats per year. To facilitate this
process, we utilize "Swiss Bitcoin Pay". It's an application
that allows us to easily manage our accounting. Additionally, we
onboard merchants with this app because of its user-friendly
interface and self-custodial capabilities, making it very
convenient. The accounting features are also highly beneficial.</p>
<p dir=3D"auto">To utilize this application in a self-custodial
manner, users need to paste a Bitcoin address on the "Swiss
Bitcoin Pay" dashboard and then sign a message with this
address. This serves as a "Proof-of-Ownership" and is a legal
requirement in some regulated countries. "Swiss Bitcoin Pay" is
not the only application that requires signing a message as a
"Proof-of-Ownership". Peach, a non-KYC P2P Bitcoin application,
is another example.</p>
<p dir=3D"auto">Given our goal to decentralize our treasury, we
naturally opt for a multi-sig wallet, similar to many companies.
However, as you know, BIP 322 hasn't been pushed and it's
currently impossible to sign a message with a multi-sig wallet.</p>
<p dir=3D"auto"><br />
</p>
<p dir=3D"auto"><u>Conclusion</u>:</p>
<p dir=3D"auto">I'm unsure why BIP322 hasn't been pushed or
addressed in the past few months/years, but I want to highlight
its necessity.<br />
Additionally, I hope that this comment sheds light on a
deficiency in our Bitcoin ecosystem, and I trust that further
improvements will be made to enable people to sign a message
with a multi-sig wallet.</p>
<p dir=3D"auto"><br />
</p>
<p dir=3D"auto">I'm available to assist if needed<span>.</span></p>
<p dir=3D"auto"><span>@ProfEduStream<br />
</span></p></blockquote></div><div><blockquote type=3D"cite">
-- <br />
You received this message because you are subscribed to the Google
Groups "Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it,
send an email to <a href=3D"" rel=3D"nofollow">bitcoindev+...@googleg=
roups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/d/msgid/bitcoindev/9004c5d4-6b9d-4ac1-834c-902ba4901e05n%40googleg=
roups.com?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" rel=
=3D"nofollow">https://groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-4a=
c1-834c-902ba4901e05n%40googlegroups.com</a>.<br /></blockquote></div></blo=
ckquote><div>=C2=A0</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/5fcc4168-b4fd-4efd-b11c-6bbf852871ccn%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/5fcc4168-b4fd-4efd-b11c-6bbf852871ccn%40googlegroups.com</a>.=
<br />
------=_Part_202541_45680655.1714910986313--
------=_Part_202540_1349781892.1714910986313--
|