path: root/4b/edfab952939acaab6c8775adea7017b7beb2fe

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 20474A7F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Jul 2017 17:41:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f53.google.com (mail-pg0-f53.google.com [74.125.83.53])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 277DE178
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Jul 2017 17:41:56 +0000 (UTC)
Received: by mail-pg0-f53.google.com with SMTP id u62so4307182pgb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 06 Jul 2017 10:41:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=Tjlz/w/EgVvfccGECqmPp8qPcQ4FOXjU8sJKLgEtEkM=;
	b=OcYgJ+BD1s5+UD3yFDoR4JQ+bDnXWa3TdBml7OPZGzUIAbpMCU1EPwwI93aFEuD/p7
	av3yjYCppt8q64xCJ9zcfOxMLY24+glnLjvXigSn09zc0fXT8OcGmWs8GALwraIlYRNL
	3MuZyplwAujM6+QrwoHyqKttpHA9Pk2NEu8Ye4N9gSrkRmL/xsHq+6jDY5hMIEZ0VZxo
	8UFOglTBiSDQvgMsxHRn63iuIbSr5jePfNAp8p8m/BcjGvl9ajvi0AJb4kY/RBJSaNVn
	Q0r9sRkw50N+5O68evXkKJKIGx1JIsSVNN17Vqj6Xtmeg4xGCiqtsyVrxIZFVs/319XH
	prOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=Tjlz/w/EgVvfccGECqmPp8qPcQ4FOXjU8sJKLgEtEkM=;
	b=fmFKlzpQadd9WJdrNFclMzSt0X91e3vNC7ViXv8FWEIFCUl3Iv++1K13p3MksFC7in
	Tpp1ot/jmbahJkmDZEVM1mw1tny/W/AyAhiLGgFLR40CKXHtN4sosbrzxupAQn6ZOEmm
	smOdPohIqc2x/ZBIIrIjIQWHbQdt/7BPsiNJdMw8UvtBKmnOpHWmOg0TT9mQsXzbpIdT
	b1tlbOXvixi0/S38X+lFRmOyAFW0s65J64qtRrxkaG6ZFnzT23MtWsUSX5hMUT3kH90w
	J2DVY5FMH9YrFckiCKytx6L67/yZ73O1jshCif8j7AQan370I08HjElQZoNEz7IDJjw6
	IZKg==
X-Gm-Message-State: AIVw111MfDfzPMEJ+rV9+qQ9RqwQmB9ezD3R63LheylJtG/TM+16oJ5g
	8/SKt93ery5hIVdvdcYprg==
X-Received: by 10.99.104.10 with SMTP id d10mr25815007pgc.186.1499362915383;
	Thu, 06 Jul 2017 10:41:55 -0700 (PDT)
Received: from ?IPv6:2600:380:8070:6d94:786a:6c9a:2dec:2bf1?
	([2600:380:8070:6d94:786a:6c9a:2dec:2bf1])
	by smtp.gmail.com with ESMTPSA id
	q67sm1553049pfi.81.2017.07.06.10.41.53
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 06 Jul 2017 10:41:53 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (14F89)
In-Reply-To: <CABm2gDo0CdyXJkpMJ7dL82xJ0LuNSq6H7sHCC8Yt9RamvhF1YQ@mail.gmail.com>
Date: Thu, 6 Jul 2017 10:41:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <3248E9A6-F729-4EC2-85F7-E18FD9CA15F8@voskuil.org>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
	<201707050350.53122.luke@dashjr.org>
	<00qcLaDJFDoC9D6644P_aLf7_n5B1pqCPj_c02QlqySsrJLsB6TZipXMD8L7l3lJcw5NoLP6dphCMruKJCIMkJUIDYbIw0iDd322vsNFmNw=@protonmail.ch>
	<201707050410.45217.luke@dashjr.org>
	<CAFMkqK9ezq_AdOpeA08jpr9haHP_jEHaJaQ2KZC=yMy6UXaJyA@mail.gmail.com>
	<CABm2gDo0CdyXJkpMJ7dL82xJ0LuNSq6H7sHCC8Yt9RamvhF1YQ@mail.gmail.com>
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, MIME_QP_LONG_LINE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 06 Jul 2017 17:54:20 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Height based vs block time based thresholds
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jul 2017 17:41:57 -0000

Just as an implementation consideration, time basis creates complexity. Ther=
e are no other reasons to index by time, but many to index by height. The ti=
me-based activation window of BIP9 forces nodes to either index by time or s=
can the chain.

e

> On Jul 6, 2017, at 10:20 AM, Jorge Tim=C3=B3n via bitcoin-dev <bitcoin-dev=
@lists.linuxfoundation.org> wrote:
>=20
> 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.
>=20
> 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.
>=20
> 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".
>=20
> 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.
>=20
> Shaolinfry had more concerns with my proposed modification, but I
> think I answered all of them here:
>=20
> https://github.com/bitcoin/bitcoin/pull/10462#issuecomment-306266218
>=20
> 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).
>=20
>> It also enables deploying softforks as a MASF, and only upgrading them to=
 UASF
> on an as-needed basis.
>=20
> You can also do
>=20
> consensus.vDeployments[Consensus::DEPLOYMENT_MASF].bit =3D 0;
> consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nStartHeight =3D 500000=
;
> consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight =3D 5100=
00;
> consensus.vDeployments[Consensus::DEPLOYMENT_MASF].lockinontimeout =3D fal=
se;
>=20
> and "if needed", simply add the following at any time (before the new
> nStartHeight, obviously):
>=20
>=20
> consensus.vDeployments[Consensus::DEPLOYMENT_UASF].bit =3D 0;
> consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nStartHeight =3D 510000=
;
> consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nTimeoutHeight =3D 5150=
00;
> consensus.vDeployments[Consensus::DEPLOYMENT_UASF].lockinontimeout =3D tru=
e;
>=20
>=20
> On Wed, Jul 5, 2017 at 9:44 PM, Hampus Sj=C3=B6berg via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> =46rom the PR change:
>>=20
>>> Miners must continue setting the bit in LOCKED_IN phase so uptake is
>>> visible and acknowledged. Blocks without the applicable bit set are inva=
lid
>>> during this period
>>=20
>> Luke, it seems like the amendments to BIP8 make it drastically different t=
o
>> 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.
>>=20
>> Hampus
>>=20
>> 2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org>:
>>>=20
>>> 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.
>>>=20
>>> It also enables deploying softforks as a MASF, and only upgrading them t=
o
>>> UASF
>>> on an as-needed basis.
>>>=20
>>> Luke
>>>=20
>>>=20
>>>> 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 go=
t
>>>> was that gratuitous orphaning was undesirable, so I dropped it. I
>>>> understand the motivation behind it (to ensure miners are upgraded), bu=
t
>>>> it's also rather pointless when miners can just fake signal. A properly=

>>>> constructed soft fork is generally such that miners have to deliberatel=
y
>>>> do something invalid - they cannot be tricked into it... and miners can=

>>>> always chose to do something invalid anyway.
>>>>=20
>>>>> -------- 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.
>>>>>=20
>>>>>> 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
>>=20
>>=20
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev