MIME-Version: 1.0
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
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Precedence: list

--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--