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
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 92BA6A0AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 1 Feb 2019 09:19:10 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6D9B9775
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 1 Feb 2019 09:19:09 +0000 (UTC)
Date: Fri, 01 Feb 2019 09:19:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1549012746;
bh=dVau10tlF03P9iY+pastbL/VtJ1R7myfyXVQeWAGSyc=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=bAUREtOZuqOvGt50pbZBIdqLc6leUOsz65/1rjrFwuJ/y/DFBXPfUODEEAEEtFSNF
1hq7M9AuseToF/ConhBloOrZT97dEomoY/GPvfcSh5Qz57ssQ0jpBIVIYwOtEAmkRo
NTfnrQ7WzLXTPNBkNLfcxu8MFQtUY925CfHN8OXA=
To: Matt Bell <mappum@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <VwCJ55YVFwMwQk83TlSxhluf6q5-m3Ad6AquADm1psVXzXRWdaMoGERtU4AFF-QGqWYJ1POLur484QzH1jGExc8qjkfWZiTb0sc_u10Vd88=@protonmail.com>
In-Reply-To: <CACV3+OU1ynRuR2SioW+O+CAp5M7ZQA6af_hEY5JZCVrXpqjtKQ@mail.gmail.com>
References: <CACV3+OU1ynRuR2SioW+O+CAp5M7ZQA6af_hEY5JZCVrXpqjtKQ@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 01 Feb 2019 14:56:03 +0000
Subject: Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Fri, 01 Feb 2019 09:19:10 -0000
Good morning Matt Bell,
Thinking of this further, I observe that there are limits on the number of =
operations in a SCRIPT (I believe 201 non-push operations, and maybe a smal=
ler number of CHECKSIG operations?).
This implies that the number of signatories of the sidechain funds in the m=
ainchain are limited.
This is an important care point.
I am uncertain what is the best way to solve this issue.
---
In any case, I now present a design for a proof-of-mainstake sidechain, now=
without any modifications to Bitcoin mainchain.
---
I observe that a blockchain is, stripped to its barest minimum, nothing mor=
e than a Merklized singly-linked list.
Each block header is a node in a singly-linked list.
It commits to the previous block header, and also commits to the block data=
(traditionally a Merkle binary tree).
Via such block headers, a chain of blocks --- a blockchain --- is formed.
---
I observe that a (non-coinbase) transaction in Bitcoin refers to at least o=
ne existing transaction output.
A representation of that transaction output must be committed to in the tra=
nsaction.
If we create single-input single-output transactions, a chain of transactio=
ns is formed.
---
Thus the idea: the sidechain *is* the transaction chain.
I observe that the mainchain *must* contain some UTXO(s) that are purported=
ly controlled by the sidechain rules.
It is also possible that the sidechain funds be a single UTXO, with deposit=
s and withdrawals requiring that the single UTXO be spent, in order to main=
tain the invariant that the sidechains funds are handled completely in a si=
ngle UTXO.
In addition, it is possible for a transaction to commit to some data arbitr=
arily, either via `OP_RETURN`, or via some technique such as pay-to-contrac=
t (which reduces space utilization on the mainchain compared to `OP_RETURN`=
).
When we use the above technique (i.e. the sidechain only "owns" a single ma=
inchain UTXO at each block of the mainchain):
1. Each transaction commits to the previous transaction (via spending the =
output of the previous transaction).
2. Each transaction may commit to some other data (via `OP_RETURN` or othe=
r technique).
I observe also that under a blockchain:
1. Each block header commits to the previous block header.
2. Each block header commits to the block data.
From this, the analogy is simple and obvious.
The sidechain "blockchain" *is* the transaction chain.
---
Under certain forms of proof-of-stake, the block must be signed by some set=
of signatories of the stakers.
Under transaction rules, the transaction must be signed according to the SC=
RIPT, and the SCRIPT may indicate that some set of signatories must sign.
Thus, it becomes possible to simply embed the sidechain block headers on th=
e mainchain directly, by spending the previous transaction (=3D=3D sidechai=
n block header).
This spend requires that the transaction be signed in order to authorize th=
e spend.
However, these same signatures are in fact also the signatures that, under =
proof-of-stake, prove that a sufficient signatory set of the stakers has au=
thorized a particular block of the proof-of-stake blockchain.
The magic here is that, on the mainchain, a transaction may only be spent o=
nce.
Thus, nothing-at-stake and stake-grinding problems disappear.
---
Now let us introduce some details.
We have two mainchain-to-sidechain requests:
1. An indication that a mainchain coin owner wants to stake coins to the s=
idechain.
2. An indication that a mainchain coin owner wants to transfer coins to th=
e sidechain.
From within the sidechain, sidechain-to-mainchain withdrawals must somehow =
be signalled, but that is up to the sidechain to define.
We shall ignore it here.
When a sidechain receives a request to add stake, then the current stakers =
create a mainchain transaction, spending the sidechain UTXO, plus the stak=
ed coins, and outputting the next sidechain UTXO (with the signatory set mo=
dified appropriately), plus a stake UTXO that locks the coins.
When a sidechain receives a request to transfer coins from mainchain to sid=
echain, then the current stakers create a mainchain transaction, spending t=
he sidechain UTXO, plus the transferred coins, and outputting the next side=
chain UTXO (with the same signatory set).
Multiple such requests can be processed for each transaction (i.e. sidechai=
n block).
This simply consumes the sidechain UTXO, any stake or transfer coins, and c=
reates the next sidechain UTXO and any stake UTXOs.
Now, the indication to stake is a UTXO with a special script.
It has two branches:
1. A signature from the current signatory set.
2. Or, 2 OP_CSV and the staker signature.
The intent of the latter branch is to ensure that, if the current signatori=
es ignore the incoming staker, the incoming staker can still recover its fu=
nds.
If the current set of stakers accepts the incoming staker (which requires b=
oth that they change the signatory set, and put the money being staked into=
a stake UTXO which is simply a long CSV and the staker signature), then th=
e first branch is performed and the coin is an input of the sidechain block=
header (=3D=3D sidechain managing transaction).
A similar technique is used for mainchain-to-sidechain transfers.
If the mainchain-to-sidechain transfer is ignored (either deliberately, or =
by an accident of disrupted communication from the mainchain trasnferrer to=
the sidechain network), the mainchain transferrer can recover its money an=
d try again.
---
Ideally, every mainchain block would have a sidechain managing transaction =
(=3D=3D sidechain block header).
Of course, we must consider fees.
Obviously the sidechain itself must charge fees within the sidechain.
Some fraction of those fees will be spent in order for the sidechain managi=
ng transaction to be confirmed on the mainchain.
Now it may happen that the sidechain managing transaction is not confirmed =
immediately on the mainchain.
The sidechain stakers (the signatory set) may elect to sacrifice even more =
of their fees to increase the fees of the sidechain managing transaction vi=
a RBF.
---
Now perhaps the sidechain may wish to have a faster (or more regular) block=
rate than the mainchain.
In such a case, it may maintain a "real" blockchain (i.e. headers that comm=
it to a single previous header, and commits the block data).
Then each sidechain managing transaction would commit to the latest sidecha=
in block header agreed upon by the stakers.
These sidechain blocks need not be signed; they only become "real" if they =
are committed to, directly or indirectly, in a sidechain managing transacti=
on.
At each sidechain block, the signatory set (the stakers) create a sidechain=
managing transaction.
If it is immediately put into a mainchain block, then the next sidechain ma=
naging transaction spends it.
Otherwise, if it is not put into a mainchain block, then the stakers just r=
ecreate the sidechain managing transaction with RBF.
Regards,
ZmnSCPxj
|
