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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3FDF7E0F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 15:50:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f180.google.com (mail-io0-f180.google.com
[209.85.223.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C6BB914D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 15:50:57 +0000 (UTC)
Received: by mail-io0-f180.google.com with SMTP id 186so135645812iow.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 07:50:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=JzBgbTQQm1DLt+fEdiGtnKhXbm4Sqq+tKkHVZOWdpjs=;
b=IesuahCdPaKYhZezBZNb1Z5UHBfNqT8mEbW/2MfTL8eosDwujlQQ3exesaG4dwJdDN
Vn3eMqQFgayMLZJry26rEMW66BA4sPLeegePUl3LYUmrAL8n0YRtu1xupRwFEcSXTt2G
MiEOrRuaJnqPJTLyfh/S6VqDaMm4FBS6+cxTU7NwIXilHfg5XKFJPDqeAyZJy91PPOdU
7dE1bPxx4PoBMqsoikZQqFKTspCw4MlF7u0IXU/Z1lFnqn8PlDQQNvBS1FE38f0yfD4b
hpbf08MntNlJWUKLFYbAn8Ra6/uIfsKFAIiUmDewwZ/+brietixLmeg8v7KsUJTLOqtr
9mug==
MIME-Version: 1.0
X-Received: by 10.107.131.207 with SMTP id n76mr14085152ioi.135.1450626657250;
Sun, 20 Dec 2015 07:50:57 -0800 (PST)
Received: by 10.79.77.75 with HTTP; Sun, 20 Dec 2015 07:50:57 -0800 (PST)
In-Reply-To: <1bf64a5b514d57ca37744ae5f5238149@openmailbox.org>
References: <1bf64a5b514d57ca37744ae5f5238149@openmailbox.org>
Date: Sun, 20 Dec 2015 15:50:57 +0000
Message-ID: <CAE-z3OXxX9Xki=oco4veasE796z__x17C-KLc0jsMW8GxSrZ_Q@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113ebda69b72ac052756560e
X-Spam-Status: No, score=-1.7 required=5.0 tests=AC_DIV_BONANZA,BAYES_00,
DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,
MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Increasing the blocksize as a (generalized)
softfork.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 20 Dec 2015 15:50:58 -0000
--001a113ebda69b72ac052756560e
Content-Type: text/plain; charset=UTF-8
This is essentially the "nuclear option". You are destroying the current
chain (converting it to a chain of coinbases) and using the same POW to
start the new chain. You are also giving everyone credit in the new chain
equal to their credit in the old chain.
It would be better if the current chain wasn't destroyed.
This could be achieved by adding the hash of an extended block into the
coinbase but not requiring the coinbase to be the only transaction.
The new block is the legacy block plus the associated extended block.
Users would be allowed to move money to the extended block by spending it
to a specific output template.
<public key hash> OP_1 OP_TO_EXTENDED OP_TRUE
OP_1 is the extended block index and initially, only one level is available.
This would work like P2SH. Users could spend the money on the extended
block chain exactly as they could on the main chain.
Money can be brought back the same way.
<public key hash> <txid1> <txid2> ... <txid-n> <N> OP_0 OP_UNLOCK OP_TRUE
The txids are for transactions that have been locked in root chain. The
transaction is only valid if they are all fully funded. The fee for the
transaction would be fee - (cost to fund unlocked txids). A negative fee
tx would be invalid.
This has the advantage that it keeps the main chain operating. People can
still send money with their un-upgraded clients. There is also an
incentive to move funds to the extended block(s). The new extended blocks
are more complex, but potentially have lower fees. Nobody is forced to
change. If the large blocks aren't needed, nobody will both to use them.
The rule could be
Now:
0) 1 MB
After change over
0) 1 MB
1) 2 MB
After 2 years
0) 1 MB
1) 2 MB
2) 4MB
After 4 years
0) 1 MB
1) 2 MB
2) 4MB
3) 8MB
--001a113ebda69b72ac052756560e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div>This is =
essentially the "nuclear option".=C2=A0 You are destroying the cu=
rrent chain (converting it to a chain of coinbases) and using the same POW =
to start the new chain.=C2=A0 You are also giving everyone credit in the ne=
w chain equal to their credit in the old chain.<br><br></div>It would be be=
tter if the current chain wasn't destroyed.<br><br></div>This could be =
achieved by adding the hash of an extended block into the coinbase but not =
requiring the coinbase to be the only transaction.=C2=A0 <br><br>The new bl=
ock is the legacy block plus the associated extended block.<br><br></div>Us=
ers would be allowed to move money to the extended block by spending it to =
a specific output template.=C2=A0 <br><br></div><public key hash> OP_=
1 OP_TO_EXTENDED OP_TRUE<br><br></div><div>OP_1 is the extended block index=
and initially, only one level is available.<br></div><div><br></div>This w=
ould work like P2SH.=C2=A0 Users could spend the money on the extended bloc=
k chain exactly as they could on the main chain.<br><br></div>Money can be =
brought back the same way.=C2=A0=C2=A0 <br><br></div><public key hash>=
; <txid1> <txid2> ... <txid-n> <N> OP_0 OP_UNLOCK O=
P_TRUE<br><br></div>The txids are for transactions that have been locked in=
root chain.=C2=A0 The transaction is only valid if they are all fully fund=
ed.=C2=A0 The fee for the transaction would be fee - (cost to fund unlocked=
txids).=C2=A0 A negative fee tx would be invalid.<br><br></div><div>This h=
as the advantage that it keeps the main chain operating.=C2=A0 People can s=
till send money with their un-upgraded clients.=C2=A0 There is also an ince=
ntive to move funds to the extended block(s).=C2=A0 The new extended blocks=
are more complex, but potentially have lower fees.=C2=A0 Nobody is forced =
to change.=C2=A0 If the large blocks aren't needed, nobody will both to=
use them.<br><br></div><div>The rule could be<br><br></div><div>Now: <br><=
/div><div>0) 1 MB<br><br></div><div>After change over<br></div><div>0) 1 MB=
<br></div><div>1) 2 MB<br><br></div><div>After 2 years<br></div><div>0) 1 M=
B<br></div><div>1) 2 MB<br></div><div>2) 4MB<br><br></div><div>After 4 year=
s<br><div>0) 1 MB<br></div><div>1) 2 MB<br></div>2) 4MB<br></div><div>3) 8M=
B<br><br></div><div><br></div></div></div>
--001a113ebda69b72ac052756560e--
|
