Delivery-date: Sun, 05 May 2024 06:31:00 -0700
Sender: bitcoindev@googlegroups.com
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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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>&gt;=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>&gt;=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>
        &amp; <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&amp;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&quot; 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--