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
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
|
Delivery-date: Sat, 11 May 2024 09:28:00 -0700
Received: from mail-yb1-f189.google.com ([209.85.219.189])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBD22VYWNUENRBB5Z72YQMGQEYUIN3XY@googlegroups.com>)
id 1s5pZm-00039a-So
for bitcoindev@gnusha.org; Sat, 11 May 2024 09:28:00 -0700
Received: by mail-yb1-f189.google.com with SMTP id 3f1490d57ef6-de468af2b73sf5747548276.0
for <bitcoindev@gnusha.org>; Sat, 11 May 2024 09:27:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1715444873; x=1716049673; 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=SLyCnwF2oJy9ExYRnfrWUOSdwPMiYiraWVXFpunMkPY=;
b=FuR8nq1o4UhHIZuaJxh9gX6FusQcd2qDOV3mpki224Z74wUDY3/9J0v9R/3pzUo5e/
JzpFiHQdxaLEFrPFnuHaemyJyLag5BunyO/gRfahmeh1hyz1C+EFskVZyMQDZCEZBvVo
e0BccE/SdmcCslXI4Jp4LwdiKOkcUo/FK5RSI2xvssNfNXGEdusLHNa4lHXZye/rpdGL
GB2owK92q5bW3A8JBuSEXNVhlONcZk3+boD1kxRRiYPtKz/SaU5TzrFCVDh9W9cB35B0
0cl80VFDkCqmqk3I9qJf8SWp8L92uPO+A1YyK/wuG7wlLV6kfASoCONLvLb6z6ubFztT
YUhg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1715444873; x=1716049673; 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:from:to:cc
:subject:date:message-id:reply-to;
bh=SLyCnwF2oJy9ExYRnfrWUOSdwPMiYiraWVXFpunMkPY=;
b=Ffr10yS9Z0ZuZBQa2bVmZqleCFgG7gycnIRDpmRcJxs9m40sh6/ipadnI3d48koY5O
o6sSZ9uzOgM18CTBCLqR9dXMUpMSI90fSYxFdu7GHpC4d0S7OfXsPqsvDp4+O1hJNy38
frGrgMKc76jtdgEDX6cwhm4Shr4h1hNfP3WzX/7C+rOhxjm/eM/1I8zo2mDAQtdQjxxn
EB5lzu/j1bJamMiu+ZxC3Dri3hBGAzlA+VSsYnlkkZI3+xDsB+BDf1QQRJ/YUlrTf3t1
/XwcXrNjbXUWFUi+YKWcHE02MseqermaJWExNzuLak9YW9KPlSpHWJaC5pOWFCiHowJ3
V1/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1715444873; x=1716049673;
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=SLyCnwF2oJy9ExYRnfrWUOSdwPMiYiraWVXFpunMkPY=;
b=KiryGhzH09PhC+5txzZOuWfO5KDIC5XDL/OFcRnZAkf9qyFCXzIHn/vubkMuK56lxH
ijwOlaYRC9P+cEYMDR4iVKSfwLB2k6qhdmAcpB+hucIFw9nCPfkr41r+W4KA4bAOmLZl
tL8fjKRnmn0GTfawjj1uxnodaBJm4pRqZPT5cDevTUQLhU6ECFuxdRrG51aEFX7qbjRI
MAukFO7yQFGBPeyTHUcTmU2FjF7WYbOWHepQDpXzwaS27mbqzOZnumEsQLBHBz1NsEw0
d0jAY7LpOP+q22UI75pV7PHgOzLy/WBJTmKd/k4aFnj8ENODDSR94NJk/UquZyA6CBws
icqg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWuxYyjr6itXL6boGq80GCQY7yRyGFCPPmU1Mc8OlXQXnsx7No3zw3PFAV8Rnm+UB40Iml0m5ZVAaHyKIfUa6zp6hnSuxo=
X-Gm-Message-State: AOJu0Yyfin+fGG9R9V7qcj+s/7QYxaoTXFgdoOyP+FefnLC5lZtbxGep
sgUJENnZw1H9FFmLtCPePWkVv+IkZ5Wek3pMYeqwd9V6YKtTX8xC
X-Google-Smtp-Source: AGHT+IGgsKvCVd5cHMc4wZyevuBTexnBSR1ZnpmhgKbN0M5TS4a6ujlxs8bqA2uywEY62jjp799edg==
X-Received: by 2002:a25:8445:0:b0:dc6:19ea:9204 with SMTP id 3f1490d57ef6-dee4f508f1dmr5777486276.61.1715444872654;
Sat, 11 May 2024 09:27:52 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:c544:0:b0:deb:438a:43c1 with SMTP id 3f1490d57ef6-debd086c93bls697138276.1.-pod-prod-06-us;
Sat, 11 May 2024 09:27:51 -0700 (PDT)
X-Received: by 2002:a05:690c:3383:b0:61a:bfc8:64ce with SMTP id 00721157ae682-622b001a073mr15830437b3.8.1715444871199;
Sat, 11 May 2024 09:27:51 -0700 (PDT)
Received: by 2002:a05:690c:10d:b0:620:26bb:319f with SMTP id 00721157ae682-622afab6ec0ms7b3;
Fri, 10 May 2024 10:47:11 -0700 (PDT)
X-Received: by 2002:a05:690c:6202:b0:61b:e2eb:f05 with SMTP id 00721157ae682-622afdd93e5mr8793187b3.2.1715363230444;
Fri, 10 May 2024 10:47:10 -0700 (PDT)
Date: Fri, 10 May 2024 10:47:10 -0700 (PDT)
From: Prof EduStream <profedustream@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <050ed80d-f4a1-48de-8808-a8af7fac3cf1n@googlegroups.com>
In-Reply-To: <b7861fc2-d980-4c3a-a472-ea7aead01692@dashjr.org>
References: <9004c5d4-6b9d-4ac1-834c-902ba4901e05n@googlegroups.com>
<e617f6eb-dd11-4ca2-aba6-f80ace8863a8@dashjr.org>
<5fcc4168-b4fd-4efd-b11c-6bbf852871ccn@googlegroups.com>
<b7861fc2-d980-4c3a-a472-ea7aead01692@dashjr.org>
Subject: Re: [bitcoindev] BIP 322 use case
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_60486_1824040206.1715363230038"
X-Original-Sender: profedustream@gmail.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.5 (/)
------=_Part_60486_1824040206.1715363230038
Content-Type: multipart/alternative;
boundary="----=_Part_60487_1004776637.1715363230038"
------=_Part_60487_1004776637.1715363230038
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hey,
@Luke: You said a few days ago that signing a message with a multi-sig=20
address doesn't have lots of use cases. That's true. But I would argue that=
=20
the use cases are the same as signing a message with a single-sig address:=
=20
being able to cryptographically show that you own an address, which is=20
possible in Bitcoin.
I also don't understand why a multi-sig user =E2=80=94 who uses a multi-sig=
wallet=20
to secure their bitcoins =E2=80=94 couldn't be able to do the same things a=
s a=20
single-sig user.
Not wanting to create tools or features that could be used as compliance=20
tools is an answer, and as a privacy advocate I do understand this point of=
=20
view. However, single-sig signing already exists, and multi-sig signing=20
would only extend this feature to a few people for their personal use; plus=
=20
some companies, which are already compliant.
*> "That being said, BIP322 as-is has already been adopted by at least some=
=20
wallets, despite its unfinished state"*
@Luke & @Ali: I have tried numerous wallets in the past few weeks, but=20
none of them seemed to have adopted BIP322. If you have any further=20
information (or GitHub implementation / repo), please feel free to send it=
=20
to me.=20
Thank you both for your answers,
@ProfEduStream
Le dimanche 5 mai 2024 =C3=A0 16:54:28 UTC+2, Luke Dashjr a =C3=A9crit :
> Addresses are not tied to UTXOs. A proof-of-funds would only ever be=20
> proving a numeric amount, not an address. While the proof would necessari=
ly=20
> use UTXOs behind-the-scenes, the signature would not be committing to tho=
se=20
> specific UTXOs being the property of the message-signer; this property is=
=20
> necessary for plausible deniability as well as hot/cold wallet separation=
=20
> (multiple users could have signed messages using the same UTXOs, yet=20
> reflecting distinct bitcoin claims).
>
> Proof-of-sender, on the other hand, would make a claim to have sent a=20
> specific txid and output index. Where this gets fairly complicated is tha=
t=20
> it's somewhat important to have a mechanism that is compatible with=20
> coinjoins, and without requiring the coinjoin participants to keep in=20
> contact after the transaction is formed. It should able be compatible wit=
h=20
> signing for transactions sent without preparation to sign messages later.=
=20
> Ultimately, this requires delegation.
>
> And since it wouldn't be great to be able to distinguish between delegate=
d=20
> and non-delegated, probably everything should just always be delegated=20
> (perhaps to a deterministic keypair in some scenarios).
>
> There's also potentially a use case for accepting an opcode rejects on=20
> mainnet as invalid, so tapscripts can commit to sign-only script paths.
>
> One thing all the current message signing standards lack is some kind of=
=20
> magic heading to identify what they are, like bech32's "bc1" prefix. This=
=20
> would be a trivial addition rather than trying to decode signatures N=20
> different ways and seeing which verify.
>
> I do agree being able to, at least internally, convert to/from PSBTs woul=
d=20
> improve compatibility significantly. This was the approach I aimed for wh=
en=20
> I tried to tackle it a few months ago. One limitation with PSBTs is that=
=20
> each input needs non-witness and/or witness input data - repeatedly, if=
=20
> multiple of the same transaction's outputs are used as inputs. To address=
=20
> that, I was planning to support having them refer back to previous inputs=
'=20
> data.
>
> Hope all this helps, if someone wants to pick up the task...
>
> Luke
> On 5/5/24 08:09, Ali Sherief wrote:
>
> > 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=
=20
> for 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=20
>
> Probably the best solution would be to make a split, where the BIP322=20
> draft as it currently is can be used unofficially and then programmed int=
o=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=
=20
> it 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 finan=
ce=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 t=
o=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 i=
ts=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=20
> paste a Bitcoin address on the "Swiss Bitcoin Pay" dashboard and then sig=
n=20
> a 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 anothe=
r=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 32=
2=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-902b=
a4901e05n%40googlegroups.com=20
> <https://groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-4ac1-834c-902=
ba4901e05n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>
> =20
> --=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/5fcc4168-b4fd-4efd-b11c-6bbf=
852871ccn%40googlegroups.com=20
> <https://groups.google.com/d/msgid/bitcoindev/5fcc4168-b4fd-4efd-b11c-6bb=
f852871ccn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>
>
--=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/050ed80d-f4a1-48de-8808-a8af7fac3cf1n%40googlegroups.com.
------=_Part_60487_1004776637.1715363230038
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div>Hey,</div><div></div><div><br /></div><div>@Luke: You said a few days =
ago that signing a message with a multi-sig address doesn't have lots of us=
e cases. That's true. But I would argue that the use cases are the same as =
signing a message with a single-sig address: being able to cryptographicall=
y show that you own an address, which is possible in Bitcoin.</div><div>I a=
lso don't understand why a multi-sig user =E2=80=94 who uses a multi-sig wa=
llet to secure their bitcoins =E2=80=94 couldn't be able to do the same thi=
ngs as a single-sig user.</div><div><br /></div><div>Not wanting to create =
tools or features that could be used as compliance tools is an answer, and =
as a privacy advocate I do understand this point of view. However, single-s=
ig signing already exists, and multi-sig signing would only extend this fea=
ture to a few people for their personal use; plus some companies, which are=
already compliant.</div><div><br /></div><div><br /></div><div><i>> "Th=
at being said, BIP322 as-is has already been adopted by at least some walle=
ts, despite its unfinished state"</i></div><div><i><br /></i></div><div>=C2=
=A0@Luke & @Ali: I have tried numerous wallets in the past few weeks, b=
ut none of them seemed to have adopted BIP322. If you have any further info=
rmation (or GitHub implementation / repo), please feel free to send it to m=
e. </div><div><br /></div><div><br /></div><div>Thank you both for your ans=
wers,</div><div>@ProfEduStream<br /></div><div class=3D"gmail_quote"><div d=
ir=3D"auto" class=3D"gmail_attr">Le dimanche 5 mai 2024 =C3=A0 16:54:28 UTC=
+2, Luke Dashjr a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204=
); padding-left: 1ex;"><u></u>
=20
=20
=20
<div>
<p>Addresses are not tied to UTXOs. A proof-of-funds would only ever
be proving a numeric amount, not an address. While the proof would
necessarily use UTXOs behind-the-scenes, the signature would not
be committing to those specific UTXOs being the property of the
message-signer; this property is necessary for plausible
deniability as well as hot/cold wallet separation (multiple users
could have signed messages using the same UTXOs, yet reflecting
distinct bitcoin claims).</p>
<p>Proof-of-sender, on the other hand, would make a claim to have
sent a specific txid and output index. Where this gets fairly
complicated is that it's somewhat important to have a mechanism
that is compatible with coinjoins, and without requiring the
coinjoin participants to keep in contact after the transaction is
formed. It should able be compatible with signing for transactions
sent without preparation to sign messages later. Ultimately, this
requires delegation.</p>
<p>And since it wouldn't be great to be able to distinguish between
delegated and non-delegated, probably everything should just
always be delegated (perhaps to a deterministic keypair in some
scenarios).</p>
<p>There's also potentially a use case for accepting an opcode
rejects on mainnet as invalid, so tapscripts can commit to
sign-only script paths.</p>
<p>One thing all the current message signing standards lack is some
kind of magic heading to identify what they are, like bech32's
"bc1" prefix. This would be a trivial addition rather than =
trying
to decode signatures N different ways and seeing which verify.</p>
<p>I do agree being able to, at least internally, convert to/from
PSBTs would improve compatibility significantly. This was the
approach I aimed for when I tried to tackle it a few months ago.
One limitation with PSBTs is that each input needs non-witness
and/or witness input data - repeatedly, if multiple of the same
transaction's outputs are used as inputs. To address that, I was
planning to support having them refer back to previous inputs'
data.</p>
<p>Hope all this helps, if someone wants to pick up the task...</p>
<p>Luke<br>
</p></div><div>
<div>On 5/5/24 08:09, Ali Sherief wrote:<br>
</div>
</div><div><blockquote type=3D"cite">
<div>>=C2=A0But 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).</div>
<div><br>
</div>
<div>BIP322 is trying to figure two things: Collecting an
authentic UTXO set for a given list of addresses, and actually
making the signed message. It appears that only 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 UTXO set of a list of addresses. I am aware
that this is already possible with some SPV implementations, but
to have the functionality directly in Core would make this BIP
more viable.</div>
<div><br>
</div>
>=C2=A0That being said, BIP322 as-is has already been adopted by a=
t
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
<div><br>
</div>
<div>Probably the best solution would be to make a split, where
the BIP322 draft as it currently is can be used unofficially and
then programmed into software that needs it, and then you can
have the actual authentication/contract mechanism constructed 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 contracts". All that's needed is an RPC to g=
et the UTXO
set and another to create 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:14:53=E2=80=AFAM=
UTC
Luke Dashjr wrote:<br>
</div>
<blockquote>
<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 mor=
e
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 current=
ly
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://bitcoin=
talk.org/index.php?topic=3D5408898.0" rel=3D"nofollow" target=3D"_blank" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://bi=
tcointalk.org/index.php?topic%3D5408898.0&source=3Dgmail&ust=3D1715=
448391881000&usg=3DAOvVaw3QcW7zGjq3215m4YY1XB6E">https://bitcointalk.or=
g/index.php?topic=3D5408898.0</a>
& <a href=3D"https://github.com/bitcoin/bips/pull/134=
7" rel=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.g=
oogle.com/url?hl=3Dfr&q=3Dhttps://github.com/bitcoin/bips/pull/1347&=
;source=3Dgmail&ust=3D1715448391881000&usg=3DAOvVaw28hixKGvbTcScIlt=
jYERBS">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 an=
d 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" i=
s 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 impossi=
ble
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 p=
ushed
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&qu=
ot;
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a rel=3D"nofollow">bitcoindev+..=
.@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href=3D"https:/=
/groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-4ac1-834c-902ba4901e05n=
%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofo=
llow" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?=
hl=3Dfr&q=3Dhttps://groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-=
4ac1-834c-902ba4901e05n%2540googlegroups.com?utm_medium%3Demail%26utm_sourc=
e%3Dfooter&source=3Dgmail&ust=3D1715448391881000&usg=3DAOvVaw07=
4hFqa5_AFyK8HqRjfMK4">https://groups.google.com/d/msgid/bitcoindev/9004c5d4=
-6b9d-4ac1-834c-902ba4901e05n%40googlegroups.com</a>.<br>
</blockquote>
</div>
</blockquote>
<div>=C2=A0</div>
</div>
</div>
-- <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 data-email-masked rel=3D"nofollow">bitcoinde=
v+...@googlegroups.com</a>.<br></blockquote></div><div><blockquote type=3D"=
cite">
To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/d/msgid/bitcoindev/5fcc4168-b4fd-4efd-b11c-6bbf852871ccn%40googleg=
roups.com?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" rel=
=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&am=
p;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/5fcc4168-b4fd-4efd-b11c-=
6bbf852871ccn%2540googlegroups.com?utm_medium%3Demail%26utm_source%3Dfooter=
&source=3Dgmail&ust=3D1715448391881000&usg=3DAOvVaw0gdSp47pviCM=
fwqhcA0c4T">https://groups.google.com/d/msgid/bitcoindev/5fcc4168-b4fd-4efd=
-b11c-6bbf852871ccn%40googlegroups.com</a>.<br>
</blockquote>
</div>
</blockquote></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/050ed80d-f4a1-48de-8808-a8af7fac3cf1n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/050ed80d-f4a1-48de-8808-a8af7fac3cf1n%40googlegroups.com</a>.=
<br />
------=_Part_60487_1004776637.1715363230038--
------=_Part_60486_1824040206.1715363230038--
|