public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jean-Pierre Rupp <root@haskoin•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Date: Fri, 14 Nov 2014 20:43:43 -0800	[thread overview]
Message-ID: <5466D9FF.3030105@haskoin.com> (raw)
In-Reply-To: <545C0617.7020300@riseup.net>


[-- Attachment #1.1: Type: text/plain, Size: 2364 bytes --]

Jean-Pierre Rupp from Haskoin here.

I support a hard fork to fix consensus bugs.  The Bitcoin protocol should eventually get to a state where it is documented in a clear and understandable fashion.  Bugs are bugs, and are the enemy.  We should not attempt to live with them.  We should be opening a process of thoroughly documenting and reparing consensus bugs on a separate branch, and eventually schedule a hard fork.

There are two good things that will come out of that:

1. Known bugs will be gone, and
2. We will have a process in place to get rid of future bugs in eventual future hard forks.

We do not need to become paranoid about the ramifications of a hard fork, or how it will open the door for unwanted changes in the protocol.  We are discussing about removing bugs, and bugs that could be used to exploit the network in ways that may not be immediately obvious.

There are 144 blocks generated per day by groups of miners that are mostly identified.  It is not going to be a titanic task to get consensus from the main mining pools on fixing this at the mining level.  We must address how the fixes for some of these bugs affect other types of software such as wallets.  I can think that fixing the bug where OP_CHECKMULTISIG pops an extra value from the stash could be more traumatic, since it requires anything that creates and validates multi-signature transactions to change the way it works.  Hardware wallets could be impacted.  But most of the consensus bugs would not affect the way the vast majority of bitcoin transactions that are currently created.  Therefore it should not be traumatic at all for users, but only really affect mining pools, who would only need to be convinced to upgrade their bitcoind well in advance, which seems to me that it is not an issue at all.

We should not compare doing a Bitcoin hard-fork with doing something like deploying IPv6 world-wide or enforcing TLS and SPF on every SMTP connection.  We should not conflate Bitcoin with other network protocols.  The Bitcoin protocol is actually relatively easy to upgrade at this point.  Let's take advantage of this fact.

On 06/11/14 15:36, Justus Ranvier wrote:
> Because Bitcoin has a extra consensus requirements, requirements which
> are really rare in engineering, the necessity of fixing bugs is even
> greater.

-- 
Be Happy :)


[-- Attachment #1.2: 0x310A8A5B.asc --]
[-- Type: application/pgp-keys, Size: 4154 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  parent reply	other threads:[~2014-11-15  5:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-06 21:32 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
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 [this message]
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=5466D9FF.3030105@haskoin.com \
    --to=root@haskoin$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /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