summaryrefslogtreecommitdiff
path: root/b6/1a42b29e2585945c22427a27f73339e7f48913
blob: 2ebdee9d893749e7033b77f31fff61cb185de880 (plain)
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
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 63CDF8D9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 May 2017 20:23:48 +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 EB1071DE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 May 2017 20:23:47 +0000 (UTC)
Received: from ishibashi.localnet (unknown
	[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id DADFE38A12BC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 May 2017 20:23:41 +0000 (UTC)
X-Hashcash: 1:25:170523:bitcoin-dev@lists.linuxfoundation.org::IaL+cQen1cZUq/U9:1SRr
From: Luke Dashjr <luke@dashjr.org>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Tue, 23 May 2017 20:23:40 +0000
User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; )
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="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201705232023.40588.luke@dashjr.org>
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 23 May 2017 20:23:48 -0000

In light of some recent discussions, I wrote up this BIP for a real 2 MB block 
size hardfork following Segwit BIP148 activation. This is not part of any 
agreement I am party to, nor anything of that sort. Just something to throw 
out there as a possible (and realistic) option.

Note that I cannot recommend this to be adopted, since frankly 1 MB blocks 
really are still too large, and this blunt-style hardfork quite risky even 
with consensus. But if the community wishes to adopt (by unanimous consensus) 
a 2 MB block size hardfork, this is probably the best way to do it right now. 
The only possible way to improve on this IMO would be to integrate it into 
MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-size HF 
improvements).

I have left Author blank, as I do not intend to personally champion this. 
Before it may be assigned a BIP number, someone else will need to step up to 
take on that role. Motivation and Rationale are blank because I do not 
personally think there is any legitimate rationale for such a hardfork at this 
time; if someone adopts this BIP, they should complete these sections. (I can 
push a git branch with the BIP text if someone wants to fork it.)

<pre>
BIP: ?
Layer: Consensus (hard fork)
Title: Post-segwit 2 MB block size hardfork
Author: FIXME
Comments-Summary: No comments yet.
Comments-URI: ?
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-2-Clause
</pre>

==Abstract==

Legacy Bitcoin transactions are given the witness discount, and a block size 
limit of 2 MB is imposed.

==Copyright==

This BIP is licensed under the BSD 2-clause license.

==Specification==

Upon activation, a block size limit of 2000000 bytes is enforced.
The block weight limit remains at 4000000 WU.

The calculation of block weight is modified:
all witness data, including both scriptSig (used by pre-segwit inputs) and 
segwit witness data, is measured as 1 weight-unit (WU), while all other data 
in the block is measured as 4 WU.

The witness commitment in the generation transaction is no longer required, 
and instead the txid merkle root in the block header is replaced with a hash 
of:

1. The witness reserved value.
2. The witness merkle root hash.
3. The transaction ID merkle root hash.

The maximum size of a transaction stripped of witness data is limited to 1 MB.

===Deployment===

This BIP is deployed by flag day, in the block where the median-past time 
surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).

It is assumed that when this flag day has been reached, Segwit has been 
activated via BIP141 and/or BIP148.

==Motivation==

FIXME

==Rationale==

FIXME

==Backwards compatibility==

This is a hardfork, and as such not backward compatible.
It should not be deployed without consent of the entire Bitcoin community.
Activation is scheduled for 18 months from the creation date of this BIP, 
intended to give 6 months to establish consensus, and 12 months for 
deployment.

==Reference implementation==

FIXME