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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2EF2AC63
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Feb 2016 21:54:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7CC71167
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Feb 2016 21:54:04 +0000 (UTC)
Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6])
by mail.bluematt.me (Postfix) with ESMTPSA id 127C55CDA0;
Tue, 9 Feb 2016 21:54:02 +0000 (UTC)
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
References: <56B8EBF8.4050602@mattcorallo.com>
<20160209090002.GB18324@sapphire.erisian.com.au>
From: Matt Corallo <lf-lists@mattcorallo.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56BA5FF9.6090905@mattcorallo.com>
Date: Tue, 9 Feb 2016 21:54:01 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20160209090002.GB18324@sapphire.erisian.com.au>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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: Tue, 09 Feb 2016 21:56:08 +0000
Subject: Re: [bitcoin-dev] On Hardforks in the Context of SegWit
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: Tue, 09 Feb 2016 21:54:05 -0000
Thanks for keeping on-topic, replying to the proposal, and being civil!
Replies inline.
On 02/09/16 09:00, Anthony Towns via bitcoin-dev wrote:
> On Mon, Feb 08, 2016 at 07:26:48PM +0000, Matt Corallo via bitcoin-dev wrote:
>> As what a hard fork should look like in the context of segwit has never
>> (!) been discussed in any serious sense, I'd like to kick off such a
>> discussion with a (somewhat) specific proposal.
>
>> Here is a proposed outline (to activate only after SegWit and with the
>> currently-proposed version of SegWit):
>
> Is this intended to be activated soon (this year?) or a while away
> (2017, 2018?)?
It's intended to activate when we have clear and broad consensus around
a hard proposal across the community.
>> 1) The segregated witness discount is changed from 75% to 50%. The block
>> size limit (ie transactions + witness/2) is set to 1.5MB. This gives a
>> maximum block size of 3MB and a "network-upgraded" block size of roughly
>> 2.1MB. This still significantly discounts script data which is kept out
>> of the UTXO set, while keeping the maximum-sized block limited.
>
> This would mean the limits go from:
>
> pre-segwit segwit pkh segwit 2/2 msig worst case
> 1MB - - 1MB
> 1MB 1.7MB 2MB 4MB
> 1.5MB 2.1MB 2.2MB 3MB
>
> That seems like a fairly small gain (20% for pubkeyhash, which would
> last for about 3 months if you're growth rate means doubling every 9
> months), so this probably makes the most sense as a "quick cleanup"
> change, that also safely demonstrates how easy/difficult doing a hard
> fork is in practice?
>
> On the other hand, if segwit wallet deployment takes longer than
> hoped, the 50% increase for pre-segwit transactions might be a useful
> release-valve.
>
> Doing a "2x" hardfork with the same reduction to a 50% segwit discount
> would (I think) look like:
>
> pre-segwit segwit pkh segwit 2/2 msig worst case
> 1MB - - 1MB
> 1MB 1.7MB 2MB 4MB
> 2MB 2.8MB 2.9MB 4MB
>
> which seems somewhat more appealing, without making the worst-case any
> worse; but I guess there's concern about the relay networking scaling
> above around 2MB per block, at least prior to IBLT/weak-blocks/whatever?
The goal isnt really to get a "gain" here...its mostly to decrease the
worst-case (4MB is pretty crazy) and keep the total size in-line with
what the network could handle. Getting 1MB blocks through the network in
under a second is already incredibly difficult...2MB is pretty scary and
will take lots of work...3MB is over the bound of "yea, we can pretty
for sure get that to work pretty well".
>> 2) In order to prevent significant blowups in the cost to validate
>> [...] and transactions are only allowed to contain
>> up to 20 non-segwit inputs. [...]
>
> This could potentially make old, signed, but time-locked transactions
> invalid. Is that a good idea?
Hmmmmmm...you make a valid point. I was trying to avoid breaking old
transactions, but didnt think too much about time-locked ones.
Hmmmmmm...we could apply the limits to txn that dont have at least one
"newer than the fork input", but I'm not sure I like that either.
>> Along similar lines, we may wish to switch MAX_BLOCK_SIGOPS from
>> 1-per-50-bytes across the entire block to a per-transaction limit which
>> is slightly looser (though not too much looser - even with libsecp256k1
>> 1-per-50-bytes represents 2 seconds of single-threaded validation in
>> just sigops on my high-end workstation).
>
> I think turning MAX_BLOCK_SIGOPS and MAX_BLOCK_SIZE into a combined
> limit would be a good addition, ie:
>
> #define MAX_BLOCK_SIZE 1500000
> #define MAX_BLOCK_DATA_SIZE 3000000
> #define MAX_BLOCK_SIGOPS 50000
>
> #define MAX_COST 3000000
> #define SIGOP_COST (MAX_COST / MAX_BLOCK_SIGOPS)
> #define BLOCK_COST (MAX_COST / MAX_BLOCK_SIZE)
> #define DATA_COST (MAX_COST / MAX_BLOCK_DATA_SIZE)
>
> if (utxo_data * BLOCK_COST + bytes * DATA_COST + sigops * SIGOP_COST
> > MAX_COST)
> {
> block_is_invalid();
> }
>
> Though I think you'd need to bump up the worst-case limits somewhat to
> make that work cleanly.
There is a clear goal here of NOT using block-based limits and switching
to transaction-based limits. By switching to transaction-based limits we
avoid nasty issues with mining code either getting complicated or
enforcing too-strict limits on individual transactions.
>> 4) Instead of requiring the first four bytes of the previous block hash
>> field be 0s, we allow them to contain any value. This allows Bitcoin
>> mining hardware to reduce the required logic, making it easier to
>> produce competitive hardware [1].
>> [1] Simpler here may not be entirely true. There is potential for
>> optimization if you brute force the SHA256 midstate, but if nothing
>> else, this will prevent there being a strong incentive to use the
>> version field as nonce space. This may need more investigation, as we
>> may wish to just set the minimum difficulty higher so that we can add
>> more than 4 nonce-bytes.
>
> Could you just use leading non-zero bytes of the prevhash as additional
> nonce?
>
> So to work out the actual prev hash, set leading bytes to zero until
> you hit a zero. Conversely, to add nonce info to a hash, if there are
> N leading zero bytes, fill up the first N-1 (or less) of them with
> non-zero values.
>
> That would give a little more than 255**(N-1) possible values
> ((255**N-1)/254) to be exact). That would actually scale automatically
> with difficulty, and seems easy enough to make use of in an ASIC?
|
