Re: [bitcoin-dev] extended BIP9 activation of segwit, for legacy nodes

From: shaolinfry <shaolinfry@protonmail•ch>
To: Ryan Grant <bitcoin-dev@rgrant•org>
Cc: "bitcoin-dev@lists•linuxfoundation.org"
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] extended BIP9 activation of segwit, for legacy nodes
Date: Fri, 14 Apr 2017 16:33:40 -0400	[thread overview]
Message-ID: <jDtJkxIBasKcUY0FNhTSazUHceUImzXe32_2D8vluCtNLWl4zk4Oi9Wo8UsA0gXHhwsfVJu0nANRnYHgUBYDYXogK0YKeBiyqn_jeUj0TC0=@protonmail.ch> (raw)
In-Reply-To: <CAMnpzfr5hLFqRm0_KWb6=N8YsD4dfQBtRBPFwfjz-EHA31d34A@mail.gmail.com>

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

You might be interested in my bip-uaversionbits proposal https://github.com/shaolinfry/bips/blob/bip-uavb/bip-uaversionbits.mediawiki

Segwit has proven more contentious to activate than anticipated
(although my read has long been that the technical consensus is clear,
despite noisy objections). No matter which method is used to
eventually activate segwit, or on what timeline, it would be
beneficial if validating nodes already capable of supporting segwit
could, without further upgrades, eventually participate to their
fullest capacity.

BIP9 assignments should reserve a backward compatibility bit which all
yet-unknown segwit-compatible proposals may utilize. These future
proposals must be consensus compatible with BIPs 141, 143, & 147,
except that they may use different deployment logic.

The motivation is so that any validating node software released after
this BIP9 assignment can eventually understand if segwit is activated
by alternate means, even when the node is itself a legacy version.
This is important because the realities of system administration on
the Bitcoin network are that upgrades occur slowly (which is inherent
in the security choice of not presenting an auto-upgrade feature).
Even though segwit in particular is backwards compatible with old
validating nodes, there are still distinct advantages to validating
and generating segregated witness transactions.

For example, future BIP9-compatible deployment attempts might
additionally include a date-dependent UASF fallback. If, either
during or after activation, deployment rules also require signaling
for segwit using the backwards-compatible bit here proposed, then
(after 95% of recent blocks signal for the alternate segwit
deployment) more legacy nodes would understand and validate
transactions using segregated witnesses.

An expiration time of five years seems conservative:

// Alternate Deployment 1 of SegWit (BIP141, BIP143, and BIP147)
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].bit = 2;
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].nStartTime
= 1510704000; // November 15th, 2017.
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].nTimeout =
1668470400; // November 15th, 2022.

Segwit deployment logic would then look like:

bool IsWitnessEnabled(const CBlockIndex* pindexPrev,
const Consensus::Params& params)
{
LOCK(cs_main);
return (VersionBitsState(pindexPrev,
params,
Consensus::DEPLOYMENT_SEGWIT,
versionbitscache)
== THRESHOLD_ACTIVE)
|| (VersionBitsState(pindexPrev,
params,
Consensus::DEPLOYMENT_SEGWIT_ALT1,
versionbitscache)
== THRESHOLD_ACTIVE);
}
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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