[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-dev
Subject:    [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
From:       root () haskoin ! com (Jean-Pierre Rupp)
Date:       2014-11-15 4:43:43
Message-ID: 5466D9FF.3030105 () haskoin ! com
[Download RAW message or body]

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 :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x310A8A5B.asc
Type: application/pgp-keys
Size: 4087 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141114/5d4c8096/attachment.bin>
                
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141114/5d4c8096/attachment.sig>



[prev in list] [next in list] [prev in thread] [next in thread]