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

[shaolinfry <shaolinfry@protonmail.ch>]

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