summaryrefslogtreecommitdiff
path: root/2e/1b13fac866bd4bdfdf78c8d1af2b7401b3b5bf
blob: 6c7675efee179916cca2f4a766751221f62c79ab (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
Return-Path: <david.vorick@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1BD00BEC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 15:57:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com
	[209.85.215.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8471916F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 15:57:22 +0000 (UTC)
Received: by mail-lf0-f45.google.com with SMTP id z15so12113761lfd.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 08:57:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=U21DCLFheL+ixDKKC5W1FvMtpIwWd4GoU2AdCDnSiEo=;
	b=sWPHpJhY1/JvJHdx8jeXVrRFo3Y/51wI4lB7wOM3hO3MY2yUc63I7iKbB+zK80pVYP
	uOeE3L0FN7pnOf2ZTtYt43tT2n5hIQm00QggNN8UzhyCR9znaVDkpDq8Yecrr/VQtZ/u
	2n4Th/3toMZ/EHBkT/DvTO48GNflFqy+DMW6jXBj1F0+Pyvn6D9H7mp+wE6HDSIDJ9f/
	vxy9yFpV1+eZn3EAD6fD0tk7JZCDxuMPBsXpxs7FtfjeGSDMwJi4u096dXgfyssLe5ww
	6MRyUIOJ7q0QKMp/MGaG4Sp5Us4ax1cbv2kdVNVGf2unSstLwqQF0PK+nxHfZjLtHUFS
	yZWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=U21DCLFheL+ixDKKC5W1FvMtpIwWd4GoU2AdCDnSiEo=;
	b=Hthi7mXDHXA8dnJUbHbudX3vMALVpubxR6QPNhkryILbDd/RfS2yXQp8T+LsMiMRxF
	KF4qtGzGQYCkMg4u+AibeFkef2OufCF1hqwftuPm7PZhDVi4jzRNhu4EeESjwBjnQZ0G
	VJSVtjGvnjBD2Iob9wcnDUJ6hvIGzPL9kPP7Hf4lcFwrBt7f/5itFN3mFotgI1CH+VLq
	eX6JuJcANCntCKUWDvNBDh2SzVb2s70Ppe04Xx9T/FlUycohfOJDdOWe0CCJyNiQ63jv
	P8zWZq5kDMpe1nCKe3S2e0RB7W2HYPKimnDdiZ+xUi9qRKQ2B8ceWgE7Hd7i82nhXjFU
	rnCw==
X-Gm-Message-State: AFeK/H2D2r+ntsZDgEzDjcGn5wZ06nIjSc19Yy1NVKt8MJai9YwMSNoEgPQ4bXTAOfUZa7yrI3+YrdeeeMOWDQ==
X-Received: by 10.28.97.2 with SMTP id v2mr1368934wmb.88.1490803040746; Wed,
	29 Mar 2017 08:57:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.55.9 with HTTP; Wed, 29 Mar 2017 08:57:19 -0700 (PDT)
Received: by 10.28.55.9 with HTTP; Wed, 29 Mar 2017 08:57:19 -0700 (PDT)
In-Reply-To: <CAB-xxiPV9oN1r2hV5a=U1pcYuiZ_qmth-AM-H+1Cjgc2uw-0xA@mail.gmail.com>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
	<CAB-xxiPV9oN1r2hV5a=U1pcYuiZ_qmth-AM-H+1Cjgc2uw-0xA@mail.gmail.com>
From: David Vorick <david.vorick@gmail.com>
Date: Wed, 29 Mar 2017 11:57:19 -0400
Message-ID: <CAFVRnyr=cYf34X80+dLHwYEPHdqA7mMtYZ_gD6j09C+aM31gQQ@mail.gmail.com>
To: =?UTF-8?Q?Martin_L=C3=ADzner?= <martin.lizner@gmail.com>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114a4c86ac8356054be0a15b
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM 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] Hard fork proposal from last week's meeting
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: Wed, 29 Mar 2017 15:57:23 -0000

--001a114a4c86ac8356054be0a15b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mar 29, 2017 9:50 AM, "Martin L=C3=ADzner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

Im tending to believe, that HF is necessary evil now.


I will firmly disagree. We know how to do a soft-fork blocksize increase.
If it is decided that a block size increase is justified, we can do it with
extension blocks in a way that achieves full backwards compatibility for
all nodes.

Barring a significant security motivation, there is no need to hardfork.

I am also solidly unconvinced that increasing the blocksize today is a good
move, even as little as SegWit does. It's too expensive for a home user to
run a full node, and user-run full nodes are what provide the strongest
defence against political manuveuring.

When considering what block size is acceptable, the impact of running
bitcoin in the background on affordable, non-dedicated home-hardware should
be a top consideration.

Disk space I believe is the most significant problem today, with RAM being
the second most significant problem, and finally bandwidth consumption as
the third most important consideration. I believe that v0.14 is already too
expensive on all three fronts, and that block size increases shouldn't be
considered at all until the requirements are reduced (or until consumer
hardware is better, but I believe we are talking 3-7 years of waiting if we
pick that option).

--001a114a4c86ac8356054be0a15b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Mar 29, 2017 9:50 AM, &quot;Martin L=C3=ADzner via bitcoin-dev&quo=
t; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt; wrote:<blockquote class=3D"quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>Im tending to believe, that HF is necessary evil now.=C2=A0</=
div></div></blockquote></div><br></div></div><div class=3D"gmail_extra" dir=
=3D"auto">I will firmly disagree. We know how to do a soft-fork blocksize i=
ncrease. If it is decided that a block size increase is justified, we can d=
o it with extension blocks in a way that achieves full backwards compatibil=
ity for all nodes.</div><div class=3D"gmail_extra" dir=3D"auto"><br></div><=
div class=3D"gmail_extra" dir=3D"auto">Barring a significant security motiv=
ation, there is no need to hardfork.</div><div class=3D"gmail_extra" dir=3D=
"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto">I am also solidly =
unconvinced that increasing the blocksize today is a good move, even as lit=
tle as SegWit does. It&#39;s too expensive for a home user to run a full no=
de, and user-run full nodes are what provide the strongest defence against =
political manuveuring.</div><div class=3D"gmail_extra" dir=3D"auto"><br></d=
iv><div class=3D"gmail_extra" dir=3D"auto">When considering what block size=
 is acceptable, the impact of running bitcoin in the background on affordab=
le, non-dedicated home-hardware should be a top consideration.</div><div cl=
ass=3D"gmail_extra" dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=
=3D"auto">Disk space I believe is the most significant problem today, with =
RAM being the second most significant problem, and finally bandwidth consum=
ption as the third most important consideration. I believe that v0.14 is al=
ready too expensive on all three fronts, and that block size increases shou=
ldn&#39;t be considered at all until the requirements are reduced (or until=
 consumer hardware is better, but I believe we are talking 3-7 years of wai=
ting if we pick that option).</div></div>

--001a114a4c86ac8356054be0a15b--