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 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
