[bitcoin-dev] Height based vs block time based thresholds

[bitcoin-dev] Height based vs block time based thresholds

[shaolinfry]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1106 bytes --]

Re: [bitcoin-dev] Height based vs block time based thresholds

[Troy Benjegerdes]

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

Re: [bitcoin-dev] Height based vs block time based thresholds

[Bram Cohen]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1486 bytes --]

Re: [bitcoin-dev] Height based vs block time based thresholds

[Luke Dashjr]

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.

Re: [bitcoin-dev] Height based vs block time based thresholds

[shaolinfry]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

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: luke@dashjr.org
> To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry <shaolinfry@protonmail.ch>
> 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.

[-- Attachment #2: Type: text/html, Size: 2346 bytes --]

Re: [bitcoin-dev] Height based vs block time based thresholds

[Luke Dashjr]

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: luke@dashjr.org
> > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry
> > <shaolinfry@protonmail.ch> 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.

Re: [bitcoin-dev] Height based vs block time based thresholds

[Hampus Sjöberg]

[-- Attachment #1: Type: text/plain, Size: 3462 bytes --]

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: luke@dashjr.org
> > > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry
> > > <shaolinfry@protonmail.ch> 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
>

[-- Attachment #2: Type: text/html, Size: 4745 bytes --]

Re: [bitcoin-dev] Height based vs block time based thresholds

[Jorge Timón]

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 = 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
<bitcoin-dev@lists.linuxfoundation.org> 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
> <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: luke@dashjr.org
>> > > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry
>> > > <shaolinfry@protonmail.ch> 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

[Eric Voskuil]

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 <bitcoin-dev@lists.linuxfoundation.org> 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 = 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
> <bitcoin-dev@lists.linuxfoundation.org> 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
>> <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: luke@dashjr.org
>>>>> To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry
>>>>> <shaolinfry@protonmail.ch> 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
>> 
> _______________________________________________
> 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

[Gregory Maxwell]

On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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.

Re: [bitcoin-dev] Height based vs block time based thresholds

[Kekcoin]

[-- Attachment #1: Type: text/plain, Size: 2785 bytes --]

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 <bitcoin-dev@lists.linuxfoundation.org>
> On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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

[-- Attachment #2: Type: text/html, Size: 3690 bytes --]

Re: [bitcoin-dev] Height based vs block time based thresholds

[Luke Dashjr]

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

Re: [bitcoin-dev] Height based vs block time based thresholds

[shaolinfry]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2221 bytes --]

Re: [bitcoin-dev] Height based vs block time based thresholds

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 3286 bytes --]