Ali Sherief [ARCHIVE] on Nostr: 📅 Original date posted:2022-08-22 📝 Original message:This message relates to an ...
📅 Original date posted:2022-08-22
📝 Original message: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
📝 Original message: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