public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: "Jorge Timón" <jtimon@jtimon.cc>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Height based vs block time based thresholds
Date: Thu, 6 Jul 2017 10:41:52 -0700	[thread overview]
Message-ID: <3248E9A6-F729-4EC2-85F7-E18FD9CA15F8@voskuil.org> (raw)
In-Reply-To: <CABm2gDo0CdyXJkpMJ7dL82xJ0LuNSq6H7sHCC8Yt9RamvhF1YQ@mail.gmail.com>

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


  reply	other threads:[~2017-07-06 17:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-05  1:30 [bitcoin-dev] Height based vs block time based thresholds shaolinfry
2017-07-05  2:25 ` Troy Benjegerdes
2017-07-05  3:39 ` Bram Cohen
2017-07-05  3:50 ` Luke Dashjr
2017-07-05  4:00   ` shaolinfry
2017-07-05  4:10     ` Luke Dashjr
2017-07-05 19:44       ` Hampus Sjöberg
2017-07-06 17:20         ` Jorge Timón
2017-07-06 17:41           ` Eric Voskuil [this message]
2017-07-05  8:06   ` Gregory Maxwell
2017-07-05  8:54     ` Kekcoin
2017-07-06 20:43     ` Luke Dashjr
2017-07-07  5:52 ` shaolinfry
2017-07-07  9:51   ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3248E9A6-F729-4EC2-85F7-E18FD9CA15F8@voskuil.org \
    --to=eric@voskuil.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jtimon@jtimon.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox