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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EE1C7B2A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Jan 2017 09:39:56 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender163-mail.zoho.com (sender163-mail.zoho.com
[74.201.84.163])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5251D12D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Jan 2017 09:39:56 +0000 (UTC)
Received: from [10.7.56.158] (ip-123-255-103-183.wlan.cuhk.edu.hk
[123.255.103.183]) by mx.zohomail.com
with SMTPS id 1485423589315837.0731533661734;
Thu, 26 Jan 2017 01:39:49 -0800 (PST)
From: Johnson Lau <jl2012@xbt.hk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Message-Id: <5B69C153-4623-4664-9C4B-4E0396FF021A@xbt.hk>
Date: Thu, 26 Jan 2017 17:39:43 +0800
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3259)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Extension block softfork proposal
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: Thu, 26 Jan 2017 09:39:57 -0000
This is a pre-BIP which allows extra block space through a soft-fork. It =
is completely transparent to existing wallets (both send and receive), =
but new wallets taking advantage of the extra block space will have a =
very different user experience.
I=E2=80=99m sure this is controversial but I think it=E2=80=99s an =
interesting academic topic. If we=E2=80=99d ever have any fully =
consensus enforced 2-way-peg side chain design, that=E2=80=99d be =
something like this.
Objectives:
1. Provide more block space through a soft forks
2. Completely transparent to existing wallets
3. Not breaking any current security assumptions
Specification and Terminology:
Main block / block: the current bitcoin block (with witness if BIP141 is =
activated)
Main transaction / tx: txs in the current bitcoin network (with witness)
Main UTXO / UTXO: the normal UTXO
Extension transaction / xtx: transactions with a format same as the =
witness tx format described in BIP141, without scriptSig field, and the =
=E2=80=9Cflag=E2=80=9D as 0x02. Only witness program are allowed for =
scriptPubKey of xtx
Extension block / xblock: xblock is a collection of xtx. Each block may =
have 0 or 1 xblock when this softfork is activated.
Extension UTXO / xUTXO: the UTXO set for of the extension block.
Bridging witness program: A new type of witness program is defined. The =
witness script version is OP_2. The program length could be 4 to 40. The =
first byte ("direction flag=E2=80=9D[note 1]) must be 0x00 (indicating =
block->xblock) or 0x01 (indicating xblock->block). Like P2WPKH and =
P2WSH, the bridging program could be wrapped by P2SH. There are 2 ways =
to spend this program type on the main block:
1) Spend it like a usual witness program with a tx. For example, if =
the bridging program is OP_2 <0x000014{20 bytes}>, it could be spent =
like a version-0 20bytes programme, i.e. P2WPKH. Nothing special would =
happen in this case
2) Spend it like a usual witness program with a special xtx, the =
genesis xtx. In this case, the miner including this xtx will need to do =
more as described below.
Integrating UTXO: a special UTXO with a value >=3D the total value of =
all existing xUTXO and scriptPubKey is OP_1. (to make the spec easier to =
read, here we assume that now we have a zero value UTXO with its =
outpoint hardcoded as the initial integrating UTXO. In practice we may =
have the first miner making xblock to create the initial integrating =
UTXO)
Integrating transaction: if a block has an xblock, the second =
transaction in the block must be the integrating transaction. The inputs =
include the spent UTXO of all the genesis xtx in this xblock. If it is a =
bare witness program, the witness must be empty. If it is a P2SH witness =
program, the scriptSig must be the bridging witness program and the =
witness must be empty. The last input must be the original integrating =
UTXO, with empty witness and scriptSig. If no one is trying to send =
money back from the xblock to the main block, the only output is the =
updated integrating UTXO, which the value must be >=3D the total value =
of all xUTXO
=E2=80=94=E2=80=94=E2=80=94=E2=80=94
Up to now, I have described how we could send bitcoins from the main =
UTXO to the xUTXO. Simply speaking, people send money to a new form of =
witness programme. They have the flexibility to spend it in the main =
block or xblock. Nothing special would happen if they send to the main =
block. If they send to the xblock, the value of such UTXO will be =
collected by the integrating UTXO.
After people sent money to xblock, they could trade inside the xblock =
just like in the main block. Since xblock is invisible to the =
pre-softfork users, we could have whatever size limit for the xblock, =
which is not a topic of this proposal.
The tricky part is sending from xblock to main block.
Returning transaction: returning transaction is a special xtx, sending =
money to a bridging witness program, with a direction flag of 0x01. =
These bridging witness program won=E2=80=99t be recorded in the xUTXO =
set. Instead, an output is added to the integrating tx, with the =
bridging witness program and corresponding value, called the =
=E2=80=9Creturning UTXO=E2=80=9D. The returning UTXOs are not spendable =
until confirmed by 100 blocks. The updated integrating UTXO is the last =
output, and is not restricted by the 100-block requirement
Fees collection in xblock: Same as normal tx, people pay fee in xblock =
by making output value < input value. Since the value of the integrating =
UTXO is >=3D the total value of all existing xUTXO, if fees are paid in =
the xblock, that will reduce the value of the integrating UTXO, and =
miners are paid through the usual coinbase tx as fee.
xblock commitment: 2 xblock merkle root, with and without witness, are =
placed exactly after the witness commitment in the coinbase tx.(maybe we =
could use the coinbase reserved witness value, details TBD). If there is =
no xblock commitment, xblock must be empty and integrating tx is not =
allowed.
=E2=80=94=E2=80=94=E2=80=94=E2=80=94
Same as any 2-way-peg proposal, sending money from the side chain to the =
main chain is always the most tricky part. Different from other side =
chain proposals like Rootstock, extension block is fully consensus =
enforced, and has the same security level as existing bitcoin =
transactions. To ensure this, an 100-block maturity is needed for the =
returning UTXO, as the TXID of the integrating transaction is *very* =
likely to change after a reorg, which will break the transaction chains =
coming from it. The 100-block maturity requirement bring us back to the =
usual assumption that txs become permanent after 100 confirmations.
Please note that this drastically changes the user experience, as no =
current users (expect miners) would expect such 100-block freezing. =
That=E2=80=99s why I don=E2=80=99t allow the returning UTXO to have an =
arbitrary scriptPubKey, as users of current wallet would never expect =
such freezing. Using a special output scriptPubKey guarantees that the =
recipient must understand the implications. Users of the new wallet =
should be warned that despite they may enjoy lower fees in the xblock, =
it may be difficult for them to send money to legacy wallets. This is a =
huge limitation.
Maybe we could have some decentralised market (using simple =
hash-time-locked txs) allowing people to exchange value between block =
and xblock, bypassing the 100 block requirement. This is actually =
cheaper, because a full returning is a 2-step process, while p2p =
exchange is only 1-step.
=E2=80=94=E2=80=94=E2=80=94=E2=80=94
Questions:
1. Is it possible to simplify the design, without compromising security?
2. Is it acceptable to do it without the 100-block maturity requirement, =
thus breaking some long-held assumptions? (This would vastly improve the =
usability, until a reorg happens)
3. Even with maturity requirement, is 100-block an overkill? We never =
had a fork over maybe 20 blocks. Also, breaking of transaction chain due =
to reorg is already possible, as people may double spend during a reorg.
[note 1] the direction flag is needed to make sure a recipient won=E2=80=99=
t be paid with a returning transaction, unless explicitly requested. It =
might be combined with the serialised witness version to save one byte.=
|
