* [bitcoindev] BIP 322 use case
@ 2024-05-03 23:53 ProfEduStream
2024-05-04 0:11 ` Luke Dashjr
0 siblings, 1 reply; 5+ messages in thread
From: ProfEduStream @ 2024-05-03 23:53 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2216 bytes --]
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+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/9004c5d4-6b9d-4ac1-834c-902ba4901e05n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 10743 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] BIP 322 use case
2024-05-03 23:53 [bitcoindev] BIP 322 use case ProfEduStream
@ 2024-05-04 0:11 ` Luke Dashjr
2024-05-05 12:09 ` Ali Sherief
0 siblings, 1 reply; 5+ messages in thread
From: Luke Dashjr @ 2024-05-04 0:11 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 4223 bytes --]
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+unsubscribe@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/e617f6eb-dd11-4ca2-aba6-f80ace8863a8%40dashjr.org.
[-- Attachment #2: Type: text/html, Size: 6036 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] BIP 322 use case
2024-05-04 0:11 ` Luke Dashjr
@ 2024-05-05 12:09 ` Ali Sherief
2024-05-05 14:50 ` Luke Dashjr
0 siblings, 1 reply; 5+ messages in thread
From: Ali Sherief @ 2024-05-05 12:09 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] BIP 322 use case
2024-05-05 12:09 ` Ali Sherief
@ 2024-05-05 14:50 ` Luke Dashjr
2024-05-10 17:47 ` Prof EduStream
0 siblings, 1 reply; 5+ messages in thread
From: Luke Dashjr @ 2024-05-05 14:50 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 8985 bytes --]
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).
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.
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).
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.
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.
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.
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
> 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
> <https://groups.google.com/d/msgid/bitcoindev/5fcc4168-b4fd-4efd-b11c-6bbf852871ccn%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/b7861fc2-d980-4c3a-a472-ea7aead01692%40dashjr.org.
[-- Attachment #2: Type: text/html, Size: 12714 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] BIP 322 use case
2024-05-05 14:50 ` Luke Dashjr
@ 2024-05-10 17:47 ` Prof EduStream
0 siblings, 0 replies; 5+ messages in thread
From: Prof EduStream @ 2024-05-10 17:47 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 10119 bytes --]
Hey,
@Luke: You said a few days ago that signing a message with a multi-sig
address doesn't have lots of use 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 cryptographically show that you own an address, which is
possible in Bitcoin.
I also don't understand why a multi-sig user — who uses a multi-sig wallet
to secure their bitcoins — couldn't be able to do the same things as a
single-sig user.
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-sig signing already exists, and multi-sig signing
would only extend this feature to a few people for their personal use; plus
some companies, which are already compliant.
*> "That being said, BIP322 as-is has already been adopted by at least some
wallets, despite its unfinished state"*
@Luke & @Ali: I have tried numerous wallets in the past few weeks, but
none of them seemed to have adopted BIP322. If you have any further
information (or GitHub implementation / repo), please feel free to send it
to me.
Thank you both for your answers,
@ProfEduStream
Le dimanche 5 mai 2024 à 16:54:28 UTC+2, Luke Dashjr a écrit :
> 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).
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> 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
> 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+...@googlegroups•com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/5fcc4168-b4fd-4efd-b11c-6bbf852871ccn%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/5fcc4168-b4fd-4efd-b11c-6bbf852871ccn%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/050ed80d-f4a1-48de-8808-a8af7fac3cf1n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 15037 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-05-11 16:28 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-03 23:53 [bitcoindev] BIP 322 use case ProfEduStream
2024-05-04 0:11 ` Luke Dashjr
2024-05-05 12:09 ` Ali Sherief
2024-05-05 14:50 ` Luke Dashjr
2024-05-10 17:47 ` Prof EduStream
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox