diff options
| author | Prof EduStream <profedustream@gmail.com> | 2024-05-10 10:47:10 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2024-05-11 09:28:00 -0700 |
| commit | 79d6b21926c67edec958d68f9703c7f7a8027a44 (patch) | |
| tree | c4c4b272dae2c54c50f0688070d4c944283313fe | |
| parent | 012b305a8cfeff2570f81b450971403a3ed88ded (diff) | |
| download | pi-bitcoindev-79d6b21926c67edec958d68f9703c7f7a8027a44.tar.gz pi-bitcoindev-79d6b21926c67edec958d68f9703c7f7a8027a44.zip | |
Re: [bitcoindev] BIP 322 use case
| -rw-r--r-- | 12/007457b1f9b8f6a1f2cab205436d46bf9f4435 | 663 |
1 files changed, 663 insertions, 0 deletions
diff --git a/12/007457b1f9b8f6a1f2cab205436d46bf9f4435 b/12/007457b1f9b8f6a1f2cab205436d46bf9f4435 new file mode 100644 index 000000000..5f390c0f7 --- /dev/null +++ b/12/007457b1f9b8f6a1f2cab205436d46bf9f4435 @@ -0,0 +1,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-- + |