From: Ali Sherief <ali@notatether•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] A method for BIP322 signing delegation
Date: Mon, 22 Aug 2022 07:56:12 +0000 [thread overview]
Message-ID: <20220822075606.6d2lsemmg7h26xqg@artanis> (raw)
This message relates to an edge case which BIP322 only partially solves, and that is Proof of Payment.
When you make a transaction to any business, it keeps the transaction in its records and generates an invoice so anyone can verify the transaction took place.
When you do a P2P transaction, whether on the blockchain or with paper money, there is always the risk that the other party will be dishonest, act in their own interest to convince people that they did not receive the transaction. Nobody has been able to completely get rid of this.
But in cryptocurrencies, this type of dispute is rampant, because it's also a scam attempt, to extract more money from the buyer. Legacy signed message isn't even enough to prove the transction took place - they can just claim (falsely) the address in the transaction is not theirs.
It usually happens like this:
1. Alice wants to buy something from Bob and sends bitcoins.
2. Bob denies receiving payment.
3. Alice publishes the txid of the transaction.
4. Bob denies that the address in the transaction belongs to him.
BIP322 signed messages only go half-way there: They can prove that the UTXO(s) belong to the buyer, and any good block explorer will show you the UTXOs that are being spent. So it can be independently established that Alice sent money, but not *who* it was sent to. That is where BIP322 falls short - there is no mechanism that forces Bob to sign a BIP322 message from the UTXO(s) he has just received, before the transaction is complete.
---
What should be done about this situation?
I propose using P2WSH 2-of-2 multisig to solve this problem. The script challenge will consist of something like OP_SHA256 <sha256 hash> OP_EQUAL[1][2]
[1]I don't even know if there is a standalone SHA256 opcode.
[2]OP_CHECKMULTISIG and OP_CHECKSIG both take public keys from the stack in addition to signatures, but we have arbitrary byte arrays and their SHA256 hashes, not public keys and signatures. How can we make this work?
Now on the witness stack, is pushed the BIP322 signature. Both of the signatures are then published on the blockchain. The catch is that both of the signatures are requires to be supplied
We don't want the signatures to be hidden using Taproot script paths or anything because whole point of this scheme is to make it verifiable to the public.
But I think that this idea can seriously work out in practice:
- Alice starts a P2P payment with Bob (let's just call this whole scheme "P2P payments")
- Alice sends bitcoin to the 2-of-2 multisig address generated by the P2P payment.
- Alice signs a BIP322 message from a UTXO (or address, but preferably a UTXO) and provides one of the signatures.
- Bob is forced to sign another BIP322 message from his address if he wants his money, and provides another signature.
- One of them broadcasts the multisig transaction, and Bob gets his money.
Advantages:
- The signatures in the Multisig transaction are two BIP322 signatures, which prove who has control of which inputs.
-- Consequentially, it can be proven who paid who. It is like an invoice, but it cannot be doctored like company invoices and databases.
Disadvantages:
- If Bob chickens out at this point, the money in the P2P payment is lost forever.
-- So, it is in the buyer's best interest to cooperate, and also in the seller's interest, but not particularly the best one - Until Bob provides a service, he doesn't lose anything except for time.
What do you guys think about this scheme?
- Ali
next reply other threads:[~2022-08-22 7:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-22 7:56 Ali Sherief [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-08-19 6:23 Ali Sherief
2022-08-16 4:38 Ali Sherief
2022-08-14 4:25 Ali Sherief
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=20220822075606.6d2lsemmg7h26xqg@artanis \
--to=ali@notatether$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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