From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D46F0EBF for ; Sat, 26 Dec 2015 23:16:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 406028C for ; Sat, 26 Dec 2015 23:16:18 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id m11so103898785igk.1 for ; Sat, 26 Dec 2015 15:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L0QRcdCCeqqKfizXL0IlNFL/3WbHh7DRddjUU/bjXbU=; b=yVWdAjVNxTq6151y8o6veDLOAqScdxQY22SbNkCVUSJ0M/P+yf/X5mHt0O8V6cBL47 BasWGeZ5PyUtaqiUU3HSCEI7qrt5r4zBLYLsurJXAZMd+xer1gaIWmqcXLTutnoJwAt6 O8kpaGKGpDUoOQ0XZwAzjQwY3lx7E3OmbGxtY8eYbtwa4ENWAzgqCivQ1Qg2Of9ujErN z3WRswPb15SuvmXD7l3VJEasxPZ9Io7lp10Ge0eisl89mBfKIjONhOGjP2i+TTSm1wTR /euPjOVeUGPpN8wWVfXakJ9KwBc4/hwtjY4qXhtA3kVtC+cp+Nj8OAf58DMF3wFWDerY N6eg== MIME-Version: 1.0 X-Received: by 10.50.85.107 with SMTP id g11mr19896798igz.4.1451171777689; Sat, 26 Dec 2015 15:16:17 -0800 (PST) Received: by 10.36.80.6 with HTTP; Sat, 26 Dec 2015 15:16:17 -0800 (PST) Received: by 10.36.80.6 with HTTP; Sat, 26 Dec 2015 15:16:17 -0800 (PST) In-Reply-To: <2D7C4E00-7451-45B6-94B6-07A7230FBF88@toom.im> References: <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com> <246AA3BE-570D-4B88-A63D-AC76CB2B0CB8@toom.im> <2D7C4E00-7451-45B6-94B6-07A7230FBF88@toom.im> Date: Sun, 27 Dec 2015 00:16:17 +0100 Message-ID: From: Pieter Wuille To: Jonathan Toomim Content-Type: multipart/alternative; boundary=089e0149bb025140770527d54232 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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 Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 23:16:18 -0000 --089e0149bb025140770527d54232 Content-Type: text/plain; charset=UTF-8 On Dec 27, 2015 00:06, "Jonathan Toomim" wrote: > Given that a supermajority of users and miners have been asking for a hard fork to increase the blocksize for years, I do not think that mobilizing people to upgrade their nodes is going to be hard. > > When we do the hard fork, we will need to encourage people to upgrade their full nodes. We may want to request that miners not trigger the fork until some percentage of visible full nodes have upgraded. I am generally not interested in a system where we rely on miners to make that judgement call to fork off nodes that don't pay attention and/or disagree with the change. This is not because I don't trust them, but because I believe one of the principle values of the system is that its consensus system should be hard to change. I can't tell you what code to run of course, but I can decide what system I find interesting to build. And it seems many people have signed off on working towards a plan that does not include a hard fork being scheduled right now: https://bitcoin.org/en/bitcoin-core/capacity-increases Cheers, -- Pieter --089e0149bb025140770527d54232 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 27, 2015 00:06, "Jonathan Toomim" <j@toom.im> wrote:

> Given that a supermajority of users and miners have bee= n asking for a hard fork to increase the blocksize for years, I do not thin= k that mobilizing people to upgrade their nodes is going to be hard.
>
> When we do the hard fork, we will need to encourage people to upgrade = their full nodes. We may want to request that miners not trigger the fork u= ntil some percentage of visible full nodes have upgraded.

I am generally not interested in a system where we rely on m= iners to make that judgement call to fork off nodes that don't pay atte= ntion and/or disagree with the change. This is not because I don't trus= t them, but because I believe one of the principle values of the system is = that its consensus system should be hard to change.

I can't tell you what code to run of course, but I can d= ecide what system I find interesting to build. And it seems many people hav= e signed off on working towards a plan that does not include a hard fork be= ing scheduled right now: https://bitcoin.org/en/bitcoin-core/capacity-increases=

Cheers,

--
Pieter

--089e0149bb025140770527d54232--