path: root/8a/b018b7a8938dbfab7cc043403aa90f4d1a65e6

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <thyshizzle@outlook.com>) id 1YqZeG-0003GM-6i
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 04:12:28 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of outlook.com
	designates 65.54.190.39 as permitted sender)
	client-ip=65.54.190.39; envelope-from=thyshizzle@outlook.com;
	helo=BAY004-OMC1S28.hotmail.com; 
Received: from bay004-omc1s28.hotmail.com ([65.54.190.39])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1YqZeE-0001Ds-4l
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 04:12:28 +0000
Received: from BAY403-EAS382 ([65.54.190.59]) by BAY004-OMC1S28.hotmail.com
	over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);
	Thu, 7 May 2015 21:12:20 -0700
X-TMN: [9rBm480vMkRdB4nQ38dXtKDg6FNGPbB6]
X-Originating-Email: [thyshizzle@outlook.com]
Message-ID: <BAY403-EAS3821CC9EA00E6AEA78320E7C2DE0@phx.gbl>
Content-Type: multipart/related;
	boundary="_33e3fe11-568b-4998-9cc9-ea8d365dd9ef_"
MIME-Version: 1.0
To: Nicolas DORIER <nicolas.dorier@gmail.com>,
	<bitcoin-development@lists.sourceforge.net>
From: Thy Shizzle <thyshizzle@outlook.com>
Date: Fri, 8 May 2015 14:12:15 +1000
X-OriginalArrivalTime: 08 May 2015 04:12:20.0347 (UTC)
	FILETIME=[2D895CB0:01D08945]
X-Spam-Score: -0.5 (/)
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
	(thyshizzle[at]outlook.com)
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [65.54.190.39 listed in list.dnswl.org]
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1YqZeE-0001Ds-4l
Subject: Re: [Bitcoin-development] Solution for Block Size Increase
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2015 04:12:28 -0000

--_33e3fe11-568b-4998-9cc9-ea8d365dd9ef_
Content-Type: multipart/alternative;
	boundary="_d493d196-230a-4476-8cba-74a691d98647_"

--_d493d196-230a-4476-8cba-74a691d98647_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Nicolas=2C can you think if there would be a problem with allowing blocks t=
o be created faster instead of increasing block size? So say if difficulty =
was reduced to allow block creation every 2 minutes instead of 10 minutes=
=2C can you think of any bad outcome from this (I know this is different to=
 what you are saying) but I'm thinking if we allow 1mb blocks to be built f=
aster=2C that way transactions are processed quicker  thus gaining a higher=
 tps rate=2C i'd think no hard fork need occur right?

Is there any downsides that you can see? Obviously miners need yo update=2C=
 but I mean if they don't it just means they potentially take too long to m=
ake blocks and thus loose out in reward so there is the incentive for them =
to update to the easier difficulty=2C while still allowing blocks done on t=
he harder difficulty for backwards compatibility.

Thoughts?
________________________________
From: Nicolas DORIER<mailto:nicolas.dorier@gmail.com>
Sent: =E2=80=8E8/=E2=80=8E05/=E2=80=8E2015 9:17 AM
To: bitcoin-development@lists.sourceforge.net<mailto:bitcoin-development@li=
sts.sourceforge.net>
Subject: [Bitcoin-development] Solution for Block Size Increase

Executive Summary:

I explain the objectives that we should aim to reach agreement without
drama=2C controversy=2C and relief the core devs from the central banker ro=
le.
(As Jeff Garzik pointed out)
Knowing the objectives=2C I propose a solution based on the objectives that
can be agreed on tomorrow=2C 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=2C political
and ideological principles about what Bitcoin should become. This includes:

1) Whether Bitcoin should be storage of value or suitable for coffee
transaction=2C
2) Whether we need a fee market=2C block scarcity=2C and how much of it=2C
3) Whether we need to periodically increase block size via some voodoo
formula which speculate on future bandwidth and cost of storage=2C

Taking decisions based on such reasons is what central bankers do=2C and yo=
u
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=2C for the
only reason that storage and bandwidth is not free=2C nor a transaction=2C
thanks to increased propagation time.
This backed in scarcity will evolve automatically as storage=2C bandwidth=
=2C
encoding=2C evolve without anybody taking any decision=2C nor making any
speculation on the future.

Sadly=2C 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=2C

Still=2C removing the limit altogether is a no-no=2C what would happen if a
block of 100 GB is created? Immediately the network would be decentralized=
=2C
not only for miners but also for bitcoin service providers. Also=2C core de=
vs
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=2C and=2C I think=2C would=
 get a
reasonable consensus. It can be published tomorrow without any controversy=
=2C
would be agreed in one year=2C and can be safely reiterated every year.
Developers will also not have to play politics nor central banker. (well=2C
it sounds to good to be true=2C I waiting for being wrong)

The solution is to use block voting. For each block=2C a miner gives the si=
ze
of the block he would like to have at the next deadline (for example=2C 30
may 2015). The rational choice for them is just enough to clear the memory
pool=2C maybe a little less if he believes fee pressure is beneficial for
him=2C maybe a little more if he believes he should leave some room for
increased use.
At the deadline=2C we take the median of the votes and implement it as a ne=
w
block size limit. Reiterate for the next year.

Objectives reached:


   - No central banking decisions on devs shoulder=2C
   - Votes can start tomorrow=2C
   - Implementation has only to be ready in one year=2C (no kick-in-the-can=
)
   - Will increase as demand is growing=2C
   - Will increase as network capacity and storage is growing=2C
   - Bitcoin becomes what miners want=2C not what core devs and politician
   wants=2C
   - Implementation reasonably easy=2C
   - Will get miner consensus=2C no impact on existing bitcoin services=2C


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=2C 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=
=2C
everybody does it. (Because of the fallacy that changing a TCP
implementation is costless)

Often=2C when we think a real life situation is a prisoner dilemma problem=
=2C
it turns out that the incentives where just incorrectly modeled.

Core devs=2C thanks for all your work=2C but please step out of the banker'=
s
role and focus on where you are the best=2C 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=2C ie=2C for the maximization of whatever metric=2C it will clear=
ly put
you in banker's shoes. As an entrepreneur=2C I have other things to specula=
te
than who gets the biggest gun in the core team.
Please consider my solution=2C

Nicolas Dorier=2C

--_d493d196-230a-4476-8cba-74a691d98647_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dutf-8">
</head>
<body>
<div>
<div style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B">Nico=
las=2C can you think if there would be a problem with allowing blocks to be=
 created faster instead of increasing block size? So say if difficulty was =
reduced to allow block creation every 2 minutes
 instead of 10 minutes=2C can you think of any bad outcome from this (I kno=
w this is different to what you are saying) but I'm thinking if we allow 1m=
b blocks to be built faster=2C that way transactions are processed quicker&=
nbsp=3B thus gaining a higher tps rate=2C i'd
 think no hard fork need occur right?<br>
<br>
Is there any downsides that you can see? Obviously miners need yo update=2C=
 but I mean if they don't it just means they potentially take too long to m=
ake blocks and thus loose out in reward so there is the incentive for them =
to update to the easier difficulty=2C
 while still allowing blocks done on the harder difficulty for backwards co=
mpatibility.<br>
<br>
Thoughts?</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">From:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:nicolas.dorier@gmail.com">Nicolas DORIER</a></span><=
br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Sent:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B">=E2=80=8E8/=E2=80=8E05/=E2=80=8E2015 9:17 AM</span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">To:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitcoin-d=
evelopment@lists.sourceforge.net</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Subject:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B">[Bitcoin-development] Solution for Block Size Increase</span><br>
<br>
</div>
<div>
<div dir=3D"ltr">
<div>Executive Summary:<br>
<br>
I explain the objectives that we should aim to reach agreement without dram=
a=2C controversy=2C and relief the core devs from the central banker role. =
(As Jeff Garzik pointed out)<br>
Knowing the objectives=2C I propose a solution based on the objectives that=
 can be agreed on tomorrow=2C would permanently fix the block size problem =
without controversy and would be immediately applicable.<br>
<br>
The objectives:<br>
<br>
There is consensus on the fact that nobody wants the core developers to be =
seen as central bankers.<br>
There is also consensus that more decentralization is better than less. (as=
suming there is no cost to it)<br>
<br>
This means you should reject all arguments based on economical=2C political=
 and ideological principles about what Bitcoin should become. This includes=
:<br>
<br>
1) Whether Bitcoin should be storage of value or suitable for coffee transa=
ction=2C<br>
2) Whether we need a fee market=2C block scarcity=2C and how much of it=2C<=
br>
3) Whether we need to periodically increase block size via some voodoo form=
ula which speculate on future bandwidth and cost of storage=2C<br>
<br>
Taking decisions based on such reasons is what central bankers do=2C and yo=
u don=E2=80=99t want to be bankers. This follow that decisions should be ta=
ken only for technical and decentralization considerations. (more about dec=
entralization after)<br>
<br>
Scarcity will evolve without you taking any decisions about it=2C for the o=
nly reason that storage and bandwidth is not free=2C nor a transaction=2C t=
hanks to increased propagation time.<br>
This backed in scarcity will evolve automatically as storage=2C bandwidth=
=2C encoding=2C evolve without anybody taking any decision=2C nor making an=
y speculation on the future.<br>
<br>
Sadly=2C deciding how much decentralization should be in the system by twea=
king the block size limit is also an economic decision that should not have=
 its place between the core devs. This follow :</div>
<div><br>
</div>
<div>4) Core devs should not decide about the amount of suitable decentrali=
zation by tweaking block size limit=2C</div>
<div>&nbsp=3B</div>
<div>Still=2C removing the limit altogether is a no-no=2C what would happen=
 if a block of 100 GB is created? Immediately the network would be decentra=
lized=2C not only for miners but also for bitcoin service providers. Also=
=2C core devs might have technical consideration
 on bitcoin core which impose a temporary limit until the bug resolved.</di=
v>
<div>&nbsp=3B</div>
<div>The solution:</div>
<div>&nbsp=3B</div>
<div>So here is a proposal that address all my points=2C and=2C I think=2C =
would get a reasonable consensus. It can be published tomorrow without any =
controversy=2C would be agreed in one year=2C and can be safely reiterated =
every year. Developers will also not have
 to play politics nor central banker. (well=2C it sounds to good to be true=
=2C I waiting for being wrong)</div>
<div>&nbsp=3B</div>
<div>The solution is to use block voting. For each block=2C a miner gives t=
he size of the block he would like to have at the next deadline (for exampl=
e=2C 30 may 2015). The rational choice for them is just enough to clear the=
 memory pool=2C maybe a little less if
 he believes fee pressure is beneficial for him=2C maybe a little more if h=
e believes he should leave some room for increased use.</div>
<div>At the deadline=2C we take the median of the votes and implement it as=
 a new block size limit. Reiterate for the next year.</div>
<div>&nbsp=3B</div>
<div>Objectives reached:</div>
<div>&nbsp=3B</div>
<ul>
<li>No central banking decisions on devs shoulder=2C</li><li>Votes can star=
t tomorrow=2C</li><li>Implementation has only to be ready in one year=2C (n=
o kick-in-the-can)</li><li>Will increase as demand is growing=2C</li><li>Wi=
ll increase as network capacity and storage is growing=2C</li><li>Bitcoin b=
ecomes what miners want=2C not what core devs and politician wants=2C</li><=
li>Implementation reasonably easy=2C</li><li>Will get miner consensus=2C no=
 impact on existing bitcoin services=2C</li></ul>
<div>&nbsp=3B</div>
<div>Unknown:</div>
<ul>
<li>Effect on bitcoin core stability (core devs might have a valid technica=
l reason to impose a limit)</li><li>Maybe a better statistical function is =
possible</li></ul>
<div>Additional input for the debate:</div>
<div>&nbsp=3B</div>
<div>Some people were debating whether miners are altruist or act rationall=
y. We should always expect them to act rationally=2C but we should not forg=
et 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=2C everybody does it. (Because o=
f the fallacy that changing a TCP implementation is costless)</div>
<div>&nbsp=3B</div>
<div>Often=2C when we think a real life situation is a prisoner dilemma pro=
blem=2C it turns out that the incentives where just incorrectly modeled.</d=
iv>
<div><br>
</div>
<div>Core devs=2C thanks for all your work=2C but please step out of the ba=
nker's role and focus on where you are the best=2C I speak as an entreprene=
ur that doesn't want decisions about bitcoin to be taken by who has the big=
gest.<br>
If the decision of the hard limit is taken for other than purely technical =
decisions=2C ie=2C for the maximization of whatever metric=2C it will clear=
ly put you in banker's shoes. As an entrepreneur=2C I have other things to =
speculate than who gets the biggest gun
 in the core team.</div>
<div>Please consider my solution=2C</div>
<div><br>
</div>
<div>Nicolas Dorier=2C</div>
</div>
</div>
</body>
</html>

--_d493d196-230a-4476-8cba-74a691d98647_--

--_33e3fe11-568b-4998-9cc9-ea8d365dd9ef_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
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
--_33e3fe11-568b-4998-9cc9-ea8d365dd9ef_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--_33e3fe11-568b-4998-9cc9-ea8d365dd9ef_--