From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqRiZ-0003un-Si for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 19:44:23 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.218.52 as permitted sender) client-ip=209.85.218.52; envelope-from=jeremie.dl@gmail.com; helo=mail-oi0-f52.google.com; Received: from mail-oi0-f52.google.com ([209.85.218.52]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqRiV-0005Im-9M for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 19:44:23 +0000 Received: by oift201 with SMTP id t201so42222612oif.3 for ; Thu, 07 May 2015 12:44:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.65.164 with SMTP id y4mr189047obs.57.1431027853913; Thu, 07 May 2015 12:44:13 -0700 (PDT) Received: by 10.202.210.88 with HTTP; Thu, 7 May 2015 12:44:13 -0700 (PDT) In-Reply-To: References: <554A91BE.6060105@bluematt.me> Date: Thu, 7 May 2015 21:44:13 +0200 Message-ID: From: =?UTF-8?B?SsOpcsOpbWllIER1Ym9pcy1MYWNvc3Rl?= Cc: Bitcoin Dev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.2 (+) 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 (jeremie.dl[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header -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 1.6 MALFORMED_FREEMAIL Bad headers on message from free email service X-Headers-End: 1YqRiV-0005Im-9M Subject: Re: [Bitcoin-development] Block Size Increase 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, 07 May 2015 19:44:23 -0000 Any proposal to switch to a new hardcorded value so we have time to *really* figure out later what's next and all implications, is a road to a gigantic issue later when we want to switch to that "next". Sure we would have more time to think about, research all implications, simulate, discuss, etc. But the ability then to agree enough on a change to roll it out successfully will be much smaller, because of the economy being built on top of Bitcoin being much larger and the technical specifications of Bitcoin being closer to a complete freeze. What I'm trying to say is that we should look at long term lasting solutions even if it takes more effort and time right now and puts the network into some "troubles" for a while, because they're short term "troubles". (You define "troubles", depending on which side you stand at the moment...). I personally believe in adaptive block size mechanisms, because: (i) common sense tells me harcoding is never a solution for a system whose usage is for many aspects unpredictable (ii) we can't rely on human consensus to adapt it (seeing the mess it is already this time). It would have the advantage to place this block size issue entirely as part of the algorithmic contract you agree on when you use Bitcoin, similar to the difficulty adapation or the block reward. J=C3=A9r=C3=A9mie 2015-05-07 21:37 GMT+02:00 Mike Hearn : > >> These statements may even be true, but they're no logical conclusions >> even if they seem obvious to you. >> I don't think those claims are strictly true, specially because they >> involve predictions about what people will do. >> But if they're true they require some proof or at least some explanation= . > > > Thank you for your patience, Jorge. > > I have written up an explanation of what I think will happen if we run ou= t > of capacity: > > https://medium.com/@octskyward/crash-landing-f5cc19908e32 > > Now I'm going to go eat some dinner :) > > -------------------------------------------------------------------------= ----- > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >