From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yshov-00009Y-T1 for bitcoin-development@lists.sourceforge.net; Thu, 14 May 2015 01:20:18 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.181 as permitted sender) client-ip=209.85.214.181; envelope-from=pieter.wuille@gmail.com; helo=mail-ob0-f181.google.com; Received: from mail-ob0-f181.google.com ([209.85.214.181]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YshoV-0002IK-2M for bitcoin-development@lists.sourceforge.net; Thu, 14 May 2015 01:19:51 +0000 Received: by obfe9 with SMTP id e9so43034826obf.1 for ; Wed, 13 May 2015 18:19:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.16.161 with SMTP id h1mr1389046obd.49.1431566385693; Wed, 13 May 2015 18:19:45 -0700 (PDT) Received: by 10.60.94.36 with HTTP; Wed, 13 May 2015 18:19:45 -0700 (PDT) In-Reply-To: References: <5550D8BE.6070207@electrum.org> Date: Wed, 13 May 2015 18:19:45 -0700 Message-ID: From: Pieter Wuille To: Aaron Voisine Content-Type: multipart/alternative; boundary=001a11c2fbe0e448d505160085af X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YshoV-0002IK-2M Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Long-term mining incentives X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 01:20:18 -0000 --001a11c2fbe0e448d505160085af Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine wrote: > Conservative is a relative term. Dropping transactions in a way that is > unpredictable to the sender sounds incredibly drastic to me. I'm suggesting > increasing the blocksize, drastic as it is, is the more conservative choice. > Transactions are already being dropped, in a more indirect way: by people and businesses deciding to not use on-chain settlement. That is very sad, but it's completely inevitable that there is space for some use cases and not for others (at whatever block size). It's only a "things don't fit anymore" when you see on-chain transactions as the only means for doing payments, and that is already not the case. Increasing the block size allows for more utility on-chain, but it does not fundamentally add more use cases - only more growth space for people already invested in being able to do things on-chain while externalizing the costs to others. > I would recommend that the fork take effect when some specific large > supermajority of the pervious 1000 blocks indicate they have upgraded, as a > safer alternative to a simple flag date, but I'm sure I wouldn't have to > point out that option to people here. > That only measures miner adoption, which is the least relevant. The question is whether people using full nodes will upgrade. If they do, then miners are forced to upgrade too, or become irrelevant. If they don't, the upgrade is risky with or without miner adoption. -- Pieter --001a11c2fbe0e448d505160085af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine <voisine= @gmail.com> wrote:
Conservati= ve is a relative term. Dropping transactions in a way that is unpredictable= to the sender sounds incredibly drastic to me. I'm suggesting increasi= ng the blocksize, drastic as it is, is the more conservative choice.
<= /blockquote>

Transactions are already being dropped, in = a more indirect way: by people and businesses deciding to not use on-chain = settlement. That is very sad, but it's completely inevitable that there= is space for some use cases and not for others (at whatever block size). I= t's only a "things don't fit anymore" when you see on-cha= in transactions as the only means for doing payments, and that is already n= ot the case. Increasing the block size allows for more utility on-chain, bu= t it does not fundamentally add more use cases - only more growth space for= people already invested in being able to do things on-chain while external= izing the costs to others.
=A0
<= div class=3D"gmail_extra">I would recommend that the fork take effect when = some specific large supermajority of the pervious 1000 blocks indicate they= have upgraded, as a safer alternative to a simple flag date, but I'm s= ure I wouldn't have to point out that option to people here.

That only measures miner adoption, which is the= least relevant. The question is whether people using full nodes will upgra= de. If they do, then miners are forced to upgrade too, or become irrelevant= . If they don't, the upgrade is risky with or without miner adoption.
--
Pieter

--001a11c2fbe0e448d505160085af--