public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Justus Ranvier <justusranvier@riseup.net>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Date: Thu, 6 Nov 2014 19:03:10 -0500	[thread overview]
Message-ID: <20141107000310.GA6532@savin.petertodd.org> (raw)
In-Reply-To: <545C0617.7020300@riseup.net>

[-- Attachment #1: Type: text/plain, Size: 3759 bytes --]

On Thu, Nov 06, 2014 at 05:36:55PM -0600, Justus Ranvier wrote:
> This explanation is completely incoherent.
> 
> Because Bitcoin has a extra consensus requirements, requirements which
> are really rare in engineering, the necessity of fixing bugs is even
> greater.
> 
> There are two general ways to fix bugs: either as part of a
> controlled, planned, and managed process, or as a response to an
> immediate disaster.
> 
> The alternative to scheduling and planning the upgrades which are
> necessary to fix the bugs in the protocol, where such fixes can be
> written, tested, and documented at leisure, is to wait for some crisis
> and slap on another bandaid when the network breaks again (like it did
> March of last year).

The protocol is what the protocol is; the bugs are when you don't match
the protocol.

> Who benefits from not fixing bugs in Bitcoin?

We can bring up politics if you want.

In the current model, the specification *is* the protocol, and the
Bitcoin Core team is scared to death of changing anything; they've got
very little real power. Soft-forks are the minimum-viable way of making
changes to the protocol, and it's very clear how they get adopted:
minerr consensus. They're also a fundemental way of changing the
protocol that is impossible to prevent, so you might as well use it.

Hard-forks require political consensus to achieve, and the way you
create that political consensus is by creating committes, groups,
associations... Foundations. Every last one of those things requires
centralization and political power.

You know, the smartest thing the Bitcoin Foundation could do if they
wanted to cement their place in the Bitcoin ecosystem as a power broker
would be to setup a program of periodic hard-forks, say every year or
two, and then manage the committees that decide what goes into those
hard-forks. That they haven't suggested that yet is a sign that they're
either not evil, or they don't understand Bitcoin very well.

I think programmers find this reality hard to accept, because they're
mostly interested in writing code that'll get widely used. To them it's
hard to accept that the Bitcoin protocol *is* a few thousand lines of
C++ code, and they're not good enough to write their own implementation
and make it match; if we replaced programmers with writers we might get
the equally bizzare and pointless situation of people taking perfectly
good RFCs and rewriting them in their own words.

If you do care about keeping the politics of Bitcoin development free
from centralized control you should do what I advised the Dark Wallet
team to do a year ago: fork Bitcoin Core and change the
non-consensus-critical code that implements policy. I've done this
myself in a minor way with my replace-by-fee(1) version. Luke-Jr has
also done this with his Eligius branch, a fork that something like 30%
of the Bitcoin hashing power appear to run. (Discus Fish has been mining
non-standard transactions(2) lately)

Multiple *forks* of the Bitcoin Core reference client that are actually
getting used by miners and other users ensures that no one group
maintaining such a fork has the ability to change anything without
strong consensus. Forking the codebase, rather than rewriting it, best
ensures that your code actually implements the protocol properly, is
safe to use for mining, and actually gets used.

Rewriting Bitcoin Core is a fun project, but it's terrible politics.

1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.3
2) https://blockchain.info/tx/e24a4085c54a6362e615f8eab758c12d80e488b73757e6d2b8ab6bfc8be7007e

-- 
'peter'[:-1]@petertodd.org
000000000000000008f2290924a6882928d4566f487f33cc57203a6535795201

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

  reply	other threads:[~2014-11-07  0:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-06 21:32 [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug Peter Todd
2014-11-06 21:58 ` Tamas Blummer
2014-11-06 22:05   ` Matt Corallo
2014-11-06 22:11     ` Jeff Garzik
2014-11-06 22:48       ` Justus Ranvier
2014-11-06 23:26         ` Peter Todd
2014-11-06 23:36           ` Justus Ranvier
2014-11-07  0:03             ` Peter Todd [this message]
2014-11-07  8:07               ` Tamas Blummer
2014-11-07  8:48                 ` Peter Todd
2014-11-07 11:30                   ` Clément Elbaz
2014-11-07 11:47                     ` Peter Todd
2014-11-07 12:01                     ` Wladimir
2014-11-07 16:52               ` Mike Hearn
2014-11-15  4:43             ` Jean-Pierre Rupp
2014-11-06 23:19       ` Peter Todd
2014-11-06 23:12     ` Peter Todd
2014-11-07  2:04       ` Gregory Maxwell

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=20141107000310.GA6532@savin.petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=justusranvier@riseup.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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