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
150
151
152
153
154
155
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8760FC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 09:15:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 65EAC4037C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 09:15:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ncD0JjCxtOiB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 09:15:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo115.poczta.onet.pl (smtpo115.poczta.onet.pl
[213.180.149.168])
by smtp2.osuosl.org (Postfix) with ESMTPS id 16067400FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 09:15:47 +0000 (UTC)
Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4KsvSr39gBzlg8Gj
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 11:15:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1651569340; bh=y98AFewBT7v9lMkmFW0TJI4NgBSDCszo8Z8/BeUfvhw=;
h=From:To:Date:Subject:From;
b=PDuqoql2R3bSU6AREehSzfYExcu850MH+vSLhU4hz1hZ0vHvqOoW1FQuOBygqjsST
RrreWj6oN2zVyrtUKHJ+eE7q44UCvSBJQHp/qgI+itFj03rAnoak1NFMLGCY76Oxnu
Hw+czBp7nbdMgOZNhrMuYKQVOLhy8KNmktQuIi+c=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.224.171] by pmq5v.m5r2.onet via HTTP id ;
Tue, 03 May 2022 11:15:40 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Date: Tue, 03 May 2022 11:15:36 +0200
Message-Id: <160827995-4aa198ec768a1ec2f886b21056804946@pmq5v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.224.171;PL;1
X-Mailman-Approved-At: Tue, 03 May 2022 09:24:43 +0000
Subject: [bitcoin-dev] CoinPool should focus on different sighashes
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: Tue, 03 May 2022 09:15:49 -0000
It seems that the current consensus with Taproot is enough to implement Coi=
nPool. There are no needed changes if we want to form a basic version of th=
at protocol, so it probably should be done now (or at least started, even i=
n some signet or testnet3). Later, if some features like SIGHASH_ANYPREVOUT=
(or the same with ANYSCRIPT) would be added, then it could be improved, ju=
st in the same way, as Lightning Network is moving from P2WSH to P2TR.
To start with, we assume there are six participants that are going to form =
a CoinPool. They start their journey by moving all of their coins to a 6-of=
-6 multisig channel. Nothing is signed, first we focus on making transactio=
ns, then we will sign them backwards to make it trustless.
+------------------------------------------------+
| Alice 3.51 -> ABCDEF (6-of-6 multisig) 19.94 |
| Bob 0.90 |
| Charlie 6.81 |
| Daniel 7.29 |
| Elaine 0.84 |
| Frank 0.60 |
+------------------------------------------------+
That first transaction is simple, we could sign it later with SIGHASH_ALL. =
But it seems we can handle it better: what about SIGHASH_ANYONECANPAY? Then=
, all outputs (so just one) will be signed, but anyone could attach another=
inputs if needed. Also, the first person could use SIGHASH_SINGLE | SIGHAS=
H_ANYONECANPAY, but it is optional, and I assume we don't need any "group l=
eader" or "coordinator", so anyone will just use SIGHASH_ANYONECANPAY, they=
will only switch destination and amount, to form a channel in a P2P way. C=
hannel forming could work in a similar way as mempools in Bitcoin: all mess=
ages will fly, until there will be some agreement, and some group will coll=
ect all needed signatures. But for now, nothing is signed, so let's go to t=
he next transaction.
To close that channel, a group should still exist, and just detach some par=
ticipant. Closing the whole group is not an option, we want to encourage Co=
inPool formation, so we don't want to continuously open and close the whole=
channel. Let's assume that Alice wants to leave. That means, we should get=
a group of five participants and Alice, nothing more is needed:
+-----------------------------------------------------------------+
| ABCDEF (6-of-6 multisig) 19.94 -> BCDEF (5-of-5 multisig) 16.43 |
| Alice 3.50 |
+-----------------------------------------------------------------+
When we talk about sighashes, that case is quite interesting. The group of =
five participants could use SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, and just=
bind that to the first output. But Alice cannot use the same sighash, beca=
use then her funds could be stolen by miners. She can use SIGHASH_ANYONECAN=
PAY, then all outputs will be protected by her signature. However, combinin=
g two different sighashes is not going to work well with Schnorr signatures=
. For that reason, we need two of them. So, the TapScript branch for that A=
BCDEF multisig could be: "<pubkeyBCDEF> OP_CHECKSIGVERIFY <pubkeyAlice> OP_=
CHECKSIG".
Also, this case is even more interesting: Alice could also use SIGHASH_SING=
LE | SIGHASH_ANYONECANPAY in that ABCDEF multisig and spend by key, but the=
n she needs some on-chain output. It could be anything, even some output sh=
e received from dust attack. Then, she could use SIGHASH_ANYONECANPAY on th=
at dust output, just to protect her coins. The total transaction size will =
be roughly the same, but then she could hide the whole group under a single=
Schnorr signature.
The missing part here is of course SIGHASH_ANYPREVOUT, then less transactio=
ns are needed. But even without that, the basic protocol can be deployed he=
re and now, the only overhead will be transaction storage, because we need =
to sign every possible transaction for closing the channel. Also, it will b=
e larger in case where all participants are going to close the channel, the=
n each detachment will be processed in a separate transaction.
When it comes to handling costs, the cost of leaving the channel is paid by=
the detached person. That means, even if going through the least compresse=
d path is possible, it would be costly for all participants trying to do th=
at, so it should discourage them and encourage to play by the rules, and mo=
ve all coins through N-of-N multisig.
Also, when we talk about covenants, it is in fact some kind of covenant. By=
having different sighashes for different signatures, we can easily restric=
t outputs to any scripts we want (and every participant can just collect ot=
her signatures, and later decide, where to send its own coins, so it is pos=
sible to pay someone directly, instead of first moving coins to some person=
al address, so there is one less transaction; tldr: another payment can be =
done during closing the channel).
So, my conclusion is that changing sighashes is far easier and more powerfu=
l than my previous idea of "paying to signatures", so I will probably focus=
on that instead.
|
