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; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP0TKWESj3-h4k=Shd0R5SXAyGe31C3tQRq7UwK=y4+JTg@mail.gmail.com>
References: <554A91BE.6060105@bluematt.me>
	<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
	<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
	<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
	<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
	<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
	<CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>
	<CAPWm=eUFe7dKJCLeNACZ4n9vw0Xj9rHVM_RRLSczGXNU-ShR2w@mail.gmail.com>
	<CANEZrP1tCda9EbYgYu5QHN8ZgBCtGP7zRiDaXnq-rWU0ZHR9NQ@mail.gmail.com>
	<CAJHLa0Nrp4QEQqrBu6Tb+dohxX2VhWKMnO40xscZF1OJdfPF-A@mail.gmail.com>
	<CANEZrP0bmh5braGO5OKTNJU9VC_9=_1RDqHMx=aJBxT1w-q8oA@mail.gmail.com>
	<CABm2gDozyxovazcNEjWsRK0KzNJotWTg9X4m3aOfx7Gr_KprxQ@mail.gmail.com>
	<CANEZrP0TKWESj3-h4k=Shd0R5SXAyGe31C3tQRq7UwK=y4+JTg@mail.gmail.com>
Date: Thu, 7 May 2015 21:44:13 +0200
Message-ID: <CAJqsvLB4WkevHPTGbV_cxoDAU3CZ3=2FvHXtu_3vO9LXRVF2Ow@mail.gmail.com>
From: =?UTF-8?B?SsOpcsOpbWllIER1Ym9pcy1MYWNvc3Rl?= <jeremie.dl@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bitcoin-development] Block Size Increase
Precedence: list

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 <mike@plan99.net>:
>
>> 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
>