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
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
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
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
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.
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
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
Recently wrote the following for a friend and thought others might learn
from it.
Nope, never heard that term. By bug-for-bug compatibility, do you mean
that, for each version which has a bug, each bug must behave in the *same*
buggy way?
Exactly. tl;dr: if you accept a block as valid due
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
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
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
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
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.
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
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
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
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
17 matches
Mail list logo
