public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2017-04-14 20:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-14 20:12 [bitcoin-dev] extended BIP9 activation of segwit, for legacy nodes Ryan Grant
2017-04-14 20:33 ` shaolinfry [this message]
2017-06-11 19:31 ` Ryan Grant

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='jDtJkxIBasKcUY0FNhTSazUHceUImzXe32_2D8vluCtNLWl4zk4Oi9Wo8UsA0gXHhwsfVJu0nANRnYHgUBYDYXogK0YKeBiyqn_jeUj0TC0=@protonmail.ch' \
    --to=shaolinfry@protonmail.ch \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=bitcoin-dev@rgrant.org \
    /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