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
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3EE5DC07FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Nov 2020 01:32:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 2D7F386004
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Nov 2020 01:32:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id gqk6gBE9Rqkl
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Nov 2020 01:32:18 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch
[185.70.40.140])
by fraxinus.osuosl.org (Postfix) with ESMTPS id E949E85FFC
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Nov 2020 01:32:17 +0000 (UTC)
Date: Mon, 16 Nov 2020 01:32:11 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1605490334;
bh=w3RXJdKAMZB3NFXI51VI3JeocWKb8dQ1kGRmIgKgwnI=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=fQN1Y7075SiscL0l32hxt20PNDhSgNYmgZi9ds++7t9nlTxDerh8WE4WccpHnL7vO
jg0LJvNWjAOuVcL4gLWpQ3UtE+j4NtiOJjCbu9O4KnSI6AKuUJUIIe90YDkhOjNL8D
oJ6tTtQ8AKJ218aNgab7zFVltCcUI/+z/bELUhaI=
To: Sridhar G <sridhar87@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <1XMBkdX-KiAjYBAfntpqYxiBPaiJ-S-n11NNwroEMLBp6G7jV1EPAhF0aFaz_pz-PZ-7gxcMfCwg04ofcMqKzYe5rz826mHSJ2eZXsBxXYw=@protonmail.com>
In-Reply-To: <CAF8yEM_gur=r2WvQ=y3bE53cfds=gQT3se-GAspHvMQzUnW-9Q@mail.gmail.com>
References: <CAF8yEM_gur=r2WvQ=y3bE53cfds=gQT3se-GAspHvMQzUnW-9Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] CoinPools based on m-of-n Schnorr aggregated
signatures
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, 16 Nov 2020 01:32:20 -0000
Good morning Sridhar,
My understanding is that it is still possible to generate an m-of-n aggrega=
ted pubkey, it "just" requires an interactive setup (i.e. all n signers hav=
e to talk to each other and send data a few times to each other) and they h=
ave to keep extra data around in order to "sign for" the n - m missing sign=
ers.
`andytoshi` and `pwuille` can probably teach you the details.
Of course, if you want to trade off the interactive setup + data storage, f=
or extra block space and a privacy loss, that seems a reasonable tradeoff t=
o make.
My understanding is that current plan is to implement a `OP_CHECKSIGADD`, w=
here your script would be:
<0> <pubkey1> OP_CHECKSIGADD <pubkey2> OP_CHECKSIGADD <pubkey3> OP_CHECK=
SIGADD <m> OP_EQUAL
However, `OP_CHECKSIGADD` would have individual signatures from the m parti=
cipating signers.
Your `OP_POOL`, as I understand it, would instead have a single m-of-m sign=
ature.
This adds another tradeoff:
* `OP_CHECKSIGADD` takes up more block space, but each signer can give thei=
r signature independently without having to enter a signing sessiong with o=
ther participating signers.
* For example, this can reduce the number of communication rounds and the=
latency.
* A participating signer can emit its own signature and then go offline a=
nd you can still use its signature when you have gotten the required m part=
icipants.
* `OP_POOL` takes less block space, but all participating signers have to b=
e online simultaneously.
I think the fact that `OP_POOL` requires all participating signers to be on=
line simultaneously to generate a single signature sort of defeats the purp=
ose, as (by my naive understanding, which could be grossly wrong) in the m-=
of-n key setup, the extra data needed would be stored by all participants, =
so even if one participant loses this data any of the others can still prov=
ide it.
Interactive setup may not be so onerous if you are doing multiple interacti=
ve signing sessions later anyway.
So doing a verifiable secret sharing at interactive setup, to generate a si=
ngle pubkey that is just used directly as the pubkey of the UTXO, would end=
up being smaller and more private anyway, and would "just" require interac=
tive setup + storage of extra data.
I guess the question is: just how big is the extra data in the m-of-n verif=
iable secret sharing?
Regards,
ZmnSCPxj
> Hi everyone,
>
> N-of-n multisig transaction using Schnorr aggregate signature is trivial =
and is similar to the current P2PKH. I would like to propose a model for m-=
of-n multisig transactions using Schnorr aggregate signatures and use this =
to enable CoinPools for off-chain scalability.
>
> 1. Creating the pool
>
> A transaction is made on the bitcoin network with an output having the fo=
llowing script:
>
> <pub_key_1> <pub_key_2> <pub_key_3> .. <pub_key_N> N M OP_POOL
>
> Bitcoin network will create a =E2=80=98pool=E2=80=99 with all the =
=E2=80=98N=E2=80=99 public keys and note down the threshold M for this pool=
. This UTXO would be referred as <POOL_ID>
>
> 2. Depositing money to pool
>
> Deposits can be made to a pool with <POOL_ID> with the following script
>
> <POOL_ID> OP_LOAD_POOL_AGG_PUB_KEY OP_CHECKSIG
>
> 3. Redeeming money from pool
>
> Redeem script would contain the aggregated signature from all signers and=
the bitmap of signers.
>
> <AGG_SIG> <SIGNERS_BITMAP> <POOL_ID>=C2=A0 OP_LOAD_POOL_AGG_PUB_KEY OP_CH=
ECKSIG
>
> With <AGG_SIG> <SIGNERS_BITMAP> provided by the person that redeems money=
from a pool, where
>
> <AGG_SIG> - is the aggregated signature
>
> <SIGNERS_BITMAP> - Is a bitmap representing whether the member of the poo=
l at position 'i' of bitmap has signed or not(1 =3D signed, 0 - has not sig=
ned)
>
> So we will be introducing two new opcodes:
>
> 1. OP_POOL - this will be used to create a new coin pool.
>
> 2. OP_LOAD_POOL_AGG_PUB_KEY - This opcode does three things
>
>
> 1. loads the pool (POOL_ID)
>
> 2. checks if there are atleast 'm' signers (based on SIGNERS_BITMAP)
>
> 3. aggregates the public key of the signers. (based on SIGNERS_BITMAP)
>
>
> The opcode uses the top two elements from the stack- the first element fr=
om the stack specifies the POOL_ID to load, which will load the public keys=
from the pool. This opcode also checks if there are =E2=80=98M=E2=80=99 si=
gners(as specified at the time of creation of the pool) and aggregates the =
public keys that have signed based on SIGNERS_BITMAP using Schnorr aggregat=
e signature scheme and puts back this aggregated public key onto the stack.
>
> SIGNERS_BITMAP is a 32 byte value, and represents a bitmap of which publi=
c keys from the pool have signed the transaction.
>
> Having this scheme would enable-
>
> 1. Scalability of m-of-n multisig transactions - People can deposit mone=
y to a pool(with 32 byte SIGNERS_BITMAP, we can allow for 256 possible sign=
ers).
>
> 2. Trust minimized off-chain scalability solutions due to the use of a s=
ufficiently large pool of signers. Most existing pools might allow for only=
a few signers as having many signers would mean higher transaction cost.
>
>
> Downsides:
>
> 1. We need to have the public keys of the members of the pool exposed.
>
>
> Despite the downsides of exposing public keys, do you think this would be=
a viable scheme for enabling CoinPool for the Bitcoin network? Or, any sch=
eme that may expose public keys is a no-go in the Bitcoin network?
>
> Thanks! Looking for your feedback and thoughts on this.
>
> -Sridhar
|
