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
|
Return-Path: <ali@notatether.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id E1284C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Sep 2022 22:31:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 1A377813C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Sep 2022 22:31:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1A377813C5
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=LHxXJ5d8
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level:
X-Spam-Status: No, score=0.599 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001,
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 w2wEYWxLAJ2h
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Sep 2022 22:31:53 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 83D5F813C1
Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17])
by smtp1.osuosl.org (Postfix) with ESMTPS id 83D5F813C1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Sep 2022 22:31:51 +0000 (UTC)
Date: Sun, 04 Sep 2022 22:31:38 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com;
s=protonmail; t=1662330708; x=1662589908;
bh=rFheFWpP3ueeBowyJhBEkUbVLnvl5II8UpvON3gae9w=;
h=Date:To:From:Reply-To:Subject:Message-ID:Feedback-ID:From:To:Cc:
Date:Subject:Reply-To:Feedback-ID:Message-ID;
b=LHxXJ5d8a6Zn8M4t4vJ9BhxQbyJDd7NpLXwacTD7dHzWaY+rZRgF90HiTbQlurLYF
QDp5+HD34rh4wWA4aOcLylDGXmUesssn9fffeKqzO+nTxLBA7SzANaTEdFwHBzzn99
FLqAI6OVZDrF1bVPkPBNnJXjFG+6RcD21tNPp+3zIK1RC6ZWtHTAVsd1SVPVZaMfbR
HpsjxMEofJo9q6oDhSMiE6fVgDgKkPGGsTVBHy/PYLU1gpe3SMQoqvFdKhmcjvqyF7
oSLf2OCTepu3BZ9sFwNfAHyyepp+zH6/AdwoCu3dFIbxGyruF7hxMiaHb6xLi1PeRx
D9kOD6RwCgjpA==
To: bitcoin-dev@lists.linuxfoundation.org
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <20220904223132.zpvhw6hcekaowlme@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: Sun, 04 Sep 2022 22:49:48 +0000
Subject: [bitcoin-dev] Multipayment Channels - A scalability solution for
Layer 1
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: Sun, 04 Sep 2022 22:31:56 -0000
Over the past few days I've figured out a novel way to batch transactions t=
ogether into blocks, thereby compacting the transaction size and increasing=
the transactions-per-second. This is all on layer 1, without any hardforks=
- only a single softfork is required to add MuSig1 support for individual =
invoice addresses.
The nucleus of the idea was born after a discussion with Greg Maxwell about=
a different BIP (Implementing multisig using Taproot, to be specific)[1]. =
He suggested to me that I should add MuSig1 signatures into the Taproot scr=
ipt paths.
After some thinking, I realized a use case for MuSig1 signatures as a kind =
of on-chain Lightning Network. Allow me to explain:
LN is very attractive to users because it keeps intermediate transaction st=
ates off-chain, and only broadcasts the final state. But without mitigation=
s in the protocol, it suffers from two disadvantages:
- You have to trust the other channel partner not to broadcast a previous s=
tate
- You also have to trust all the middlemen in intermediate channels not to =
do the above.
Most of us probably know that many mitigations have been created for this p=
roblem, e.g. penalty transactions. But what if it were possible to create a=
scheme where so-called technical fraud is not possible? That is what I'm g=
oing to demonstrate here.
My scheme makes use of MuSig1, OP_CHECKLOCKTIMEVERIFY (OP_CLTV) timelock ty=
pe, and negligible OP_RETURN data. It revolves around constructs I call "mu=
ltipayment channels", called so because they allow multiple people to pay i=
n one transaction - something that is already possible BTW, but with much l=
arger tx size (for large number of cosigners) than when using MuSig1. These=
have the advantage over LN channels that the intermediate state is also on=
the blockchain, but it's very compact.
A channel consists of a fixed amount of people N. These people open a chann=
el by creating a (optionally Taproot) address with the following script:
<blockheightofoutput+desiredwaitingblocks>* OP_CTLV OP_DROP <N-of-N MuSig1>=
OP_CHECKMUSIG**
Simultaneously, each of the N participants receives the N signatures and co=
nstructs the N-of-N MuSig. Each participant will use this MuSig to generate=
his own independent "commitment transaction" with the following properties=
:
- It has a single input, the MuSig output. It has an nSequence of desiredwa=
itingblocks. <This prevents the output from being spent immediately.>
- It has outputs corresponding to the addresses and balances of each of the=
participants in the agreed-upon distribution.
Disadvantage: Because the N-of-N signature is given to all participants, it=
might be leaked into the public and consequentially anybody can spend this=
transaction after the timelock, to commit the balance.*** On the other han=
d, removing the timelocks means that if one of the participants goes missin=
g, all funds are locked forever.****
A second output with a script OP_RETURN <32-byte connection ID> can be adde=
d to the transaction to enable L1 channel discovery.
Full nodes parsing the blockchain can maintain a list of connection IDs to =
connect to (but without a non-malleable refund transaction, nobody is going=
to use this). SPVs can simply export a list of them from Full Nodes.
A connection only lasts for one transaction. Spending the output to another=
MuSig of the above format will create a new connection if it spends to a s=
imilarly-constructed MuSig output with different signature. In all cases, t=
he current connection is destroyed.
*This introduces a variable grace period, in blocks, after which anybody ca=
n broadcast this transaction to commit the channel funds distribution to ea=
ch of the participants' addresses. blockheightofoutput is the block height =
of the musig output, and desiredwaitingblocks is the maximum number of bloc=
ks the connection can stay alive for.
**This implies that a hypothetical OP_CHECKMUSIG would take a single aggreg=
ated signature, a single aggregated public key, and an integer N that denot=
es how many public keys were combined together. I elected not to overload O=
P_CHECKSIG since MuSig and regular signatures are both valid for the same a=
ddress types. This part is a rought draft and requires lots of work on maki=
ng an OP_CHECKMUSIG opcode that satisfies the requirements of multipayment =
channels.
***This is quite a bad flaw of this scheme because it means that all the pa=
rticipants must be trustworthy - you can't use this in trustless environmen=
ts. I appreciate any ways on how to implement non-malleable refund transact=
ions with single (non-aggregated) signatures!
****Perhaps the best solution is to offer both alternatives: <N-of-N MuSig1=
> OP_CHECKMUSIG in a public scenario where none of the participants want to=
face the prospect of losing their money, and <blockheightofoutput+desiredw=
aitingblocks>* OP_CTLV OP_DROP <N-of-N MuSig1> OP_CHECKMUSIG with signature=
sharing in private scenarios.
This draft is very crude and parts have not been fully developed. Tips for =
fleshing it out is much appreciated. Not that there's anything wrong with L=
N for that matter, I'm just concerned about the security reprocussions of n=
ot broadcasting intermediate transactions, and its enabling of crime.
- Ali
[1]: https://bitcointalk.org/index.php?topic=3D5410553.0
|
