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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1YyLBC-00032p-DA
for bitcoin-development@lists.sourceforge.net;
Fri, 29 May 2015 14:22:34 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.42 as permitted sender)
client-ip=209.85.192.42; envelope-from=tier.nolan@gmail.com;
helo=mail-qg0-f42.google.com;
Received: from mail-qg0-f42.google.com ([209.85.192.42])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YyLBB-0001xT-Fg
for bitcoin-development@lists.sourceforge.net;
Fri, 29 May 2015 14:22:34 +0000
Received: by qgf2 with SMTP id 2so29727650qgf.3
for <bitcoin-development@lists.sourceforge.net>;
Fri, 29 May 2015 07:22:28 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.26.165 with SMTP id l37mr15886345qkh.88.1432909347833;
Fri, 29 May 2015 07:22:27 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Fri, 29 May 2015 07:22:27 -0700 (PDT)
In-Reply-To: <CAE-z3OXEGcUYYAsqqrVMQw=XA=5dt9u7XHDmuzhMJ8OkZ+k3yg@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
<CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
<CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com>
<CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com>
<CANEZrP2BaKwhpPgcUHWAHswOmUeFLgEk4ysrn4+73qNzWDJ=yQ@mail.gmail.com>
<CABsx9T3nCJ-w_v-yEbEE2Ytb+xC65mhYqhoAhoOHw9tkPpG0TA@mail.gmail.com>
<CANEZrP1qH+zucYsGrMgnfi99e61Edxaj+xm=u_xYXga1g0WzJQ@mail.gmail.com>
<CAE-z3OVmw+0doCe0hmYE6A1D61h0AUh4Mtnf5Fg1e4zQBkpraQ@mail.gmail.com>
<CANEZrP0psA7hcJdKdA-r01UEt7ig3O-9vjwBMqKSEq-csu0hPQ@mail.gmail.com>
<CABsx9T23r_y2R9OEgqb3AAZf47Hh8BUJncjxxmPp5v_9uKEiqQ@mail.gmail.com>
<CAE-z3OXEGcUYYAsqqrVMQw=XA=5dt9u7XHDmuzhMJ8OkZ+k3yg@mail.gmail.com>
Date: Fri, 29 May 2015 15:22:27 +0100
Message-ID: <CAE-z3OU8Vtmi_UK=nF1UNLsXCwd17mKDMS1qKudYB_kwDbOguA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1142dc1aac67250517393404
X-Spam-Score: 3.3 (+++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
2.7 MALFORMED_FREEMAIL Bad headers on message from free email service
-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YyLBB-0001xT-Fg
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
function
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2015 14:22:34 -0000
--001a1142dc1aac67250517393404
Content-Type: text/plain; charset=UTF-8
On Fri, May 29, 2015 at 3:09 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
>
>
> On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen <gavinandresen@gmail.com>
> wrote:
>
>> But if there is still no consensus among developers but the "bigger
>> blocks now" movement is successful, I'll ask for help getting big miners to
>> do the same, and use the soft-fork block version voting mechanism to
>> (hopefully) get a majority and then a super-majority willing to produce
>> bigger blocks. The purpose of that process is to prove to any doubters that
>> they'd better start supporting bigger blocks or they'll be left behind, and
>> to give them a chance to upgrade before that happens.
>>
>
> How do you define that the movement is successful?
>
Sorry again, I keep auto-sending from gmail when trying to delete.
In theory, using the "nuclear option", the block size can be increased via
soft fork.
Version 4 blocks would contain the hash of the a valid extended block in
the coinbase.
<block height> <32 byte extended hash>
To send coins to the auxiliary block, you send them to some template.
OP_P2SH_EXTENDED <scriptPubKey hash> OP_TRUE
This transaction can be spent by anyone (under the current rules). The
soft fork would lock the transaction output unless it transferred money
from the extended block.
To unlock the transaction output, you need to include the txid of
transaction(s) in the extended block and signature(s) in the scriptSig.
The transaction output can be spent in the extended block using P2SH
against the scriptPubKey hash.
This means that people can choose to move their money to the extended
block. It might have lower security than leaving it in the root chain.
The extended chain could use the updated script language too.
This is obviously more complex than just increasing the size though, but it
could be a fallback option if no consensus is reached. It has the
advantage of giving people a choice. They can move their money to the
extended chain or not, as they wish.
--001a1142dc1aac67250517393404
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 29, 2015 at 3:09 PM, Tier Nolan <span dir=3D"ltr"><<a href=3D"ma=
ilto:tier.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">On Fri,=
May 29, 2015 at 1:39 PM, Gavin Andresen <span dir=3D"ltr"><<a href=3D"m=
ailto:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
></div><div>But if there is still no consensus among developers but the &qu=
ot;bigger blocks now" movement is successful, I'll ask for help ge=
tting big miners to do the same, and use the soft-fork block version voting=
mechanism to (hopefully) get a majority and then a super-majority willing =
to produce bigger blocks. The purpose of that process is to prove to any do=
ubters that they'd better start supporting bigger blocks or they'll=
be left behind, and to give them a chance to upgrade before that happens.<=
/div></div></blockquote><div><br></div></span><div>How do you define that t=
he movement is successful?<br></div></div></div></div></blockquote><div><br=
></div><div>Sorry again, I keep auto-sending from gmail when trying to dele=
te.<br><br></div><div>In theory, using the "nuclear option", the =
block size can be increased via soft fork.<br></div><div><br></div><div></d=
iv><div>Version 4 blocks would contain the hash of the a valid extended blo=
ck in the coinbase.<br><br></div><div><block height> <32 byte exte=
nded hash><br></div><div><br></div><div>To send coins to the auxiliary b=
lock, you send them to some template.<br><br></div><div>OP_P2SH_EXTENDED &l=
t;scriptPubKey hash> OP_TRUE<br><br></div><div>This transaction can be s=
pent by anyone (under the current rules).=C2=A0 The soft fork would lock th=
e transaction output unless it transferred money from the extended block.<b=
r><br></div><div>To unlock the transaction output, you need to include the =
txid of transaction(s) in the extended block and signature(s) in the script=
Sig.<br><br></div><div>The transaction output can be spent in the extended =
block using P2SH against the scriptPubKey hash.<br></div><div><br></div><di=
v>This means that people can choose to move their money to the extended blo=
ck.=C2=A0 It might have lower security than leaving it in the root chain.<b=
r><br></div><div>The extended chain could use the updated script language t=
oo.<br><br></div><div>This is obviously more complex than just increasing t=
he size though, but it could be a fallback option if no consensus is reache=
d.=C2=A0 It has the advantage of giving people a choice.=C2=A0 They can mov=
e their money to the extended chain or not, as they wish.<br></div></div></=
div></div>
--001a1142dc1aac67250517393404--
|
