1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
Return-Path: <ali@notatether.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5B710C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Aug 2022 07:56:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 237BD81AEA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Aug 2022 07:56:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 237BD81AEA
Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key,
unprotected) header.d=notatether.com header.i=@notatether.com
header.a=rsa-sha256 header.s=protonmail header.b=RtXI/dYO
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id LHdPZqGNtWVu
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Aug 2022 07:56:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5BD2981A64
Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136])
by smtp1.osuosl.org (Postfix) with ESMTPS id 5BD2981A64
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Aug 2022 07:56:21 +0000 (UTC)
Date: Mon, 22 Aug 2022 07:56:12 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com;
s=protonmail; t=1661154979; x=1661414179;
bh=bQBHYUt9UZgy4ymWpBsntsmsKHRaQp4n8JAeJMGt2fI=;
h=Date:To:From:Reply-To:Subject:Message-ID:Feedback-ID:From:To:Cc:
Date:Subject:Reply-To:Feedback-ID:Message-ID;
b=RtXI/dYOxX6JXRaKEE6o6DN9fUkEChSmijviZBa+3fIvrvlAl7HypjcIgxbBkOp0K
yFCG3mFFCAbxSw0ZMwjeqH+lKEEfsppGj1Yi7xEcEgjNI+g2bCaZXuwEio1FENTTTL
zRlL29Jeh0LsujkuKc9KfnZLuHQkWdb99GgX3lr9zdaseEaLo2p4dGAoA8Ow4wg5nL
qc8gssVLmFO6FnqEmyBUACECcDyJXBIuu9SAKVfsIIRmKr3s/uHgk3uwZ3B+UbjLmP
kVEhFp3QSsuyW/2b70Y39afSZZpMxXf7gqrbMPDlJCgJwbTZyZpXkB0J7WG6ReCt2i
HQ3P39Cg/I9Jg==
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
X-Mailman-Approved-At: Mon, 22 Aug 2022 08:20:17 +0000
Subject: Re: [bitcoin-dev] A method for BIP322 signing delegation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Aug 2022 07:56:24 -0000
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
|
