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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 82FBB1194
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Feb 2016 03:14:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com
[209.85.213.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8C99166
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Feb 2016 03:14:04 +0000 (UTC)
Received: by mail-vk0-f44.google.com with SMTP id e6so67875473vkh.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 05 Feb 2016 19:14:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=WNifnxV9pQH3z5ZPfw9LfYhLADQWE2N/dVVJuVD6NqY=;
b=QnL849YJy2qVRMthYh4OyZ8d5rPtgCbXZxbOqK3KhGRxU4P2pBbJK0IOHAopFPqkkY
ZV2fCkqhP05NG8WihxBk6OXVK5vmHsGUF6W6bozZLyMi4iyd3aF+lxNpa5BbyYaOrQUN
Ub2nLkthQwgIr1VRJ6rZubyDNxRpkMEWon3lGK6GaEWodtOi9MAUNlInjbInHHyeryvl
wnDd1sAeblTnjrSutmCRBBdBr164EqpQ8bsONZIuXqschT8wrQb3FtQrsTPXhHwcAMr2
UAyc8mO8Pvvs6IK+SuCo0jmqJHOJm9MsPlabeAoe7tt9oRKLuLah6zZ53w4SFxxjdYJH
af2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=WNifnxV9pQH3z5ZPfw9LfYhLADQWE2N/dVVJuVD6NqY=;
b=JkPvEZOa2EtwV42D3meDRclR9+x/RBuUeQWJVluaI3Gzt8Q7L51FdCYnCxOm1qAIU6
aR0bprWDfRBfst3TizvJ70F6swUnTAH4ajH0Q6yRpHZQytq9TFGJi3qWB0JqULIB4xo2
nAYKHzaxWe17VxICqc6qQiE3yPX8E858swFCPsnsR3OyLjY0wydiLeu0CgmkwsjbShFd
RNq9HSafyGNj+68S9PDIcilGKv1rTTjtQd5X5x8DIb4tbPJ/mLOEp+AWXXI6uW3yg5Q1
wYI6m5FurMAfDW3h0jnQ4yRfUPhyElU5fVAJ1NCNzw9iiPafOsjy/l9WGl2JolsSVaYT
sDGA==
X-Gm-Message-State: AG10YOTw+bdSfl/AYH+UCG7p8bAxzwTycSYXcarEoViB2HzI7gHj1m5TfgSgnSCMgKCd5KLtwb6AzkXvM1GBkQ==
MIME-Version: 1.0
X-Received: by 10.31.180.213 with SMTP id d204mr10918055vkf.80.1454728443943;
Fri, 05 Feb 2016 19:14:03 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Fri, 5 Feb 2016 19:14:03 -0800 (PST)
In-Reply-To: <201602060012.26728.luke@dashjr.org>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
<201602060012.26728.luke@dashjr.org>
Date: Sat, 6 Feb 2016 04:14:03 +0100
Message-ID: <CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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 03:14:05 -0000
If it is to be uncontroversial and everybody will upgrade, there's no
fear of a "veto power" and there's no good reason not to wait for 95%
block version signaling for deployment coordination, ideally using
bip9.
But that's for chosing the exact block where to start. The grace
period to give time to all users to upgrade should be before and not
after miner's final confirmation: that simplifies and accelerates
things. Assuming we chose a grace period that is really adequate,
nearly 100% of miners will have likely upgraded long before everyone
(since miners are a subset of "everyone"). If that is not the case and
miners happen to be the latest to upgrade, using bip9 after the grace
period (aka starting median-time/height) will make sure the hardfork
doesn't get activated without 95% of the miners having upgraded.
28 days seems extremely short (specially if the grace period comes
first), some people have suggested one year for simple hardforks like
this one.
On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
