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.

Post by shaolinfry via bitcoin-devSome 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 besimpler (and probably safer) to require a minimum block time spacing of say30 seconds or 1 minute, and orphan blocks that are too close in time and morethan say an hour behind real-time.

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

It *might* be a delay tactic as a 'nuclear option' attack vector for a miningcabal to run up the difficulty so high as to make it impractical to mine anynew blocks after the adjustment, but there are plenty of altcoins that havehardforked and gotten along just fine after the same kind of thing due toprofit-switching pools.

Post by shaolinfry via bitcoin-devOn 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 listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Post by shaolinfry via bitcoin-devSome people have criticized BIP9's blocktime based thresholds arguing theyare confusing (the first retarget after threshold). It is also vulnerableto miners fiddling with timestamps in a way that could prevent or delayactivation - for example by only advancing the block timestamp by 1 secondyou would never meet the threshold (although this would come a the penaltyof hiking the difficulty dramatically).On the other hand, the exact date of a height based thresholds is hard topredict 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: Havethe activation be a timestamp plus a certain number of blocks to come aftermaybe about 100, which is more than enough to make sure all the games whichcan be played with timestamps have passed but a small enough amount that itdoesn't add much uncertainty to wall clock time.

I've already opened a PR almost 2 weeks ago to do this and fix the otherissues BIP 9 has. https://github.com/bitcoin/bips/pull/550

It just needs your ACK to merge.

Post by shaolinfry via bitcoin-devSome people have criticized BIP9's blocktime based thresholds arguing theyare confusing (the first retarget after threshold). It is also vulnerableto miners fiddling with timestamps in a way that could prevent or delayactivation - for example by only advancing the block timestamp by 1 secondyou would never meet the threshold (although this would come a the penaltyof hiking the difficulty dramatically). On the other hand, the exact dateof a height based thresholds is hard to predict a long time in advance dueto difficulty fluctuations. However, there is certainty at a given blockheight and it's easy to monitor. If there is sufficient interest, I wouldbe happy to amend BIP8 to be height based. I originally omitted heightbased thresholds in the interests of simplicity of review - but now thatthe proposal has been widely reviewed it would be a trivial amendment.

It's not pointless: it's a wake-up call for miners asleep "at the wheel", toensure they upgrade in time. Not having a mandatory signal turned out to be aserious bug in BIP 9, and one which is fixed in BIP 148 (and remains a problemfor BIP 149 as-is). Additionally, it makes the activation decisive andunambiguous: once the lock-in period is complete, there remains no question asto what the correct protocol rules are.

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

Luke

Luke,I previously explored an extra state to require signalling beforeactivation in an earlier draft of BIP8, but the overall impression I gotwas that gratuitous orphaning was undesirable, so I dropped it. Iunderstand the motivation behind it (to ensure miners are upgraded), butit's also rather pointless when miners can just fake signal. A properlyconstructed soft fork is generally such that miners have to deliberatelydo something invalid - they cannot be tricked into it... and miners canalways 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/550It just needs your ACK to merge.

Some people have criticized BIP9"s blocktime based thresholds arguingthey are confusing (the first retarget after threshold). It is alsovulnerable to miners fiddling with timestamps in a way that couldprevent or delay activation - for example by only advancing the blocktimestamp by 1 second you would never meet the threshold (although thiswould come a the penalty of hiking the difficulty dramatically). On theother hand, the exact date of a height based thresholds is hard topredict a long time in advance due to difficulty fluctuations. However,there is certainty at a given block height and it"s easy to monitor. Ifthere is sufficient interest, I would be happy to amend BIP8 to beheight based. I originally omitted height based thresholds in theinterests of simplicity of review - but now that the proposal has beenwidely reviewed it would be a trivial amendment.

visible and acknowledged. Blocks without the applicable bit set are invalidduring this period

Luke, it seems like the amendments to BIP8 make it drastically different tohow it first was designed to work.It now looks more akin to BIP148, which was AFAICT not how BIP8 wasoriginally intended to work.Perhaps this should be made into its own BIP instead, or make it so it'spossible to decide how the LOCKED_IN state should work when designing thesoftfork.

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", toensure they upgrade in time. Not having a mandatory signal turned out to be aserious bug in BIP 9, and one which is fixed in BIP 148 (and remains a problemfor BIP 149 as-is). Additionally, it makes the activation decisive andunambiguous: once the lock-in period is complete, there remains no question asto what the correct protocol rules are.It also enables deploying softforks as a MASF, and only upgrading them to UASFon an as-needed basis.Luke

Luke,I previously explored an extra state to require signalling beforeactivation in an earlier draft of BIP8, but the overall impression I gotwas that gratuitous orphaning was undesirable, so I dropped it. Iunderstand the motivation behind it (to ensure miners are upgraded), butit's also rather pointless when miners can just fake signal. A properlyconstructed soft fork is generally such that miners have to deliberatelydo something invalid - they cannot be tricked into it... and miners canalways 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/550It just needs your ACK to merge.

Some people have criticized BIP9"s blocktime based thresholds arguingthey are confusing (the first retarget after threshold). It is alsovulnerable to miners fiddling with timestamps in a way that couldprevent or delay activation - for example by only advancing the blocktimestamp 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 topredict 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 beheight based. I originally omitted height based thresholds in theinterests of simplicity of review - but now that the proposal has beenwidely reviewed it would be a trivial amendment.

I'm all for using height instead of time. That was my preference forbip9 all along, but my arguments at the time apparently weren'tconvincing.

Regarding luke's proposal, the only advantage I see is that it wouldallow nodes that don't know a deployment that gets activated to issuea warning, like bip9 always does when an unknown deployment is lockedin.

But there's a simpler way to do that which doesn't require to addconsensus rules as to what versionbits should be.I'm honestly not worried about it being "coersive" and I don't thinkit's inherently reckless (although used with short deployment timeslike bip148 it can be IMO). But it adds more complexity to theconsensus 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, forexample, if the miner that mines the block right after lock in doesn'tknow about the deployment, he can't possibly know that he was supposedto signal the warning bit, even if he has the best intentions. Minerscan also intentionally not signal it out of pure malice. But that's noworse than the current form, when deployments activated by final dateinstead of miner signaling never get a warning.

Shaolinfry had more concerns with my proposed modification, but Ithink 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 reopenand rebase to simplify (#10464 was merged and there's at least 1commit to squash).

Miners must continue setting the bit in LOCKED_IN phase so uptake isvisible and acknowledged. Blocks without the applicable bit set are invalidduring this period

Luke, it seems like the amendments to BIP8 make it drastically different tohow it first was designed to work.It now looks more akin to BIP148, which was AFAICT not how BIP8 wasoriginally intended to work.Perhaps this should be made into its own BIP instead, or make it so it'spossible to decide how the LOCKED_IN state should work when designing thesoftfork.Hampus2017-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", toensure they upgrade in time. Not having a mandatory signal turned out to be aserious bug in BIP 9, and one which is fixed in BIP 148 (and remains a problemfor BIP 149 as-is). Additionally, it makes the activation decisive andunambiguous: once the lock-in period is complete, there remains no question asto what the correct protocol rules are.It also enables deploying softforks as a MASF, and only upgrading them to UASFon an as-needed basis.Luke

Luke,I previously explored an extra state to require signalling beforeactivation in an earlier draft of BIP8, but the overall impression I gotwas that gratuitous orphaning was undesirable, so I dropped it. Iunderstand the motivation behind it (to ensure miners are upgraded), butit's also rather pointless when miners can just fake signal. A properlyconstructed soft fork is generally such that miners have to deliberatelydo something invalid - they cannot be tricked into it... and miners canalways 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/550It just needs your ACK to merge.

Some people have criticized BIP9"s blocktime based thresholds arguingthey are confusing (the first retarget after threshold). It is alsovulnerable to miners fiddling with timestamps in a way that couldprevent or delay activation - for example by only advancing the blocktimestamp by 1 second you would never meet the threshold (although thiswould come a the penalty of hiking the difficulty dramatically). On theother hand, the exact date of a height based thresholds is hard topredict a long time in advance due to difficulty fluctuations. However,there is certainty at a given block height and it"s easy to monitor. Ifthere is sufficient interest, I would be happy to amend BIP8 to beheight based. I originally omitted height based thresholds in theinterests of simplicity of review - but now that the proposal has beenwidely reviewed it would be a trivial amendment.

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-devI'm all for using height instead of time. That was my preference forbip9 all along, but my arguments at the time apparently weren'tconvincing.Regarding luke's proposal, the only advantage I see is that it wouldallow nodes that don't know a deployment that gets activated to issuea warning, like bip9 always does when an unknown deployment is lockedin.But there's a simpler way to do that which doesn't require to addconsensus rules as to what versionbits should be.I'm honestly not worried about it being "coersive" and I don't thinkit's inherently reckless (although used with short deployment timeslike bip148 it can be IMO). But it adds more complexity to theconsensus 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, forexample, if the miner that mines the block right after lock in doesn'tknow about the deployment, he can't possibly know that he was supposedto signal the warning bit, even if he has the best intentions. Minerscan also intentionally not signal it out of pure malice. But that's noworse than the current form, when deployments activated by final dateinstead of miner signaling never get a warning.Shaolinfry had more concerns with my proposed modification, but Ihttps://github.com/bitcoin/bitcoin/pull/10462#issuecomment-306266218The implementation of the proposal is there too. I'm happy to reopenand rebase to simplify (#10464 was merged and there's at least 1commit to squash).

Miners must continue setting the bit in LOCKED_IN phase so uptake isvisible and acknowledged. Blocks without the applicable bit set are invalidduring this period

Luke, it seems like the amendments to BIP8 make it drastically different tohow it first was designed to work.It now looks more akin to BIP148, which was AFAICT not how BIP8 wasoriginally intended to work.Perhaps this should be made into its own BIP instead, or make it so it'spossible to decide how the LOCKED_IN state should work when designing thesoftfork.Hampus2017-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", toensure they upgrade in time. Not having a mandatory signal turned out to be aserious bug in BIP 9, and one which is fixed in BIP 148 (and remains a problemfor BIP 149 as-is). Additionally, it makes the activation decisive andunambiguous: once the lock-in period is complete, there remains no question asto what the correct protocol rules are.It also enables deploying softforks as a MASF, and only upgrading them to UASFon an as-needed basis.Luke

Luke,I previously explored an extra state to require signalling beforeactivation in an earlier draft of BIP8, but the overall impression I gotwas that gratuitous orphaning was undesirable, so I dropped it. Iunderstand the motivation behind it (to ensure miners are upgraded), butit's also rather pointless when miners can just fake signal. A properlyconstructed soft fork is generally such that miners have to deliberatelydo something invalid - they cannot be tricked into it... and miners canalways 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/550It just needs your ACK to merge.

Some people have criticized BIP9"s blocktime based thresholds arguingthey are confusing (the first retarget after threshold). It is alsovulnerable to miners fiddling with timestamps in a way that couldprevent or delay activation - for example by only advancing the blocktimestamp by 1 second you would never meet the threshold (although thiswould come a the penalty of hiking the difficulty dramatically). On theother hand, the exact date of a height based thresholds is hard topredict a long time in advance due to difficulty fluctuations. However,there is certainty at a given block height and it"s easy to monitor. Ifthere is sufficient interest, I would be happy to amend BIP8 to beheight based. I originally omitted height based thresholds in theinterests of simplicity of review - but now that the proposal has beenwidely reviewed it would be a trivial amendment.

Post by Luke Dashjr via bitcoin-devI've already opened a PR almost 2 weeks ago to do this and fix the otherissues BIP 9 has. https://github.com/bitcoin/bips/pull/550It 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 amplifyingorphaning 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 todo so at the risk of monetary losses by any and all users users fromthe resulting network instability.

It's one thing to argue that some disruption is strictly needed forthe 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 fromyour advocacy of these changes and similar activity around BIP148).

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?

I"ve already opened a PR almost 2 weeks ago to do this and fix the otherissues BIP 9 has. https://github.com/bitcoin/bips/pull/550It 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 amplifyingorphaning 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 todo so at the risk of monetary losses by any and all users users fromthe resulting network instability.It"s one thing to argue that some disruption is strictly needed forthe 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 fromyour 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 listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Post by Gregory Maxwell via bitcoin-devThese proposals for gratuitous orphaning are reckless and coersive.We have a professional obligation to first do no harm, and amplifyingorphaning 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'sdesign, and these changes are necessary for both that and keeping the networksecure. This doesn't do harm; it reduces risk of harm.

Post by Gregory Maxwell via bitcoin-devIt's one thing to argue that some disruption is strictly needed forthe 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 fromyour advocacy of these changes and similar activity around BIP148).

I don't appreciate the uncalled-for character assassination, and it doesn'tbelong on this mailing list.

Since you apparently have a drastically different opinion on this subject, Ithink 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 beobjecting to removed. Please let us know if this version is satisfactory.

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-heightBIP: https://github.com/bitcoin/bips/compare/master...shaolinfry:bip8-height

-------- Original Message --------Subject: [bitcoin-dev] Height based vs block time based thresholdsSome 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.

Post by shaolinfry via bitcoin-devI have written a height based reference implementation as well as updatedthe BIP text in the following proposals"lockinontimeout" was just an implementation detail to allow BIP8 the BIP9implementation code. With the change to height based, we can dispense withit 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-heightBIP: https://github.com/bitcoin/bips/compare/master...shaolinfry:bip8-height-------- Original Message --------Subject: [bitcoin-dev] Height based vs block time based thresholdsSome people have criticized BIP9's blocktime based thresholds arguing theyare confusing (the first retarget after threshold). It is also vulnerableto miners fiddling with timestamps in a way that could prevent or delayactivation - for example by only advancing the block timestamp by 1 secondyou would never meet the threshold (although this would come a the penaltyof hiking the difficulty dramatically).On the other hand, the exact date of a height based thresholds is hard topredict 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 beheight based. I originally omitted height based thresholds in the interestsof simplicity of review - but now that the proposal has been widelyreviewed it would be a trivial amendment._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev