Re: [bitcoin-dev] Height based vs block time based thresholds
What if you want height based but lockinontimeout = false ? On 7 Jul 2017 8:09 am, "shaolinfry via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Height based vs block time based thresholds
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 bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Height based vs block time based thresholds
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 "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. > 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. > 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. 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Height based vs block time based thresholds
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 bitcoin-dev > wrote: > > 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). > >> 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 = 50; > consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight = 51; > 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 = 51; > 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 > wrote: >> 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. >> 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 >>> >>> On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote: 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 > From: l...@dashjr.org > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry >
Re: [bitcoin-dev] Height based vs block time based thresholds
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). > 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 = 50; consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight = 51; 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 = 51; 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 wrote: > 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. > 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 >> >> >> On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote: >> > 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 >> > > From: l...@dashjr.org >> > > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry >> > > 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 thresholds arguing >> > >> they are confusing (the first retarget after threshold). It is also >> > >> vulnerable to miners fiddling with timestamps in
Re: [bitcoin-dev] Height based vs block time based thresholds
>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. 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 < bitcoin-dev@lists.linuxfoundation.org>: > 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 > > > On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote: > > 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 > > > From: l...@dashjr.org > > > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry > > > 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 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 > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Height based vs block time based thresholds
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 > From: bitcoin-dev@lists.linuxfoundation.org > To: Bitcoin Dev > 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 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 > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Height based vs block time based thresholds
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 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 bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Height based vs block time based thresholds
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 > From: l...@dashjr.org > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry > > 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 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 bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Height based vs block time based thresholds
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 On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote: > 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 > > From: l...@dashjr.org > > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry > > 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 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 bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Height based vs block time based thresholds
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 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 bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Height based vs block time based thresholds
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 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Height based vs block time based thresholds
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 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. > 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 > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
