Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1BD00BEC for ; 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 ; Wed, 29 Mar 2017 15:57:22 +0000 (UTC) Received: by mail-lf0-f45.google.com with SMTP id z15so12113761lfd.1 for ; 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: References: From: David Vorick Date: Wed, 29 Mar 2017 11:57:19 -0400 Message-ID: To: =?UTF-8?Q?Martin_L=C3=ADzner?= , Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

On Mar 29, 2017 9:50 AM, "Martin L=C3=ADzner via bitcoin-dev&quo= t; <bitcoin-dev= @lists.linuxfoundation.org> wrote:
Im tending to believe, that HF is necessary evil now.=C2=A0

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 class=3D"gmail_extra" dir=3D"auto">Barring a significant security motiv= ation, there is no need to hardfork.

I am also solidly = unconvinced that increasing the blocksize today is a good move, even as lit= tle as SegWit does. It'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.

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.

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'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).
--001a114a4c86ac8356054be0a15b--