e the veto failed state.
>
> Code: https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip8-
> height
> BIP: https://github.com/bitcoin/bips/compare/master...
> shaolinfry:bip8-height
>
>
> ---- Original Message
> Subject: [bitcoin-dev] Height based vs bl
---
> Subject: [bitcoin-dev] Height based vs block time based thresholds
> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable to
> miners fiddling with timestamps in a way that could
On Wednesday 05 July 2017 8:06:33 AM Gregory Maxwell via bitcoin-dev wrote:
> These proposals for gratuitous orphaning are reckless and coersive.
> We have a professional obligation to first do no harm, and amplifying
> orphaning which can otherwise easily be avoided violates it.
Nothing is "orpha
Just as an implementation consideration, time basis creates complexity. There
are no other reasons to index by time, but many to index by height. The
time-based activation window of BIP9 forces nodes to either index by time or
scan the chain.
e
> On Jul 6, 2017, at 10:20 AM, Jorge Timón via bi
I'm all for using height instead of time. That was my preference for
bip9 all along, but my arguments at the time apparently weren't
convincing.
Regarding luke's proposal, the only advantage I see is that it would
allow nodes that don't know a deployment that gets activated to issue
a warning, lik
>From the PR change:
> Miners must continue setting the bit in LOCKED_IN phase so uptake is
visible and acknowledged. Blocks without the applicable bit set are invalid
during this period
Luke, it seems like the amendments to BIP8 make it drastically different to
how it first was designed to work.
be optional by default with a deferred mechanism to make it
mandatory? If so, is there any thought on how to realize the latter without the
former?
Sent with [ProtonMail](https://protonmail.com) Secure Email.
> Original Message --------
> Subject: Re: [bitcoin-dev] Height
On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
wrote:
> I've already opened a PR almost 2 weeks ago to do this and fix the other
> issues BIP 9 has. https://github.com/bitcoin/bips/pull/550
>
> It just needs your ACK to merge.
These proposals for gratuitous orphaning are reckless and
Luke,
I previously explored an extra state to require signalling before activation in
an earlier draft of BIP8, but the overall impression I got was that gratuitous
orphaning was undesirable, so I dropped it. I understand the motivation behind
it (to ensure miners are upgraded), but it's also ra
It's not pointless: it's a wake-up call for miners asleep "at the wheel", to
ensure they upgrade in time. Not having a mandatory signal turned out to be a
serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a problem
for BIP 149 as-is). Additionally, it makes the activation deci
I've already opened a PR almost 2 weeks ago to do this and fix the other
issues BIP 9 has. https://github.com/bitcoin/bips/pull/550
It just needs your ACK to merge.
On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
> Some people have criticized BIP9's blocktime based thresh
On Tue, Jul 4, 2017 at 6:30 PM, shaolinfry via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable
> to miners fiddling with timestamps i
On Tue, Jul 04, 2017 at 09:30:26PM -0400, shaolinfry via bitcoin-dev wrote:
> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable to
> miners fiddling with timestamps in a way that could prevent or
Some people have criticized BIP9's blocktime based thresholds arguing they are
confusing (the first retarget after threshold). It is also vulnerable to miners
fiddling with timestamps in a way that could prevent or delay activation - for
example by only advancing the block timestamp by 1 second
14 matches
Mail list logo