From: "Jorge Timón" <jtimon@jtimon•cc>
To: NxtChg <nxtchg@hush•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Date: Wed, 19 Aug 2015 11:47:22 +0200 [thread overview]
Message-ID: <CABm2gDp1h_iQKkyS5MUE0R85_DJcCZBKwop1731CbLR-AGOX1A@mail.gmail.com> (raw)
In-Reply-To: <20150818094612.2344943128@smtp.hushmail.com>
On Tue, Aug 18, 2015 at 11:46 AM, NxtChg via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Eric,
>
>>FWIW...
>
> These are all good points and I agree with most of them. Yes, the block size debate is a lucky historical accident, which makes it easier for XT to pull off the split, but that's not the point.
>
> The point is, the split _must_ happen because the centralized governance of Bitcoin became a bigger problem than the risks of a fork or larger blocks.
>
> You cannot govern a decentralized currency with a centralized entity.
Nobody has complained about Bitcoin-XT (nor libbitcoin, nor libcoin,
nor against any other of the multiple alternative implementations of
bitcoin).
Please, understand that people are worried about the schism hardfork,
not about the software fork (which happened long ago when some of
Hearn's changes were reverted due to security concerns). If Bitcoin-XT
didn't had a schism hardfork, nobody would be calling it "an altcoin".
For consensus rules we use "the implementation is the specification"
as a principle for multiple reasons. By separating libconsensus (a
work in progress [far less progress than I would like]) we remove
Bitcoin Core's privileged position: Bitcoin Core wouldn't be "the
specification of the consensus rules" anymore, just a reference
implementation that is not "consensus-safer" compared to alternative
implementations (since they can use libconsensus directly [or a
software fork of it in the case of a reasonable schism hardfork]).
> That's why we shouldn't fear hard forks - they are the new reality, and if we cannot set up a reliable process for them to happen then there _is_ no decentralized Bitcoin and we all might as well just give up and go home.
We have many reasons to fear schism hardforks (
https://github.com/jtimon/bips/blob/bip-forks/bip-0099.mediawiki#Schism1_hardforks
), even though they may be unavoidable at some point (ie for an
ASIC-reset hardfork).
prev parent reply other threads:[~2015-08-19 9:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-16 22:34 jyellen
2015-08-17 3:10 ` jl2012
2015-08-17 7:04 ` Peter Todd
2015-08-17 10:09 ` NxtChg
2015-08-17 12:40 ` Vali Zero
2015-08-17 13:34 ` NxtChg
2015-08-17 14:03 ` Eric Lombrozo
2015-08-17 14:09 ` Levin Keller
2015-08-17 14:30 ` Eric Lombrozo
2015-08-17 14:36 ` Adam Back
2015-08-17 14:58 ` GC
2015-08-17 15:03 ` Levin Keller
2015-08-17 15:07 ` Eric Lombrozo
2015-08-19 3:49 ` odinn
2015-08-17 15:10 ` NxtChg
2015-08-17 16:37 ` Eric Lombrozo
2015-08-17 16:55 ` Eric Lombrozo
2015-08-18 4:37 ` Dave Scotese
2015-08-18 5:13 ` GC
2015-08-18 5:33 ` Dave Scotese
2015-08-18 9:46 ` NxtChg
2015-08-19 9:47 ` Jorge Timón [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=CABm2gDp1h_iQKkyS5MUE0R85_DJcCZBKwop1731CbLR-AGOX1A@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=nxtchg@hush$(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