Date: Mon, 22 Aug 2022 07:56:12 +0000
To: bitcoin-dev@lists.linuxfoundation.org
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <20220822075606.6d2lsemmg7h26xqg@artanis>
Feedback-ID: 34210769:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] A method for BIP322 signing delegation
Precedence: list

This message relates to an edge case which BIP322 only partially solves, an=
d that is Proof of Payment.

When you make a transaction to any business, it keeps the transaction in it=
s records and generates an invoice so anyone can verify the transaction too=
k place.

When you do a P2P transaction, whether on the blockchain or with paper mone=
y, 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 transac=
tion. 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 messag=
e isn't even enough to prove the transction took place - they can just clai=
m (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 UTXO=
s that are being spent. So it can be independently established that Alice s=
ent 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 UT=
XO(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 cha=
llenge 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 signa=
tures are then published on the blockchain. The catch is that both of the s=
ignatures are requires to be supplied

We don't want the signatures to be hidden using Taproot script paths or any=
thing because whole point of this scheme is to make it verifiable to the pu=
blic.

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 "P=
2P payments")
- Alice sends bitcoin to the 2-of-2 multisig address generated by the P2P p=
ayment.
- Alice signs a BIP322 message from a UTXO (or address, but preferably a UT=
XO) 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, whi=
ch prove who has control of which inputs.
-- Consequentially, it can be proven who paid who. It is like an invoice, b=
ut 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 f=
orever.
-- So, it is in the buyer's best interest to cooperate, and also in the sel=
ler's interest, but not particularly the best one - Until Bob provides a se=
rvice, he doesn't lose anything except for time.

What do you guys think about this scheme?

- Ali