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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C9DD6EF7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Feb 2016 09:00:08 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 382D3156
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Feb 2016 09:00:08 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian))
id 1aT49V-0007ai-KV for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 09 Feb 2016 19:00:07 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Tue, 09 Feb 2016 19:00:02 +1000
Date: Tue, 9 Feb 2016 19:00:02 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20160209090002.GB18324@sapphire.erisian.com.au>
References: <56B8EBF8.4050602@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56B8EBF8.4050602@mattcorallo.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
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 09:00:08 -0000
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?)?
> 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?
> 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?
> 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.
> 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?
Cheers,
aj
|
