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
|
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 859F9B8A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 11:38:07 +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 ED4D4E1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 11:38:06 +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 1aSNfG-0008TC-L6 for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 07 Feb 2016 21:38:04 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Sun, 07 Feb 2016 21:37:57 +1000
Date: Sun, 7 Feb 2016 21:37:57 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20160207113757.GA10769@sapphire.erisian.com.au>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.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.1 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] BIP proposal: Increase block size limit to 2
megabytes
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, 07 Feb 2016 11:38:07 -0000
On Fri, Feb 05, 2016 at 03:51:08PM -0500, Gavin Andresen via bitcoin-dev wrote:
> Constructive feedback welcome; [...]
> Summary:
> Increase block size limit to 2,000,000 bytes.
> With accurate sigop counting, but existing sigop limit (20,000)
> And a new, high limit on signature hashing
To me, it seems absurd to have a hardfork but not take the opportunity
to combine these limits into a single weighted sum.
I'd suggest:
0.5*blocksize + 50*accurate_sigops + 0.001*sighash < 2,000,000
That provides worst case blocksize of 4MB, worst case sigops of 40,000
and worst case sighash bytes of 2GB. Given the separate limit on sighash
bytes and the improvements from libsecp256k1 I think 40k sigops should
be fine, but I'm happy to be corrected.
For a regular transaction, of say 380 bytes with 2 sigops and hashing
about 800 bytes, that uses up about 291 units of the limit, meaning
that if a block was full of transactions of that form, the limit would
be 6872 tx or 2.6MB per block (along with 13.7k sigops and ~5.5MB hashed
for signatures). Those weightings could probably be improved by doing
some detailed analysis and measurements, but I think they're pretty
reasonable for round figures.
The main advantage is that it would prevent blocks being cheaply filled
up due to hitting one of the secondary limits but only paying for the
contribution to the primary limit (presumably block size), which avoids
denial of service spam attacks.
I think having the limit take UTXO increase (or decrease) into effect
would be helpful too; but I don't have a specific suggestion. If it's
just a matter of making the limit stronger (eg adding "0.25*max(0,change
in UTXO bytes)" to the formula on the left, but not changing the limit on
the right), that would be a soft-forking change that could be introduced
later, and maybe that's fine.
If there was time to actually iterate on this proposal, rather than an
apparent aim to get it out the door in the next month or two, I think it
would be good to also design it so that the parameters of the weighted
sum could be adjusted by a soft-fork in future rather than requiring a
hard fork every time a limit's reached, or a weighting can be relaxed.
But I don't think that's feasible to design within a few weeks, so I
think it's off the table given the activation goal.
Cheers,
aj
|
