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
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
--
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.
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
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/5fcc4168-b4fd-4efd-b11c-6bbf852871ccn%40googlegroups.com.