public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@bitpay.com>
To: Matt Corallo <bitcoin-list@bluematt.me>
Cc: Bitcoin Dev <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 23:11:52 +0100	[thread overview]
Message-ID: <CAJHLa0NTj6m4JpHx3+nWtYVV1Zpwf-FaxiyFX9DR821cQYVqsg@mail.gmail.com> (raw)
In-Reply-To: <545BF0C2.3030201@bluematt.me>

IMO, CHECKLOCKTIMEVERIFY should be included in that list, too.

RE soft fork vs. hard fork:  It's about this time at Mike Hearn will
chime in, on the side of hard forks.  Hard forks are in a sense much
cleaner, and permit solving problems not otherwise solvable with a
hard fork.  However, hard forks clearly have risks, notably the Big
Risk akin to a US Constitutional Convention:  once you open the door,
anything can happen, any rule no matter how "sacred" can be changed.

Soft forks are not without their own risks, e.g. reducing some things
to SPV levels of security.

Leaning towards soft fork, but it is a good discussion to have.  A
poorly implemented soft fork may potentially require a hard fork to
fix rollout bugs.


On Thu, Nov 6, 2014 at 11:05 PM, Matt Corallo <bitcoin-list@bluematt.me> wrote:
> Depends, without BIP62 a /lot/ of the even basic contracts that people
> want to use today (or wanted to use 18 months ago) are unusable, in
> fact, without BIP62, the atomic swaps suggested as important for
> sidechains are not secure. While redoing Bitcoin in a hardfork is nice,
> its a very long-term thing, so I'm not sure about making people wait for
> a large hardfork just to use payment channels.
>
> Also, I echo the difficulty of writing consensus-compatible code and
> highly suggest anyone with money behind an implementation that is doing
> script verification in code that isnt Bitcoin Core rethink that decision.
>
> Matt
>
> On 11/06/14 21:58, Tamas Blummer wrote:
>> Thanks Peter,
>>
>> Having tried to write a bug-for-bug compatible code with Satoshi, I can only second that it is rather close to impossible.
>>
>> The aim of BIP62 is noble, still it does not feel right for me to increase the complexity of the code with e.g. soft-fork-ready versioning.
>> Freezing the consensus code, studying its bugs appears more appropriate to me. What we learn could define a hard fork or a better
>> chain we migrate to as discussed by blockstream.
>>
>> Tamas Blummer
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



  reply	other threads:[~2014-11-06 22:12 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 [this message]
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
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=CAJHLa0NTj6m4JpHx3+nWtYVV1Zpwf-FaxiyFX9DR821cQYVqsg@mail.gmail.com \
    --to=jgarzik@bitpay.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=bitcoin-list@bluematt.me \
    /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