summaryrefslogtreecommitdiff
path: root/da/a840cbaafc2522d006b411143811f8e116a1c7
blob: 5d0373c9371b419b37474cae157cf7fddae2c54d (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
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 AB055B7B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 04:15:17 +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 41F71155
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 04:15:17 +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 CC01238A17B7;
	Fri, 27 Jan 2017 04:14:19 +0000 (UTC)
X-Hashcash: 1:25:170127:andrew.johnson83@gmail.com::tECtw/mY1MNh5J36:dvbVv
X-Hashcash: 1:25:170127:bitcoin-dev@lists.linuxfoundation.org::3yi+YVDOWO3TJ=9M:IBuP
From: Luke Dashjr <luke@dashjr.org>
To: Andrew Johnson <andrew.johnson83@gmail.com>
Date: Fri, 27 Jan 2017 04:14:16 +0000
User-Agent: KMail/1.13.7 (Linux/4.4.39-gentoo; KDE/4.14.24; x86_64; ; )
References: <201701270107.01092.luke@dashjr.org>
	<CAAy62_+1OjF3V5g4wpOyW0KtNGodddJu_cxOfG-f+8LB7D=rPA@mail.gmail.com>
	<CAAy62_JuWMQ=HMmcw8GsQSDM8S+4LJeG1GHw1OdT+mQC3H-DOA@mail.gmail.com>
In-Reply-To: <CAAy62_JuWMQ=HMmcw8GsQSDM8S+4LJeG1GHw1OdT+mQC3H-DOA@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: <201701270414.18553.luke@dashjr.org>
X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
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: Fri, 27 Jan 2017 04:15:17 -0000

On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote:
> Comment on #1.  You're dropping the blocksize limit to 300KB and only
> reaching the limit that we have in place today 7 years later?

The limit only drops all the way to 300k if it activates before 2017 April. 
Considering that this requires the consensus of a hardfork, followed by a 
release in software, and then actual activation by miners using BIP9, I think 
it's extremely unlikely to activate by then.

But more importantly: such a drop would probably be good for the network in 
the long-term. As explained in the Rationale section, 300k is necessary to 
maintain our *current* IBD (first-time node sync) costs even with 
technological improvements (which appear to be slowing lately).

> We're already at capacity today, surely you're not serious with this
> proposal?

We are only at capacity because the space is available below actual costs, 
and/or because efficient alternatives are not yet widely supported. A 
reduction of block size will likely squeeze out spam, and perhaps some 
unsustainable microtransaction use, but the volume which actually *benefits 
from* the blockchain's security should continue along fine. Furthermore, once 
Lightning is widely implemented as well-tested, at least microtransactions are 
likely to gain a huge improvement in efficiency, reducing legitimate usage of 
block sizes well below 300k naturally - that is frankly when I first expect 
this proposal to be seriously considered for activation (which is independent 
from the consensus to include support for it in nodes).

> When you promised code for a hard forking block size increase in the HK
> agreement I don't believe that a decrease first was made apparent.  While
> not technically in violation of the letter of the agreement, I think this
> is a pretty obviously not in the spirit of it.

I did not mention the HK "roundtable", because this is indeed not in the 
spirit of what we set out to do, and do not wish this to be interpreted as 
some kind of slap in the face of the honest participants of that discussion.

This proposal is, however, the best I am currently able to honestly recommend 
that meets the hard criteria outlined at Hong Kong a year ago. (Continued work 
on the MMHF/SHF concept may eventually deliver a better solution, but it is 
not yet ready.)

Luke