If it is to be uncontroversial and everybody will upgrade, there's no
fear of a "veto power" and there's no good reason not to wait for 95%
block version signaling for deployment coordination, ideally using
bip9.
But that's for chosing the exact block where to start. The grace
period to give time t
On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev wrote:
> Blog post on a couple of the constants chosen:
> http://gavinandresen.ninja/seventyfive-twentyeight
Can you put this in the BIP's Rationale section (which appears to be mis-named
"Discussion" in the current draft)?
Soft-hardforks have the same behaviour for both SPV and full nodes.
I don't see the point in making this SPV-only "middle layer"...
On Friday, February 05, 2016 6:40:57 PM jl2012 via bitcoin-dev wrote:
> BIP draft: Hard fork opt-in mechanism for SPV nodes:
> https://github.com/bitcoin/bips/pull/32
On Fri, Feb 5, 2016 at 8:51 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This has been reviewed by merchants, miners and exchanges for a couple of
> weeks, and has been implemented and tested as part of the Bitcoin Classic
> and Bitcoin XT implementations.
>
"We can look at the adoption of the last major Bitcoin core release to
guess how long it might take people to upgrade. 0.11.0 was released on 12
July, 2015. Twenty eight days later, about 38% of full nodes were running
that release. Three months later, about 50% of the network was running that
rele
This has been reviewed by merchants, miners and exchanges for a couple of
weeks, and has been implemented and tested as part of the Bitcoin Classic
and Bitcoin XT implementations.
Constructive feedback welcome; argument about whether or not it is a good
idea to roll out a hard fork now will be unp
BIP draft: Hard fork opt-in mechanism for SPV nodes:
https://github.com/bitcoin/bips/pull/320
This is a supplement, instead of a replacement, of the hardfork bit BIP:
https://github.com/bitcoin/bips/pull/317
They solves different problems:
The hardfork bit tells full and SPV that a planned ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Binaries for bitcoin Core version 0.12.0rc3 are available from:
https://bitcoin.org/bin/bitcoin-core-0.12.0/test/
Source code can be found on github under the signed tag
https://github.com/bitcoin/bitcoin/tree/v0.12.0rc3
This is a release
On Feb 4, 2016 19:29, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote:
> > ABSTRACT
> >
> > This document specifies a proposed change to the semantics of the sign
> > bit of the "version" field
Concept ACK. I've been talking about adding this to BIP99 since before
scaling bitcoin Hong Kong, so it will be nice to have a BIP to just point
to. Also I hadn't thought about concurrent deployment of 2 hardforks, nice.
On Feb 4, 2016 23:30, "Gavin Andresen via bitcoin-dev" <
bitcoin-dev@lists.li
10 matches
Mail list logo