From: Ali Sherief <ali@notatether•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] BIP 322 use case
Date: Sun, 5 May 2024 05:09:46 -0700 (PDT) [thread overview]
Message-ID: <5fcc4168-b4fd-4efd-b11c-6bbf852871ccn@googlegroups.com> (raw)
In-Reply-To: <e617f6eb-dd11-4ca2-aba6-f80ace8863a8@dashjr.org>
[-- Attachment #1.1: Type: text/plain, Size: 5779 bytes --]
> 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).
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.
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.
> 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
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 get the UTXO set and another to create an unsigned template
transaction for the message.
-Ali
On Saturday, May 4, 2024 at 12:14:53 AM UTC Luke Dashjr wrote:
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)
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. :/
Luke
On 5/3/24 19:53, ProfEduStream wrote:
Hey,
As a Bitcoin association, we're currently facing an issue because we're
unable to sign an address with our multi-sig wallet.
After conducting some research, I came across BIP322 in these threads:
https://bitcointalk.org/index.php?topic=5408898.0 &
https://github.com/bitcoin/bips/pull/1347
*Explanation*:
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.
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.
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.
*Conclusion*:
I'm unsure why BIP322 hasn't been pushed or addressed in the past few
months/years, but I want to highlight its necessity.
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.
I'm available to assist if needed.
@ProfEduStream
--
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
email to bitcoindev+...@googlegroups•com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-4ac1-834c-902ba4901e05n%40googlegroups.com
<https://groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-4ac1-834c-902ba4901e05n%40googlegroups.com?utm_medium=email&utm_source=footer>
.
--
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 email 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.
[-- Attachment #1.2: Type: text/html, Size: 7580 bytes --]
next prev parent reply other threads:[~2024-05-05 13:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 23:53 ProfEduStream
2024-05-04 0:11 ` Luke Dashjr
2024-05-05 12:09 ` Ali Sherief [this message]
2024-05-05 14:50 ` Luke Dashjr
2024-05-10 17:47 ` Prof EduStream
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5fcc4168-b4fd-4efd-b11c-6bbf852871ccn@googlegroups.com \
--to=ali@notatether$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox