On Sun, Feb 07, 2016 at 03:20:27PM -0500, Gavin via bitcoin-dev wrote:
> > On Feb 7, 2016, at 2:27 PM, wrote:
> > Normal version number only suggests softforks, which is usually not a
> > concern for SPV clients.
> Soft forks affect the security of low-confirmation (zero or one) transactions
>
> On Feb 7, 2016, at 2:27 PM, wrote:
>
> Normal version number only suggests softforks, which is usually not a concern
> for SPV clients.
Soft forks affect the security of low-confirmation (zero or one) transactions
sent to SPV wallets even more than hard forks, and because many users and
b
From: Gavin Andresen [mailto:gavinandre...@gmail.com]
Sent: Friday, 5 February, 2016 06:16
To: Gregory Maxwell
Cc: jl2012 ; Bitcoin Dev
Subject: Re: [bitcoin-dev] Hardfork bit BIP
>It is always possible I'm being dense, but I still don't understand how this
>proposal makes
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
It is always possible I'm being dense, but I still don't understand how
this proposal makes a chain-forking situation better for anybody.
If there are SPV clients that don't pay attention to versions in block
headers, then setting the block version negative doesn't directly help
them, they will ig
On Thu, Feb 4, 2016 at 5:14 PM, jl2012 via bitcoin-dev
wrote:
> https://github.com/bitcoin/bips/pull/317
I think this is a good idea, and I've independently proposed it in the past.
I agree with most of luke's language nitpicks.
It could, however, be pointed out that the version number flag is
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 in Bitcoin block headers, as a mechanism to
> indicate a hardfork is deployed.
Disagree with treating the "ver
On Thu, Feb 4, 2016 at 5:56 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> No, the "triggering block" you mentioned is NOT where the hardfork starts.
> Using BIP101 as an example, the hardfork starts when the first >1MB is
> mined. For people who failed to upgrade, th
On Thu, Feb 04, 2016 at 12:36:06PM -0500, Gavin Andresen via bitcoin-dev wrote:
> This BIP is unnecessary, in my opinion.
>
> I'm going to take issue with items (2) and (3) that are the motivation for
> this BIP:
>
> " 2. Full nodes and SPV nodes following original consensus rules may not be
> aw
On Thu, Feb 4, 2016 at 11:56 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> past the triggering block. A block-chain re-org of two thousand or
>> more blocks on the main Bitcoin chain is unthinkable-- the economic
>> chaos would be massive, and the reaction to such a
Gavin Andresen 於 2016-02-04 12:36 寫到:
This BIP is unnecessary, in my opinion.
I'm going to take issue with items (2) and (3) that are the motivation
for this BIP:
" 2. Full nodes and SPV nodes following original consensus rules may
not be aware of the deployment of a hardfork. They may stick to
This BIP is unnecessary, in my opinion.
I'm going to take issue with items (2) and (3) that are the motivation for
this BIP:
" 2. Full nodes and SPV nodes following original consensus rules may not be
aware of the deployment of a hardfork. They may stick to an
economic-minority fork and unknowing
https://github.com/bitcoin/bips/pull/317
ABSTRACT
This document specifies a proposed change to the semantics of the sign
bit of the "version" field in Bitcoin block headers, as a mechanism to
indicate a hardfork is deployed. It alleviates certain risks related to
a hardfork by introducing an e
14 matches
Mail list logo
