Discussion:
Height based vs block time based thresholds
Add Reply
shaolinfry via bitcoin-dev
2017-07-05 01:30:26 UTC
Reply
Permalink
Raw Message
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 you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically).
On the other hand, the exact date of a height based thresholds is hard to predict a long time in advance due to difficulty fluctuations. However, there is certainty at a given block height and it's easy to monitor.
If there is sufficient interest, I would be happy to amend BIP8 to be height based. I originally omitted height based thresholds in the interests of simplicity of review - but now that the proposal has been widely reviewed it would be a trivial amendment.
Troy Benjegerdes via bitcoin-dev
2017-07-05 02:25:33 UTC
Reply
Permalink
Raw Message
Post by shaolinfry via bitcoin-dev
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 you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically).
If there are miners that start doing 1 second timestamp advances, it would be
simpler (and probably safer) to require a minimum block time spacing of say
30 seconds or 1 minute, and orphan blocks that are too close in time and more
than say an hour behind real-time.

I cannot picture any realistic scenario in which an attempt to block activation
in this way is in anything other than a very expensive temper tantrum for any
miners foolish enough to attempt it.

It *might* be a delay tactic as a 'nuclear option' attack vector for a mining
cabal to run up the difficulty so high as to make it impractical to mine any
new blocks after the adjustment, but there are plenty of altcoins that have
hardforked and gotten along just fine after the same kind of thing due to
profit-switching pools.
Post by shaolinfry via bitcoin-dev
On the other hand, the exact date of a height based thresholds is hard to predict a long time in advance due to difficulty fluctuations. However, there is certainty at a given block height and it's easy to monitor.
If there is sufficient interest, I would be happy to amend BIP8 to be height based. I originally omitted height based thresholds in the interests of simplicity of review - but now that the proposal has been widely reviewed it would be a trivial amendment.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Bram Cohen via bitcoin-dev
2017-07-05 03:39:09 UTC
Reply
Permalink
Raw Message
On Tue, Jul 4, 2017 at 6:30 PM, shaolinfry via bitcoin-dev <
Post by shaolinfry via bitcoin-dev
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
you would never meet the threshold (although this would come a the penalty
of hiking the difficulty dramatically).
On the other hand, the exact date of a height based thresholds is hard to
predict a long time in advance due to difficulty fluctuations. However,
there is certainty at a given block height and it's easy to monitor.
You could get most of the best of both with a combination of the two: Have
the activation be a timestamp plus a certain number of blocks to come after
maybe about 100, which is more than enough to make sure all the games which
can be played with timestamps have passed but a small enough amount that it
doesn't add much uncertainty to wall clock time.
Luke Dashjr via bitcoin-dev
2017-07-05 03:50:51 UTC
Reply
Permalink
Raw Message
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.
Post by shaolinfry via bitcoin-dev
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
you would never meet the threshold (although this would come a the penalty
of hiking the difficulty dramatically). On the other hand, the exact date
of a height based thresholds is hard to predict a long time in advance due
to difficulty fluctuations. However, there is certainty at a given block
height and it's easy to monitor. If there is sufficient interest, I would
be happy to amend BIP8 to be height based. I originally omitted height
based thresholds in the interests of simplicity of review - but now that
the proposal has been widely reviewed it would be a trivial amendment.
Luke Dashjr via bitcoin-dev
2017-07-05 04:10:43 UTC
Reply
Permalink
Raw Message
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 decisive and
unambiguous: once the lock-in period is complete, there remains no question as
to what the correct protocol rules are.

It also enables deploying softforks as a MASF, and only upgrading them to UASF
on an as-needed basis.

Luke
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 rather pointless when miners can just fake signal. A properly
constructed soft fork is generally such that miners have to deliberately
do something invalid - they cannot be tricked into it... and miners can
always chose to do something invalid anyway.
-------- Original Message --------
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.
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 you would never meet the threshold (although this
would come a the penalty of hiking the difficulty dramatically). On the
other hand, the exact date of a height based thresholds is hard to
predict a long time in advance due to difficulty fluctuations. However,
there is certainty at a given block height and it"s easy to monitor. If
there is sufficient interest, I would be happy to amend BIP8 to be
height based. I originally omitted height based thresholds in the
interests of simplicity of review - but now that the proposal has been
widely reviewed it would be a trivial amendment.
Hampus Sjöberg via bitcoin-dev
2017-07-05 19:44:27 UTC
Reply
Permalink
Raw Message
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.
It now looks more akin to BIP148, which was AFAICT not how BIP8 was
originally intended to work.
Perhaps this should be made into its own BIP instead, or make it so it's
possible to decide how the LOCKED_IN state should work when designing the
softfork.

Hampus

2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev <
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 decisive and
unambiguous: once the lock-in period is complete, there remains no question as
to what the correct protocol rules are.
It also enables deploying softforks as a MASF, and only upgrading them to UASF
on an as-needed basis.
Luke
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 rather pointless when miners can just fake signal. A properly
constructed soft fork is generally such that miners have to deliberately
do something invalid - they cannot be tricked into it... and miners can
always chose to do something invalid anyway.
-------- Original Message --------
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.
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 you would never meet the threshold (although
this
would come a the penalty of hiking the difficulty dramatically). On
the
other hand, the exact date of a height based thresholds is hard to
predict a long time in advance due to difficulty fluctuations.
However,
there is certainty at a given block height and it"s easy to monitor.
If
there is sufficient interest, I would be happy to amend BIP8 to be
height based. I originally omitted height based thresholds in the
interests of simplicity of review - but now that the proposal has been
widely reviewed it would be a trivial amendment.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jorge Timón via bitcoin-dev
2017-07-06 17:20:47 UTC
Reply
Permalink
Raw Message
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, like bip9 always does when an unknown deployment is locked
in.

But there's a simpler way to do that which doesn't require to add
consensus rules as to what versionbits should be.
I'm honestly not worried about it being "coersive" and I don't think
it's inherently reckless (although used with short deployment times
like bip148 it can be IMO). But it adds more complexity to the
consensus rules, with something that could merely be "warning code".

You can just use a special bit in versionbits for nodes to get the warning.
My proposal doesn't guarantee that the warning will be signaled, for
example, if the miner that mines the block right after lock in doesn't
know about the deployment, he can't possibly know that he was supposed
to signal the warning bit, even if he has the best intentions. Miners
can also intentionally not signal it out of pure malice. But that's no
worse than the current form, when deployments activated by final date
instead of miner signaling never get a warning.

Shaolinfry had more concerns with my proposed modification, but I
think I answered all of them here:

https://github.com/bitcoin/bitcoin/pull/10462#issuecomment-306266218

The implementation of the proposal is there too. I'm happy to reopen
and rebase to simplify (#10464 was merged and there's at least 1
commit to squash).
Post by Luke Dashjr via bitcoin-dev
It also enables deploying softforks as a MASF, and only upgrading them to UASF
on an as-needed basis.

You can also do

consensus.vDeployments[Consensus::DEPLOYMENT_MASF].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nStartHeight = 500000;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight = 510000;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].lockinontimeout = false;

and "if needed", simply add the following at any time (before the new
nStartHeight, obviously):


consensus.vDeployments[Consensus::DEPLOYMENT_UASF].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nStartHeight = 510000;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nTimeoutHeight = 515000;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].lockinontimeout = true;


On Wed, Jul 5, 2017 at 9:44 PM, Hampus Sjöberg via bitcoin-dev
Post by Luke Dashjr via bitcoin-dev
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.
It now looks more akin to BIP148, which was AFAICT not how BIP8 was
originally intended to work.
Perhaps this should be made into its own BIP instead, or make it so it's
possible to decide how the LOCKED_IN state should work when designing the
softfork.
Hampus
2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev
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 decisive and
unambiguous: once the lock-in period is complete, there remains no question as
to what the correct protocol rules are.
It also enables deploying softforks as a MASF, and only upgrading them to UASF
on an as-needed basis.
Luke
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 rather pointless when miners can just fake signal. A properly
constructed soft fork is generally such that miners have to deliberately
do something invalid - they cannot be tricked into it... and miners can
always chose to do something invalid anyway.
-------- Original Message --------
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.
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 you would never meet the threshold (although this
would come a the penalty of hiking the difficulty dramatically). On the
other hand, the exact date of a height based thresholds is hard to
predict a long time in advance due to difficulty fluctuations. However,
there is certainty at a given block height and it"s easy to monitor. If
there is sufficient interest, I would be happy to amend BIP8 to be
height based. I originally omitted height based thresholds in the
interests of simplicity of review - but now that the proposal has been
widely reviewed it would be a trivial amendment.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Eric Voskuil via bitcoin-dev
2017-07-06 17:41:52 UTC
Reply
Permalink
Raw Message
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
Post by Jorge Timón via bitcoin-dev
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, like bip9 always does when an unknown deployment is locked
in.
But there's a simpler way to do that which doesn't require to add
consensus rules as to what versionbits should be.
I'm honestly not worried about it being "coersive" and I don't think
it's inherently reckless (although used with short deployment times
like bip148 it can be IMO). But it adds more complexity to the
consensus rules, with something that could merely be "warning code".
You can just use a special bit in versionbits for nodes to get the warning.
My proposal doesn't guarantee that the warning will be signaled, for
example, if the miner that mines the block right after lock in doesn't
know about the deployment, he can't possibly know that he was supposed
to signal the warning bit, even if he has the best intentions. Miners
can also intentionally not signal it out of pure malice. But that's no
worse than the current form, when deployments activated by final date
instead of miner signaling never get a warning.
Shaolinfry had more concerns with my proposed modification, but I
https://github.com/bitcoin/bitcoin/pull/10462#issuecomment-306266218
The implementation of the proposal is there too. I'm happy to reopen
and rebase to simplify (#10464 was merged and there's at least 1
commit to squash).
Post by Luke Dashjr via bitcoin-dev
It also enables deploying softforks as a MASF, and only upgrading them to UASF
on an as-needed basis.
You can also do
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nStartHeight = 500000;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight = 510000;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].lockinontimeout = false;
and "if needed", simply add the following at any time (before the new
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nStartHeight = 510000;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nTimeoutHeight = 515000;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].lockinontimeout = true;
On Wed, Jul 5, 2017 at 9:44 PM, Hampus Sjöberg via bitcoin-dev
Post by Luke Dashjr via bitcoin-dev
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.
It now looks more akin to BIP148, which was AFAICT not how BIP8 was
originally intended to work.
Perhaps this should be made into its own BIP instead, or make it so it's
possible to decide how the LOCKED_IN state should work when designing the
softfork.
Hampus
2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev
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 decisive and
unambiguous: once the lock-in period is complete, there remains no question as
to what the correct protocol rules are.
It also enables deploying softforks as a MASF, and only upgrading them to UASF
on an as-needed basis.
Luke
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 rather pointless when miners can just fake signal. A properly
constructed soft fork is generally such that miners have to deliberately
do something invalid - they cannot be tricked into it... and miners can
always chose to do something invalid anyway.
-------- Original Message --------
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.
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 you would never meet the threshold (although this
would come a the penalty of hiking the difficulty dramatically). On the
other hand, the exact date of a height based thresholds is hard to
predict a long time in advance due to difficulty fluctuations. However,
there is certainty at a given block height and it"s easy to monitor. If
there is sufficient interest, I would be happy to amend BIP8 to be
height based. I originally omitted height based thresholds in the
interests of simplicity of review - but now that the proposal has been
widely reviewed it would be a trivial amendment.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Gregory Maxwell via bitcoin-dev
2017-07-05 08:06:33 UTC
Reply
Permalink
Raw Message
On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
Post by Luke Dashjr via bitcoin-dev
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 coersive.
We have a professional obligation to first do no harm, and amplifying
orphaning which can otherwise easily be avoided violates it.

It is not anyones position to decide who does and doesn't need to be
"woken up" with avoidable finical harm, nor is it any of our right to
do so at the risk of monetary losses by any and all users users from
the resulting network instability.

It's one thing to argue that some disruption is strictly needed for
the sake of advancement, it's another to see yourself fit as judge,
jury, and executioner to any that does not jump at your command.
(which is exactly the tone I and at least some others extract from
your advocacy of these changes and similar activity around BIP148).

I for one oppose those changes strongly.
Post by Luke Dashjr via bitcoin-dev
Not having a mandatory signal turned out to be a serious bug in BIP 9,
I have seen no evidence or case for this.
Kekcoin via bitcoin-dev
2017-07-05 08:54:40 UTC
Reply
Permalink
Raw Message
Luke's proposed changes to BIP8 (specifically, the FAILING state) seem designed to address the regression compared to BIP9 that there is no way to avoid activating a softfork that is shown to be suboptimal or flawed in some (serious enough) way - after deployment is well underway - without hardforking.
I agree with your principle but we should also look at the circumstances in which this mechanism would be beneficial vs. when it would cause harm (compared to BIP8 without this mechanism). The scenario this was designed for is "miners refusing to activate, on non-technical grounds, a widely desired upgrade" - in which case the "wakeup call" would be in users' hands, not anyone in particular.
Is there a hypothetical scenario in which the orphan risk outweighs the benefits of having this kind of upgrade mechanism that can (at deploy-time) be chosen to 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 based vs block time based thresholds
Local Time: July 5, 2017 8:06 AM
UTC Time: July 5, 2017 8:06 AM
On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
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 coersive.
We have a professional obligation to first do no harm, and amplifying
orphaning which can otherwise easily be avoided violates it.
It is not anyones position to decide who does and doesn"t need to be
"woken up" with avoidable finical harm, nor is it any of our right to
do so at the risk of monetary losses by any and all users users from
the resulting network instability.
It"s one thing to argue that some disruption is strictly needed for
the sake of advancement, it"s another to see yourself fit as judge,
jury, and executioner to any that does not jump at your command.
(which is exactly the tone I and at least some others extract from
your advocacy of these changes and similar activity around BIP148).
I for one oppose those changes strongly.
Not having a mandatory signal turned out to be a serious bug in BIP 9,
I have seen no evidence or case for this.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Luke Dashjr via bitcoin-dev
2017-07-06 20:43:28 UTC
Reply
Permalink
Raw Message
Post by Gregory Maxwell via bitcoin-dev
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 "orphaned" unless miners are acting negligently or maliciously.
Incentivising honest behaviour from miners is inherently part of Bitcoin's
design, and these changes are necessary for both that and keeping the network
secure. This doesn't do harm; it reduces risk of harm.
Post by Gregory Maxwell via bitcoin-dev
It's one thing to argue that some disruption is strictly needed for
the sake of advancement, it's another to see yourself fit as judge,
jury, and executioner to any that does not jump at your command.
(which is exactly the tone I and at least some others extract from
your advocacy of these changes and similar activity around BIP148).
I don't appreciate the uncalled-for character assassination, and it doesn't
belong on this mailing list.
Post by Gregory Maxwell via bitcoin-dev
I for one oppose those changes strongly.
Post by Luke Dashjr via bitcoin-dev
Not having a mandatory signal turned out to be a serious bug in BIP 9,
I have seen no evidence or case for this.
Since you apparently have a drastically different opinion on this subject, I
think it may be best to wait until after BIP148 to continue the discussion
(thereby having more real-world information to work from).

Therefore, I have opened a new pull request with just the parts you seem to be
objecting to removed. Please let us know if this version is satisfactory.

https://github.com/bitcoin/bips/pull/551

Luke
shaolinfry via bitcoin-dev
2017-07-07 05:52:13 UTC
Reply
Permalink
Raw Message
I have written a height based reference implementation as well as updated the BIP text in the following proposals

"lockinontimeout" was just an implementation detail to allow BIP8 the BIP9 implementation code. With the change to height based, we can dispense with it entirely.
So the two changes BIP8 brings is BIP9 modified to use height not time, and remove 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 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 prevent or delay activation - for example by only advancing the block timestamp by 1 second you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically).
On the other hand, the exact date of a height based thresholds is hard to predict a long time in advance due to difficulty fluctuations. However, there is certainty at a given block height and it's easy to monitor.
If there is sufficient interest, I would be happy to amend BIP8 to be height based. I originally omitted height based thresholds in the interests of simplicity of review - but now that the proposal has been widely reviewed it would be a trivial amendment.
Jorge Timón via bitcoin-dev
2017-07-07 09:51:16 UTC
Reply
Permalink
Raw Message
What if you want height based but lockinontimeout = false ?

On 7 Jul 2017 8:09 am, "shaolinfry via bitcoin-dev" <
Post by shaolinfry via bitcoin-dev
I have written a height based reference implementation as well as updated
the BIP text in the following proposals
"lockinontimeout" was just an implementation detail to allow BIP8 the BIP9
implementation code. With the change to height based, we can dispense with
it entirely.
So the two changes BIP8 brings is BIP9 modified to use height not time,
and remove 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 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 prevent or delay
activation - for example by only advancing the block timestamp by 1 second
you would never meet the threshold (although this would come a the penalty
of hiking the difficulty dramatically).
On the other hand, the exact date of a height based thresholds is hard to
predict a long time in advance due to difficulty fluctuations. However,
there is certainty at a given block height and it's easy to monitor.
If there is sufficient interest, I would be happy to amend BIP8 to be
height based. I originally omitted height based thresholds in the interests
of simplicity of review - but now that the proposal has been widely
reviewed it would be a trivial amendment.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Loading...