[bitcoin-dev] Thoughts on Forks, Scalability, and other Bitcoin inconveniences.

Eric Lombrozo elombrozo at gmail.com
Sun Jul 5 18:50:23 UTC 2015


Blockchain validation has become too expensive to properly secure the
network as per our original security model. The level of validation
required to comply with our security model has become completely
impractical for most use cases. Block space is still cheap only because of
block reward subsidy (which decreases exponentially with time). The
economics are already completely jacked - larger blocks will only worsen
this disparity.

The only practical way for the network to function at present (and what has
essentially ended up happening, if often tacitly) is by introducing trust,
in validators, miners, relayers, explorer websites, online wallets,
etc...which in and of itself wouldn't be the end of the world were it not
for the fact that the raison d'etre of bitcoin is trustlessness - and the
security model is very much based on this idea. Because of this, there's
been a tendency to deny that bitcoin cannot presently scale without trust.
This is horrible because our entire security model has gone out the
window...and has been replaced with something that isn't specified at all!

We don't really know the boundaries of our model, as the fork a couple of
days ago demonstrated. Right now we're basically trusting a few devs and
some mining pool operators that until now have been willing to cooperate
for the benefit of the network. It is dangerous to assume this will
continue perpetually. Even assuming the best intentions, an incident might
occur that this cooperation cannot easily repair.

We need to either solve the validation cost/bottleneck issue...or we need
to construct a new security model that takes these trust assumptions into
account.

- Eric Lombrozo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150705/d52e2a17/attachment.html>


More information about the bitcoin-dev mailing list