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 openin
>
> > 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
On Fri, Nov 7, 2014 at 12:30 PM, 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 ?
Yes, we're moving in that direction. First with a script
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
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 abs
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
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 wrote:
> Forking the codebase, rather than rewriting it, best
> ensures that your code actually implements the protocol properly, is
> safe
On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd 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 more clearly
correct
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/06/2014 05:26 PM, Peter Todd wrote:> 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 problems to worry about.
>
> Flag days are really rar
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 p
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 solvin
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 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 hav
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 fork
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 th
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 cons
17 matches
Mail list logo
