From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqUzt-0001j0-Ch for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 23:14:29 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.178 as permitted sender) client-ip=209.85.213.178; envelope-from=nicolas.dorier@gmail.com; helo=mail-ig0-f178.google.com; Received: from mail-ig0-f178.google.com ([209.85.213.178]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqUzs-0003mL-4l for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 23:14:29 +0000 Received: by iget9 with SMTP id t9so20688747ige.1 for ; Thu, 07 May 2015 16:14:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.78.130 with SMTP id b2mr774962igx.42.1431040462775; Thu, 07 May 2015 16:14:22 -0700 (PDT) Sender: slashene@gmail.com X-Google-Sender-Delegation: slashene@gmail.com Received: by 10.64.133.7 with HTTP; Thu, 7 May 2015 16:14:22 -0700 (PDT) Date: Fri, 8 May 2015 01:14:22 +0200 X-Google-Sender-Auth: yt_o-BYP0We4hkARUNI-0rp1D_g Message-ID: From: Nicolas DORIER To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=089e0111b76a716c3005158612ec 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 (nicolas.dorier[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: 1YqUzs-0003mL-4l Subject: [Bitcoin-development] Solution for 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 23:14:29 -0000 --089e0111b76a716c3005158612ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Executive Summary: I explain the objectives that we should aim to reach agreement without drama, controversy, and relief the core devs from the central banker role. (As Jeff Garzik pointed out) Knowing the objectives, I propose a solution based on the objectives that can be agreed on tomorrow, would permanently fix the block size problem without controversy and would be immediately applicable. The objectives: There is consensus on the fact that nobody wants the core developers to be seen as central bankers. There is also consensus that more decentralization is better than less. (assuming there is no cost to it) This means you should reject all arguments based on economical, political and ideological principles about what Bitcoin should become. This includes: 1) Whether Bitcoin should be storage of value or suitable for coffee transaction, 2) Whether we need a fee market, block scarcity, and how much of it, 3) Whether we need to periodically increase block size via some voodoo formula which speculate on future bandwidth and cost of storage, Taking decisions based on such reasons is what central bankers do, and you don=E2=80=99t want to be bankers. This follow that decisions should be take= n only for technical and decentralization considerations. (more about decentralization after) Scarcity will evolve without you taking any decisions about it, for the only reason that storage and bandwidth is not free, nor a transaction, thanks to increased propagation time. This backed in scarcity will evolve automatically as storage, bandwidth, encoding, evolve without anybody taking any decision, nor making any speculation on the future. Sadly, deciding how much decentralization should be in the system by tweaking the block size limit is also an economic decision that should not have its place between the core devs. This follow : 4) Core devs should not decide about the amount of suitable decentralization by tweaking block size limit, Still, removing the limit altogether is a no-no, what would happen if a block of 100 GB is created? Immediately the network would be decentralized, not only for miners but also for bitcoin service providers. Also, core devs might have technical consideration on bitcoin core which impose a temporary limit until the bug resolved. The solution: So here is a proposal that address all my points, and, I think, would get a reasonable consensus. It can be published tomorrow without any controversy, would be agreed in one year, and can be safely reiterated every year. Developers will also not have to play politics nor central banker. (well, it sounds to good to be true, I waiting for being wrong) The solution is to use block voting. For each block, a miner gives the size of the block he would like to have at the next deadline (for example, 30 may 2015). The rational choice for them is just enough to clear the memory pool, maybe a little less if he believes fee pressure is beneficial for him, maybe a little more if he believes he should leave some room for increased use. At the deadline, we take the median of the votes and implement it as a new block size limit. Reiterate for the next year. Objectives reached: - No central banking decisions on devs shoulder, - Votes can start tomorrow, - Implementation has only to be ready in one year, (no kick-in-the-can) - Will increase as demand is growing, - Will increase as network capacity and storage is growing, - Bitcoin becomes what miners want, not what core devs and politician wants, - Implementation reasonably easy, - Will get miner consensus, no impact on existing bitcoin services, Unknown: - Effect on bitcoin core stability (core devs might have a valid technical reason to impose a limit) - Maybe a better statistical function is possible Additional input for the debate: Some people were debating whether miners are altruist or act rationally. We should always expect them to act rationally, but we should not forget the peculiarity of TCP backoff game: While it is in the best interest of players to NOT reemit TCP packet with a backoff if the ACK is not received, everybody does it. (Because of the fallacy that changing a TCP implementation is costless) Often, when we think a real life situation is a prisoner dilemma problem, it turns out that the incentives where just incorrectly modeled. Core devs, thanks for all your work, but please step out of the banker's role and focus on where you are the best, I speak as an entrepreneur that doesn't want decisions about bitcoin to be taken by who has the biggest. If the decision of the hard limit is taken for other than purely technical decisions, ie, for the maximization of whatever metric, it will clearly put you in banker's shoes. As an entrepreneur, I have other things to speculate than who gets the biggest gun in the core team. Please consider my solution, Nicolas Dorier, --089e0111b76a716c3005158612ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Executive Summary:

I explain the objectives th= at we should aim to reach agreement without drama, controversy, and relief = the core devs from the central banker role. (As Jeff Garzik pointed out)Knowing the objectives, I propose a solution based on the objectives that = can be agreed on tomorrow, would permanently fix the block size problem wit= hout controversy and would be immediately applicable.

The objectives= :

There is consensus on the fact that nobody wants the core develope= rs to be seen as central bankers.
There is also consensus that more dece= ntralization is better than less. (assuming there is no cost to it)

= This means you should reject all arguments based on economical, political a= nd ideological principles about what Bitcoin should become. This includes:<= br>
1) Whether Bitcoin should be storage of value or suitable for coffee= transaction,
2) Whether we need a fee market, block scarcity, and how m= uch of it,
3) Whether we need to periodically increase block size via so= me voodoo formula which speculate on future bandwidth and cost of storage,<= br>
Taking decisions based on such reasons is what central bankers do, a= nd you don=E2=80=99t want to be bankers. This follow that decisions should = be taken only for technical and decentralization considerations. (more abou= t decentralization after)

Scarcity will evolve without you taking an= y decisions about it, for the only reason that storage and bandwidth is not= free, nor a transaction, thanks to increased propagation time.
This bac= ked in scarcity will evolve automatically as storage, bandwidth, encoding, = evolve without anybody taking any decision, nor making any speculation on t= he future.

Sadly, deciding how much decentralization should be in th= e system by tweaking the block size limit is also an economic decision that= should not have its place between the core devs. This follow :
<= br>
4) Core devs should not decide about the amount of suitable d= ecentralization by tweaking block size limit,
=C2=A0
St= ill, removing the limit altogether is a no-no, what would happen if a block= of 100 GB is created? Immediately the network would be decentralized, not = only for miners but also for bitcoin service providers. Also, core devs mig= ht have technical consideration on bitcoin core which impose a temporary li= mit until the bug resolved.
=C2=A0
The solution:
<= div>=C2=A0
So here is a proposal that address all my points, and,= I think, would get a reasonable consensus. It can be published tomorrow wi= thout any controversy, would be agreed in one year, and can be safely reite= rated every year. Developers will also not have to play politics nor centra= l banker. (well, it sounds to good to be true, I waiting for being wrong)
=C2=A0
The solution is to use block voting. For each blo= ck, a miner gives the size of the block he would like to have at the next d= eadline (for example, 30 may 2015). The rational choice for them is just en= ough to clear the memory pool, maybe a little less if he believes fee press= ure is beneficial for him, maybe a little more if he believes he should lea= ve some room for increased use.
At the deadline, we take the medi= an of the votes and implement it as a new block size limit. Reiterate for t= he next year.
=C2=A0
Objectives reached:
=C2= =A0
  • No central banking decisions on devs shoulder,
  • Vot= es can start tomorrow,
  • Implementation has only to be ready in one y= ear, (no kick-in-the-can)
  • Will increase as demand is growing,
    • <= li>Will increase as network capacity and storage is growing,
  • Bitcoi= n becomes what miners want, not what core devs and politician wants,
    • Implementation reasonably easy,
  • Will get miner consensus, no impa= ct on existing bitcoin services,
=C2=A0
Unknown:
  • Effect on bitcoin core stability (core devs might have a valid t= echnical reason to impose a limit)
  • Maybe a better statistical funct= ion is possible
Additional input for the debate:
= =C2=A0
Some people were debating whether miners are altruist or a= ct rationally. We should always expect them to act rationally, but we shoul= d not forget the peculiarity of TCP backoff game: While it is in the best i= nterest of players to NOT reemit TCP packet with a backoff if the ACK is no= t received, everybody does it. (Because of the fallacy that changing a TCP = implementation is costless)
=C2=A0
Often, when we think= a real life situation is a prisoner dilemma problem, it turns out that the= incentives where just incorrectly modeled.

Core d= evs, thanks for all your work, but please step out of the banker's role= and focus on where you are the best, I speak as an entrepreneur that doesn= 't want decisions about bitcoin to be taken by who has the biggest.
= If the decision of the hard limit is taken for other than purely technical = decisions, ie, for the maximization of whatever metric, it will clearly put= you in banker's shoes. As an entrepreneur, I have other things to spec= ulate than who gets the biggest gun in the core team.
Please cons= ider my solution,

Nicolas Dorier,
--089e0111b76a716c3005158612ec--