Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-14 Thread Jean-Pierre Rupp
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

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-07 Thread Tamas Blummer
Peter, forking would work best with a freeze of the consensus code. Do you see any chance for that? Tamas Blummer On Nov 7, 2014, at 1:03 AM, Peter Todd p...@petertodd.org wrote: Forking the codebase, rather than rewriting it, best ensures that your code actually implements the protocol

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-07 Thread Peter Todd
On Fri, Nov 07, 2014 at 09:07:47AM +0100, Tamas Blummer wrote: Peter, forking would work best with a freeze of the consensus code. Do you see any chance for that? To a first approximation the consensus code *is* frozen; if we introduce any consensus changes into it at this point it's due to

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-07 Thread Clément Elbaz
Thinking out loud here : would it make sense to separate the consensus code into some kind of Bitcoin Kernel (similar to the Linux Kernel) project that could be used by anyone ? Bitcoin Core (and any other application wishing to do so) could be based on it. The kernel would just contain the

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-07 Thread Peter Todd
On Fri, Nov 07, 2014 at 11:30:22AM +, Clément Elbaz wrote: Thinking out loud here : would it make sense to separate the consensus code into some kind of Bitcoin Kernel (similar to the Linux Kernel) project that could be used by anyone ? That's a pretty old idea, and we're working on it.

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-07 Thread Wladimir
On Fri, Nov 7, 2014 at 12:30 PM, Clément Elbaz clem...@gmail.com wrote: Thinking out loud here : would it make sense to separate the consensus code into some kind of Bitcoin Kernel (similar to the Linux Kernel) project that could be used by anyone ? Yes, we're moving in that direction. First

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-07 Thread Mike Hearn
Who benefits from not fixing bugs in Bitcoin? We can bring up politics if you want. No, please don't. That question was rhetorical, not an invitation for you to try and convince bystanders that anyone who disagrees with you is a shadowy Agent Of Centralisation or an idiot. You use that

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Tamas Blummer
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

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Matt Corallo
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

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Jeff Garzik
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

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Justus Ranvier
On 11/06/2014 04:11 PM, Jeff Garzik wrote: 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

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Peter Todd
On Thu, Nov 06, 2014 at 10:05:54PM +, Matt Corallo 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.

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Peter Todd
On Thu, Nov 06, 2014 at 11:11:52PM +0100, Jeff Garzik wrote: 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

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Peter Todd
On Thu, Nov 06, 2014 at 04:48:54PM -0600, Justus Ranvier wrote: Why not schedule protocol upgrades every two years for the foreseeable future? For the same reason we don't do hard-forking upgrades of basically every protocol on the planet on a regular basis, even when we don't have consensus

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Peter Todd
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

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Gregory Maxwell
On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd p...@petertodd.org wrote: BIP62 does make life easier for wallet authors as they don't have to deal with malleability - maybe! - Yes, I agree for most contract purposes CTLV is what you want to be using, instead of refund transactions beyond being