From: "Eric Lombrozo" <elombrozo@gmail.com>
To: "Milly Bitcoin" <milly@bitcoins.info>,
	bitcoin-dev@lists.linuxfoundation.org
Date: Sun, 20 Sep 2015 23:11:33 +0000
Message-Id: <em36157ae1-7c4b-488f-88d6-5a8df930ef0f@platinum>
In-Reply-To: <55FF3878.4060501@bitcoins.info>
Reply-To: "Eric Lombrozo" <elombrozo@gmail.com>
User-Agent: eM_Client/6.0.23181.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
Precedence: list


------ Original Message ------
From: "Milly Bitcoin via bitcoin-dev"=20
<bitcoin-dev@lists.linuxfoundation.org>
To: bitcoin-dev@lists.linuxfoundation.org
Sent: 9/20/2015 3:51:36 PM
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

>>Some of us have also been actively working towards developing
>>a more modular, layered architecture and better implementations that
>>will afford greater decentralization in software development with less
>>need for critical code reviews, less pushback from downstream=20
>>developers
>>who must continuously rebase, a better process for building consensus=20
>>in
>>the community, and simpler app migration.
>
>It sounds more efficient but it is not clear to me that it would change=
=20
>the level of centralization of how the final decisions are made.
>
>One threat to Bintcoin involves incentive for companies to hire=20
>developers.  The only reason is to change (or not change) Bitcoin Core=20
>so it is beneficial to their interests.  I am not sure anything can be=20
>done about that risk but it needs to be understood and considered and=20
>not just ignored.
Core development process and decentralized dev/community consensus=20
building (in particular for consensus-critical changes) is at the top of=
=20
my priorities as issues right now...and one that I'd love to discuss=20
more in depth...but it probably deserves its own thread. The political=20
angle seems very difficult right now while the systems architecture=20
stuff seems a bit more tractable...and it seems that without=20
architectural changes it will be extremely hard to decentralize=20
development and easily bring large numbers of new developers in.

>
>>We need to increase the basic infrastructure nodes by a factor much
>>larger than 2 or 3...more like 100 or 1000...and it's entirely doable
>>with properly aligned incentives.
>
>I assume that would mean fees that hike transaction fees and make=20
>Bitcoin more expensive?
>
Not necessarily. Right now we already pay around 3,600 bitcoins a day in=
=20
inflationary subsidies, very little of which goes to the majority of=20
critical infrastructure nodes and their operators. This is a problem=20
with the current protocol design, one we'll hopefully be able to fix.

Having more core infrastructure nodes doesn't need to raise costs per=20
transaction - but it will most likely require abandoning the current=20
approach of having three basic node classes: miners (which tend towards=20
centralized pools), full nodes (which must validate each of everyone's=20
transaction and in return get paid nothing), and thin clients (which=20
essentially amount to parasitic nodes that do not contribute any=20
resources back to the network and must be subsidized).