From: Eric Lombrozo <elombrozo@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Thoughts on Forks, Scalability, and other Bitcoin inconveniences.
Date: Sun, 5 Jul 2015 11:50:23 -0700 [thread overview]
Message-ID: <CABr1YTfiCx6igG9s6NbdD7pWLuoYSJ1QFcX_RnhbdtX5r=Z5Xg@mail.gmail.com> (raw)
In-Reply-To: <CABr1YTfEEXoQJ4SUtrUki9_WetWbGV7TEB+3usJGQqu-P55kSA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1793 bytes --]
next parent reply other threads:[~2015-07-05 18:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABr1YTf72fdQmTDEHAWVKqvTCLSpJZyiiw4g3ifrY8x5RZ=shQ@mail.gmail.com>
[not found] ` <CABr1YTfwcOQuNyqO57=jdghTnqt56u6pBvK6+dWbED-4OMh+Ug@mail.gmail.com>
[not found] ` <CABr1YTfEEXoQJ4SUtrUki9_WetWbGV7TEB+3usJGQqu-P55kSA@mail.gmail.com>
2015-07-05 18:50 ` Eric Lombrozo [this message]
2015-07-05 19:55 ` Eric Lombrozo
2015-07-05 20:33 ` Justus Ranvier
2015-07-05 20:53 ` Eric Lombrozo
2015-07-05 21:05 ` Justus Ranvier
2015-07-05 21:08 ` Eric Lombrozo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABr1YTfiCx6igG9s6NbdD7pWLuoYSJ1QFcX_RnhbdtX5r=Z5Xg@mail.gmail.com' \
--to=elombrozo@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox