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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1CA6B11E8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Feb 2016 00:12:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 617B11B2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Feb 2016 00:12:39 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 983B738A9783;
Sat, 6 Feb 2016 00:12:27 +0000 (UTC)
X-Hashcash: 1:25:160206:bitcoin-dev@lists.linuxfoundation.org::w40VGfkjjIOUoQ6j:aeCBk
X-Hashcash: 1:25:160206:gavinandresen@gmail.com::G6zdS+JqgzpYZIAz:wnYD
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Gavin Andresen <gavinandresen@gmail.com>
Date: Sat, 6 Feb 2016 00:12:25 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; )
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
In-Reply-To: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201602060012.26728.luke@dashjr.org>
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_SBL,
RP_MATCHES_RCVD 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] 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: Sat, 06 Feb 2016 00:12:40 -0000
On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev wrote:
> Blog post on a couple of the constants chosen:
> http://gavinandresen.ninja/seventyfive-twentyeight
Can you put this in the BIP's Rationale section (which appears to be mis-named
"Discussion" in the current draft)?
> Signature operations in un-executed branches of a Script are not counted
> OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a
> 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top
> of the execution stack, it is counted as one signature operation. If it is
> satisfied by the public key nearest the bottom of the execution stack, it
> is counted as twenty signature operations. Signature operations involving
> invalidly encoded signatures or public keys are not counted towards the
> limit
These seem like they will break static analysis entirely. That was a noted
reason for creating BIP 16 to replace BIP 12. Is it no longer a concern? Would
it make sense to require scripts to commit to the total accurate-sigop count
to fix this?
> The amount of data hashed to compute signature hashes is limited to
> 1,300,000,000 bytes per block.
The rationale for this wasn't in your blog post. I assume it's based on the
current theoretical max at 1 MB blocks? Even a high-end PC would probably take
40-80 seconds just for the hashing, however - maybe a lower limit would be
best?
> Miners express their support for this BIP by ...
But miners don't get to decide hardforks. How does the economy express their
support for it? What happens if miners trigger it without consent from the
economy?
If you are intent on using the version bits to trigger the hardfork, I suggest
rephrasing this such that miners should only enable the bit when they have
independently confirmed economic support (this means implementations need a
config option that defaults to off).
> SPV (simple payment validation) wallets are compatible with this change.
Would prefer if this is corrected to "Light clients" or something. Actual SPV
wallets do not exist at this time, and would not be compatible with a
hardfork.
> In the short term, an increase is needed to continue the current economic
> policies with regards to fees and block space, matching market expectations
> and preventing market disruption.
IMO this sentence is the most controversial part of your draft, and it
wouldn't suffer a loss to remove it (or at least make it subjective).
I would also prefer to see any hardfork:
1. Address at least the simple tasks on the hardfork wishlist (eg, enable some
disabled opcodes; fix P2SH for N-of->15 multisig; etc).
2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
insecure.
Luke
|
