From: Eric Lombrozo <elombrozo@gmail•com>
To: Btc Drak <btcdrak@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: A measured response to save Bitcoin Core
Date: Sun, 31 May 2015 03:01:53 -0700 [thread overview]
Message-ID: <CABr1YTcSPcJBb-ZFQ59cYuywix4bfKpic_KjBProiAZ47o8fPg@mail.gmail.com> (raw)
In-Reply-To: <CADJgMztZuqt1BM8S2W1nOOBET=na+L+SZe4RRPdLU4tnbA-7cA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]
Drak,
I mostly agree with your assessment...except for your last claim.
Not that I wouldn't like to find a way to avoid politics, but like I've
argued before, it is inevitable that sooner or later any consensus protocol
that seeks dynamism will encounter politics.
The block size discussion, while ultimately necessary, for now is in the
best case merely serving as an example of the kind of political issues we
*really* need to be finding some solution for...and in the worst case is a
distraction and evasion.
Some protocol updates will be merely technical optimizations or feature
enhancements that are fairly uncontroversial...but some will inevitably be
highly controversial with real-world economic consequences, winners and
losers. We lack a process for deciding these issues. No matter how
sophistocated we make the protocol, somethings will inevitably require
external input to make these issues decidable...it is a Goedelian
implication. This external input could be some sort of vote (of which
hashing power is a particular kind) or perhaps something else.
There's something to be said for building the dynamics of hard forks *into*
our model rather than avoiding it at all costs. However, forks are the
easy part. The difficulty is in merging different branches. Perhaps we
should learn a thing or two from git. Perhaps the question we should be
asking is not "how do we avoid hard forks" but "how can we design the
network to allow for merging?"
- Eric Lombrozo
[-- Attachment #2: Type: text/html, Size: 1635 bytes --]
prev parent reply other threads:[~2015-05-31 10:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-31 0:29 Matt Whitlock
2015-05-31 9:32 ` s7r
2015-05-31 9:35 ` Btc Drak
2015-05-31 10:01 ` Eric Lombrozo [this message]
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=CABr1YTcSPcJBb-ZFQ59cYuywix4bfKpic_KjBProiAZ47o8fPg@mail.gmail.com \
--to=elombrozo@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=btcdrak@gmail$(echo .)com \
/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