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

[shaolinfry via bitcoin-dev]

I have written a height based reference implementation as well as updated the 
BIP text in the following proposals

"lockinontimeout" was just an implementation detail to allow BIP8 the BIP9 
implementation code. With the change to height based, we can dispense with it 
entirely.
So the two changes BIP8 brings is BIP9 modified to use height not time, and 
remove the veto failed state.
Code: https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip8-height
BIP: https://github.com/bitcoin/bips/compare/master...shaolinfry:bip8-height

>  Original Message 
> Subject: [bitcoin-dev] Height based vs block time based thresholds
> 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

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

[shaolinfry via bitcoin-dev]

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: l...@dashjr.org
> To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry 
> <shaolin...@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] Height based vs block time based thresholds

[shaolinfry via bitcoin-dev]

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

Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?

[shaolinfry via bitcoin-dev]

I agree the date can be brought forward. FWIW, I originally set the date far 
out enough that people wouldn't immediately fixate on the date and rather look 
at the meat of the proposal instead.

Given that we saw around 70% of nodes upgrade to BIP141 in around 5/6 months, I 
dont see any reason why we cant reduce the date to being 6 months or less from 
Nov. Given people are starving for segwit to the point of running BIP148, there 
is good evidence the community will upgrade in record time to BIP149.

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

 Original Message 

Based on how fast we saw segwit adoption, why is the BIP149 timeout so
far in the future?

It seems to me that it could be six months after release and hit the
kind of density required to make a stable transition.

(If it were a different proposal and not segwit where we already have
seen what network penetration looks like-- that would be another
matter.)
___
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] Barry Silbert segwit agreement

[shaolinfry via bitcoin-dev]

Someone sent me a copy of the Barry Silbert agreement, an agreement forged 
between a select number of participants https://pastebin.com/VuCYteJh

Participants agree to immediately activate Segwit, however, under a different 
activation proposal. Since I have spent the last few months researching various 
activation strategies of the current BIP141 deployment, as well as 
redeployment, I feel I am quite well placed to comment on the technicalities.

To be clear, the proposal as far as I can see does not activate BIP141, but is 
a completely new deployment which would be incompatible with the BIP141 
deployment. I'm not sure how that can be considered "immediate" activation. 
Surely immediate activation would just be for miners to start signalling and 
segwit would be activated in 4-5 weeks. The proposal seems to require a lower 
80% threshold, I assume because they were unable to convince 95% of the 
hashpower to go trigger activation.

There are a few options to activating segwit now, the first being for 95% of 
hashrate to signal. The second is for the community to deploy BIP148 UASF which 
will force miners to signal segwit. Being a UASF it is date triggered. The 
third option is a redeployment of segwit on a new bit, but requires waiting for 
the existing deployment to time out, because all the p2p messages and service 
bits related to segwit must be replaced too (which is what BIP149 does).

A fourth option, first suggested to me by James Hilliard, was to make BIP148 
miner triggered (MASF) with a lower threshold, above 50%. I coded this up a few 
weeks ago 
https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:segsignal but 
didnt get around to posting to the ML yet. This effectively lowers the 
threshold from 95% to 65% as coded, or could be upped to 80% or whatever was 
preferable.

I think this removes the primary risk of BIP148 causing the creation of two 
chains, and gives an improved chance to get segwit activated quickly (assuming 
a majority of miners wish to go this route). But hash a primary disadvantage of 
still leaving the activation in the hands of miners. If it doesn't work out, 
then BIP149 can then be used as proposed, but it'll be even safer because we'll 
have futher guaged support.

References:

SEGSIGNAL: 
https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:segsignal
BIP148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
BIP149: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki

I think the Barry Silbert agreement is very ill considered, and clearly lacking 
peer review from the technical community. Suggestions of a HF in 4 months are 
completely unrealistic and without technical merits. But more importantly, 
closed door agreements between selected participants is not how to garner 
consensus to change a $30bn decentralized system. The purpose of my email is to 
try and assist in the "immediate activation of segwit" which only requires 
hashrate to participate; and to provide some techincal input since I have done 
a great deal of research and development into the topic.

Given the history we've already passed the point where we should be expecting 
miners to cooperate in lowering their own fee income with a capacity increase; 
but we should be open to all reasonable options in the interest in moving 
things forward in a safe and collaborative way.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Draft BIP: Segwit deployment with versionbits and guaranteed lock-in

[shaolinfry via bitcoin-dev]

This is a draft BIP proposal to redeploy segwit using BIP-8, from the day after 
the current BIP9 segwit times out.

This BIP could be deployed long before Nov 15th 2016, for example in July 
allowing wide deployment to begin soon. The timeout (and this useractivation) 
could be set to roughly a year from then. However, considering around 70% of 
nodes upgraded to witness capability within 5-6 months, I personally think we 
could reduce the time, especially considering how much people want segwit - but 
I understand the need for more caution in Bitcoin.

Preliminary dates are deploy within a couple months, startdate Nov 16th 2017, 
BIP8 timeout July 4th 2018.


BIP: ?
Layer: Consensus (soft fork)
Title: Segwit deployment with versionbits and guaranteed lock-in
Author: Shaolin Fry 
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
Status: Draft
Type: Standards Track
Created: 2017-04-14
License: BSD-3-Clause
CC0-1.0


==Abstract==

This document specifies a user activated soft fork for BIP141, BIP143 and 
BIP147 using versionbits with guaranteed lock-in.

==Motivation==

Miners have been reluctant to signal the BIP9 segwit deployment despite a large 
portion of the Bitcoin ecosystem who want the soft fork activated. This BIP 
specifies a user activated soft fork (UASF) that deploys segwit again using 
versionbits with guaranteed lock-in on timeout if the BIP is not already 
locked-in or activated by the timeout. This ensures users have sufficient time 
to prepare and no longer require a miner supermajority, while still allowing 
for an earlier miner activated soft fork (MASF).

==Reference implementation==

https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday

==Specification==

This deployment will set service bit (1<<5) as NODE_UAWITNESS.

==Deployment==

This BIP will be deployed by BIP8 with the name "uasegwit" and using bit 2.

For Bitcoin mainnet, the BIP8 starttime will be midnight 16 November 2017 UTC 
(Epoch timestamp 1510790400) and BIP8 timeout will be 4 July 2018 UTC (Epoch 
timestamp 1530662400).

For Bitcoin testnet, segwit is already activated so no deployment is specified.

==Rationale==

This BIP can be deployed well in advance of the BIP8 '''starttime''' so that 
the '''timeout''' will be sufficiently far in the future to allow Bitcoin users 
to uprgade in preparation.

The '''starttime''' of this BIP is after the BIP9 "segwit" timeout to remove 
compatibility issues with old nodes.

==References==

https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki

==Copyright==

This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 
Universal.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[shaolinfry via bitcoin-dev]

Dear Greg,

Thank you for taking the time to review the BIP148 proposal.

I agree with much of your thoughts. I originally started working on a 
generalized way to deploy user activated soft forks, in a way that leveraged 
BIP9 to allow for optional faster MASF activation. BIP148 came about as a way 
to satify many people's frustrations about the current segwit activation. I 
have said several times in various places that the proposal requires a very 
high amount of consensus that needs to be present to make actual deployment 
feasible. BIP148 is certainly not what a normal UASF would or should look like.

I remain convinced the community very much wants segwit activated and that the 
UASF movement in general has gained a lot of traction. While support for BIP148 
is surprisingly high, there are definitely important players who support UASF 
in general but do not like BIP148 approach (which you rightly point out is a 
UASF to force a MASF).

In any case, I have been working on various iterations for generalized 
deployment of soft forks. My latest iteration adds a simple flag to a BIP9 
deployment so the deployment will transition to LOCKED_IN at timeout if the 
deployment hasnt already activated or locked in by then. This is nice because 
it allows for a long deployment of a soft fork, giving the ecosystem plenty 
time to upgrade with an effective flagday at the end of the timeout. The hash 
power can still optionally activate earlier under MASF.

BIP8 (was uaversionbits) can be seen here 
https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki

With BIP8 we could perform a UASF segwit deployment. Due to some complexities 
in the peering logic, I recommend a new deployment with a fresh bit that starts 
right after November 15th (when BIP9 segwit timesout) with a BIP8 timeout for 
April 2018. The code can deployed much earlier. For example if code was 
deployed today, it would give the economy a year to upgrade. Activation could 
still occur safely by MASF any time from now until April 2018 (SEGWIT until 
Nov, then UASEGWIT from Nov until April 2018).

I am still working on the finer implementation details, but you can see a rough 
draft from this diff (which includes BIP8 in the first commit, and the proposed 
bip-segwit-uasf in the second commit).

https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday

I believe this approach would satisfy the more measured approach expected for 
Bitcoin and does not have the issues you brought up about BIP148.

I do not support the BIP148 UASF for some of the same reasons that I
do support segwit: Bitcoin is valuable in part because it has high
security and stability, segwit was carefully designed to support and
amplify that engineering integrity that people can count on now and
into the future.

I do not feel the the approach proposed in BIP148 really measures up
to the standard set by segwit itself, or the existing best practices
in protocol development in this community.

The primary flaw in BIP148 is that by forcing the activation of the
existing (non-UASF segwit) nodes it almost guarantees at a minor level
of disruption.

Segwit was carefully engineered so that older unmodified miners could
continue operating _completely_ without interruption after segwit
activates.

Older nodes will not include segwit spends, and so their blocks will
not be invalid even if they do not have segwit support. They can
upgrade to it on their own schedule. The only risk non-participating
miners take after segwit activation is that if someone else mines an
invalid block they would extend it, a risk many miners already
frequently take with spy-mining.

I do not think it is a horrible proposal: it is better engineered than
many things that many altcoins do, but just not up to our normal
standards. I respect the motivations of the authors of BIP 148. If
your goal is the fastest possible segwit activation then it is very
useful to exploit the >80% of existing nodes that already support the
original version of segwit.

But the fastest support should not be our goal, as a community-- there
is always some reckless altcoin or centralized system that can support
something faster than we can-- trying to match that would only erode
our distinguishing value in being well engineered and stable.

"First do no harm." We should use the least disruptive mechanisms
available, and the BIP148 proposal does not meet that test. To hear
some people-- non-developers on reddit and such-- a few even see the
forced orphaning of 148 as a virtue, that it's punitive for
misbehaving miners. I could not not disagree with that perspective any
more strongly.

Of course, I do not oppose the general concept of a UASF but
_generally_ a soft-fork (of any kind) does not need to risk disruption
of mining, just as segwit's activation does not. UASF are the
original kind of soft-fork and were the only kind of fork practiced by
Satoshi. P2SH was activated based on a date, and all prior ones were

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

[shaolinfry via bitcoin-dev]

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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in

[shaolinfry via bitcoin-dev]

After some thought I managed to simplify the original uaversionbits proposal 
introducing a simple boolean flag to guarantee lock-in of a BIP9 deployment by 
the timeout. This seems to be the simplest form combining optional flag day 
activation with BIP9. This brings the best of both worlds allowing user 
activated soft forks that can be activated early by the hash power.

Specification: 
https://github.com/shaolinfry/bips/blob/bip-uavb/bip-uaversionbits.mediawiki
Previous discussion: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html


BIP: ?
Title: Version bits extension with guaranteed lock-in
Author: Shaolin Fry 
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
Status: Draft
Type: Informational
Created: 2017-02-01
License: BSD-3-Clause
CC0-1.0


==Abstract==

This document specifies an extension to BIP9 that introduces an additional 
activation parameter to guarantee activation of backward-compatible changes 
(further called "soft forks").

==Motivation==

BIP9 introduced a mechanism for doing parallel soft forking deployments based 
on repurposing the block nVersion field. Activation is dependent on near 
unanimous hashrate signalling which may be impractical and is also subject to 
veto by a small minority of non-signalling hashrate.

This specification provides a way to optionally guarantee lock-in at the end of 
the BIP9 timeout, and therefore activation.

==Specification==

This specification adds a new per-chain deployment parameter to the existing 
BIP9 specification as follows:

# The '''lockinontimeout''' boolean if set to true, will transition state to 
LOCKED_IN at timeout if not already ACTIVE.

===State transitions===



The state transition workflow is exactly the same as in BIP9 with an additional 
rule: During the STARTED state if the '''lockinontimeout''' is set to true, the 
state will transition to LOCKED_IN when '''timeout''' is reached.

case STARTED:
// BIP9 specification follows
if (GetMedianTimePast(block.parent) >= timeout) {
return (fLockInOnTimeout == true) ? THRESHOLD_LOCKED_IN : THRESHOLD_FAILED
}
int count = 0;
walk = block;
for (i = 0; i < 2016; i++) {
walk = walk.parent;
if (walk.nVersion & 0xE000 == 0x2000 && (walk.nVersion >> bit) & 1 == 
1) {
count++;
}
}
if (count >= threshold) {
return LOCKED_IN;
}
return STARTED;

=== Reference implementation ===

https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits

==Deployments==

A living list of deployment proposals can be found 
[[bip-0009/assignments.mediawiki|here]].

==Copyright==

This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 
Universal.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Flag day activation of segwit

[shaolinfry via bitcoin-dev]

Fundamentally, what you have described is not a UASF, it is a miner attack on 
other miners. 51% of hash power has always been able to collude to orphan 
blocks that contain transactions they have blacklisted (a censorship soft 
fork). This is clearly a miner attack which would escalate pretty rapidly into 
a PoW change if sustained for any time.

Miners have always retained the ability to include whatever valid transactions 
they like. If they don't like P2SH or segwit, they don't have to include them 
in their blocks. There is a clear difference between opting out of transaction 
selection vs miners attacking other miners to prevent their voluntary 
participation in mining valid transactions.

Of course, anything is possible, but game theory and incentives seem to suggest 
that any tantrums would be at most, short lived, if lived at all. Mining is an 
extraordinarily expensive endeavour, which is the basis of the strong 
assumption of Bitcoin that PoW/revenue incentives will keep miners honest. If 
that assumption is broken, Bitcoin has bigger problems.


 Original Message 
Subject: Re: [bitcoin-dev] Flag day activation of segwit
From: nickodell



The problem with modifying Bitcoin to work around community norms is that it's 
a two-way street. Other people can do it too.

Let me propose a counter-fork, or a "Double UASF." This is also a BIP9 fork, 
and it uses, say, bit 2. starttime is 1489449600, and the end time is 
1506812400. It enforces every rule that UASF enforces, plus one additional 
rule. If 60% of blocks in any retargeting period signal for Double UASF, any 
descendant block that creates or spends a segregated witness output is invalid.

Double UASF signaling never coincides with UASF signaling, because the 
signaling periods don't overlap. Full nodes happily validate the chain, because 
Double UASF doesn't break any rules; it just adds new ones. Miners who adopt 
Double UASF don't need to understand segwit, because all segwit transactions 
are banned. Miners don't need to commit to a wtxid structure, either. Per BIP 
141, "If all transactions in a block do not have witness data, the commitment 
is optional." Segwit is activated, but useless. Miners who *do* adopt segwit 
will lose money, as their blocks are orphaned.

Thanks,
--Nick



On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> wrote:

I recently posted about so called "user activated soft forks" and received a 
lot of feedback. Much of this was how such methodologies could be applied to 
segwit which appears to have fallen under the miner veto category I explained 
in my original proposal, where there is apparently a lot of support for the 
proposal from the economy, but a few mining pools are vetoing the activation.

It turns out Bitcoin already used flag day activation for 
P2SH[[1](https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283)],
 a soft fork which is remarkably similar to segwit. The disadvantage of a UASF 
for segwit is there is an existing deployment. A UASF would require another 
wide upgrade cycle (from what I can see, around 80% of existing nodes have 
upgraded from pre-witness, to NODE_WITNESS 
capability[[2](http://luke.dashjr.org/programs/bitcoin/files/charts/services.html)][[3](https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/)].
 While absolute node count is meaningless, the uprgrade trend from version to 
version seems significant.

Also it is quite clear a substantial portion of the ecosystem industry has put 
in time and resources into segwit adoption, in the form of upgrading wallet 
code, updating libraries and various other integration work that requires 
significant time and money. Further more, others have built systems that rely 
on segwit, having put significant engineering resources into developing systems 
that require segwit - such as several lightning network system. This is much 
more significant social proof than running a node.

The delayed activation of segwit is also holding back a raft protocol of 
innovations such as MAST, Covenants, Schnorr signature schemes and signature 
aggregation and other script innovations of which, much of the development work 
is already done.

A better option would be to release code that causes the existing segwit 
deployment to activate without requiring a completely new deployment nor 
subject to hash power veto. This could be achieved if the economic majority 
agree to run code that rejects non-signalling segwit blocks. Then from the 
perspective of all existing witness nodes, miners trigger the BIP9 activation. 
Such a rule could come into effect 4-6 weeks before the BIP9 timeout. If a 
large part of the economic majority publicly say that they will adopt this new 
client, miners will have to signal bip9 segwit activation in order for their 
blocks to be valid.

I have drafted a BIP proposal

Re: [bitcoin-dev] Flag day activation of segwit

[shaolinfry via bitcoin-dev]

From: l...@dashjr.org
On Sunday, March 12, 2017 3:50:27 PM shaolinfry via bitcoin-dev wrote:
> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017
> inclusive if (pindex->GetMedianTimePast() >= 1538352000 &&
> pindex->GetMedianTimePast() <= 1510704000 &&
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
> if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params,
> Consensus::DEPLOYMENT_SEGWIT)) != 0) {
> return state.DoS(2, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID,
> "bad-no-segwit");
> }
> }

I don't think this is actually BIP 9 compatible. Once activated, the bit loses
its meaning and should not be set. So you need to check that it hasn't locked-
in already...

I believe that is handled.

time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()

Signalling is only required from October 1st until the BIP9 timeout, or, until 
segwit is activated. The bit becomes free after activation/timeout as per BIP9. 
Also, the default behaviour of BIP9 in Bitcoin Core is to signal through the 
LOCKED_IN period - it would be trivial to add a condition to not require 
mandatory signalling during LOCKED_IN but since miners signal by default during 
this period, I figured I would leave it.

I thought about 5% tolerance. but I don't think it makes sense since miners 
will already have plenty of warning this is coming up and the intent of the 
mandatory signalling period is quite clear. It also seems a bit weird to say 
"it's mandatory but not for 5%". If miners are required to signal, they need to 
signal. It also adds unnecessary complexity to an otherwise simple patch.

That said, I have no strong feelings either way on both counts, but I chose to 
present the simplest option first.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Flag day activation of segwit

[shaolinfry via bitcoin-dev]

Before setting a flag day, I think we should get written cooperation agreements 
from the largest economic players in Bitcoin. This would include:

There isn't a flag day to set. If the major economic organs like exchanges run 
the BIP, non-signalling miners simply wont get paid (starting October 1st) and 
their blocks will be rejected. Miners will have the choice to signal, or find 
something else profitable to mine. In turn, this will trigger the existing 
segwit deployment for everyone who has already upgraded to segwit compatible 
node software (currently Bitcoin Core 0.13.1, 0.13.2, 0.14.0, Bitcoin Knots 
0.13.1+, and bcoin) regardless of whether they run this BIP or not.

But yes, it goes without saying that this BIP would need to have buy-in from 
major economic organs, especially fiat egress points, before being deployed. 
Failing that, a second deployment of segwit with a flag day, or preferably 
using the bip-uaversionbits-strong BIP9/flagday hybrid would be required.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Flag day activation of segwit

[shaolinfry via bitcoin-dev]

I recently posted about so called "user activated soft forks" and received a 
lot of feedback. Much of this was how such methodologies could be applied to 
segwit which appears to have fallen under the miner veto category I explained 
in my original proposal, where there is apparently a lot of support for the 
proposal from the economy, but a few mining pools are vetoing the activation.

It turns out Bitcoin already used flag day activation for 
P2SH[[1](https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283)],
 a soft fork which is remarkably similar to segwit. The disadvantage of a UASF 
for segwit is there is an existing deployment. A UASF would require another 
wide upgrade cycle (from what I can see, around 80% of existing nodes have 
upgraded from pre-witness, to NODE_WITNESS 
capability[[2](http://luke.dashjr.org/programs/bitcoin/files/charts/services.html)][[3](https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/)].
 While absolute node count is meaningless, the uprgrade trend from version to 
version seems significant.

Also it is quite clear a substantial portion of the ecosystem industry has put 
in time and resources into segwit adoption, in the form of upgrading wallet 
code, updating libraries and various other integration work that requires 
significant time and money. Further more, others have built systems that rely 
on segwit, having put significant engineering resources into developing systems 
that require segwit - such as several lightning network system. This is much 
more significant social proof than running a node.

The delayed activation of segwit is also holding back a raft protocol of 
innovations such as MAST, Covenants, Schnorr signature schemes and signature 
aggregation and other script innovations of which, much of the development work 
is already done.

A better option would be to release code that causes the existing segwit 
deployment to activate without requiring a completely new deployment nor 
subject to hash power veto. This could be achieved if the economic majority 
agree to run code that rejects non-signalling segwit blocks. Then from the 
perspective of all existing witness nodes, miners trigger the BIP9 activation. 
Such a rule could come into effect 4-6 weeks before the BIP9 timeout. If a 
large part of the economic majority publicly say that they will adopt this new 
client, miners will have to signal bip9 segwit activation in order for their 
blocks to be valid.

I have drafted a BIP proposal so the community may discuss 
https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full text 
below).

References:
[1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
[2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html
[3]: 
https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/

Proposal text:

 BIP: bip-segwit-flagday Title: Flag day activation for segwit deployment 
Author: Shaolin Fry  Comments-Summary: No comments 
yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP- 
Status: Draft Type: Informational Created: 2017-03-12 License: BSD-3-Clause 
CC0-1.0  ==Abstract== This document specifies a BIP16 like soft fork flag 
day activation of the segregated witness BIP9 deployment known as "segwit". 
==Definitions== "existing segwit deployment" refer to the BIP9 "segwit" 
deployment using bit 1, between November 15th 2016 and November 15th 2017 to 
activate BIP141, BIP143 and BIP147. ==Motivation== Cause the mandatory 
activation of the existing segwit deployment before the end of midnight 
November 15th 2017. ==Specification== All times are specified according to 
median past time. This BIP will be activate between midnight October 1st 2017 
(epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) 
if the existing segwit deployment is not activated before epoch time 
1538352000. This BIP will cease to be active when the existing segwit 
deployment activates. While this BIP is active, all blocks must set the 
nVersion header top 3 bits to 001 together with bit field (1<<1) (according to 
the existing segwit deployment). Blocks that do not signal as required will be 
rejected. === Reference implementation ===  // mandatory segwit activation 
between Oct 1st 2017 and Nov 15th 2017 inclusive if 
(pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 
1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) { 
if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && 
(pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYMENT_SEGWIT)) != 
0) { return state.DoS(2, error("ConnectBlock(): relayed block must signal for 
segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit"); } }  
==Backwards Compatibility== This deployment is compatible with the existing 
"segwit" bit 1 

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[shaolinfry via bitcoin-dev]

Thank you all for the insightful feedback, on list, in private and on various 
social media platforms. I have extended the generalized proposal which extends 
BIP9. This basically introduces an extra workflow state if activationtime > 
starttime and < timeout - 1 month. It allows extra business logic to be added, 
such as requiring mandatory signalling.

Please find the draft here:

https://gist.github.com/shaolinfry/70d0582db7de958b7d5b6422cfef4e22

 BIP: bip-uaversionbits-strong Title: Version bits extension with 
mandatory activation Author: Shaolin Fry  
Comments-Summary: No comments yet. Comments-URI: 
https://github.com/bitcoin/bips/wiki/Comments:BIP- Status: Draft Type: 
Informational Created: 2017-03-09 License: BSD-3-Clause CC0-1.0  
==Abstract== This document specifies an extension to BIP9 that introduces an 
additional activation parameter to deploy backward-compatible changes (further 
called "soft forks") to be activated by a deadline. ==Motivation== BIP9 
introduced a mechanism for doing parallel soft forking deployments based on 
repurposing the block nVersion field. Activation is dependent on near unanimous 
hashrate signalling which may be impractical and is also subject to veto by a 
small minority of non-signalling hashrate. This specification provides an way 
for full nodes to coordinate syncronized activation based on a median past time 
using the BIP9 state machine. Hashrate may optionally trigger activation before 
the user defined activation sequence triggers. ==Specification== This 
specification adds a new per-chain deployment parameter to the existing BIP9 
specification as follows: # The '''activationtime''' specifies a minimum median 
time past of a block at which the deployment should transition to the locked-in 
state. This specification adds a new workflow state, '''PRE_LOCK_IN''' to the 
BIP9 state machine if the deployment '''activationtime''' is greater than zero 
when the workflow will be '''DEFINED''' -> '''STARTED''' -> '''PRE_LOCK_IN''' 
-> '''LOCKED_IN''' -> '''ACTIVE'''. The '''PRE_LOCK_IN''' phase allows optional 
per deployment processing, e.g. mandatory signalling. ===Selection 
guidelines=== The following guidelines are suggested for selecting these 
parameters for a soft fork: # '''activationtime''' should be set to some date 
in the future and must be less than the BIP9 '''timeout'''. It is recommended 
to have an activation time of 1 year minus 30 days (28944000 seconds). The 
'''activationtime''' cannot be less than 30 days before the '''timeout'''. 
===State transitions=== The state transition workflow is exactly the same as in 
BIP9 except when '''activationtime''' is greater than zero. Then the workflow 
will be '''DEFINED''' -> '''STARTED''' -> '''PRE_LOCK_IN''' -> '''LOCKED_IN''' 
-> '''ACTIVE'''. When in the STARTED state if the median time past is greater 
than or equal to the '''activationtime''' then the state will transition to 
PRE_LOCK_IN on the next retarget after '''activationtime'''. case STARTED: // 
Transition to THRESHOLD_PRE_LOCK_IN if mandatory activation is set if 
((nActivationTime != 0) && pindexPrev->GetMedianTimePast() >= nActivationTime) 
{ stateNext = THRESHOLD_PRE_LOCK_IN; break; } // BIP9 specification follows if 
(GetMedianTimePast(block.parent) >= timeout) { return FAILED; } int count = 0; 
walk = block; for (i = 0; i < 2016; i++) { walk = walk.parent; if 
(walk.nVersion & 0xE000 == 0x2000 && (walk.nVersion >> bit) & 1 == 1) { 
count++; } } if (count >= threshold) { return LOCKED_IN; } return STARTED; === 
Reference implementation === 
https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits-strong
  Optional mandatory signalling   /** * Return true if nVersion 
BIP9 deployment is signalling during * mandatory periods. */ bool 
IsMandatorySignalling(int32_t nVersion, Consensus::DeploymentPos pos, const 
CBlockIndex* pindexPrev, const Consensus::Params& params) { // Check the 
deployment is in the correct state for this check to apply. if 
(!((VersionBitsState(pindexPrev, params, pos, versionbitscache) == 
THRESHOLD_PRE_LOCK_IN) || (VersionBitsState(pindexPrev, params, pos, 
versionbitscache) == THRESHOLD_LOCKED_IN))) return true; // return signalling 
state return (((nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && 
(nVersion & VersionBitsMask(params, pos)) != 0); } // segwit signalling is 
mandatory during PRE_LOCK_IN and LOCKED_IN phase if 
(!IsMandatorySignalling(block.nVersion, Consensus::DEPLOYMENT_EXAMPLE, 
pindexPrev, consensusParams)) return state.Invalid(false, REJECT_OBSOLETE, 
strprintf("bad-version(0x%08x)", block.nVersion), strprintf("rejected 
nVersion=0x%08x block, must upgrade", block.nVersion));  ==Deployments== 
A living list of deployment proposals can be found 
[[bip-0009/assignments.mediawiki|here]]. ==Copyright== This document is placed 
in the public domain.___
bitcoin-dev mailing 

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[shaolinfry via bitcoin-dev]

my text, that the 
decision to deploy a soft fork (regardless of the activation method) is based 
on a reasonable expectation that users will make use of the new feature. 
Hashrate signalling is not a vote, but a coordination trigger. Soft forks are 
backwards compatible and opt-in; so long as they are well written and bug free, 
users should at worst, be agnostic towards them because they have a choice 
whether to safely use the new feature or not, without preventing others' 
enjoyment of the feature. A controversial or unreasonable soft fork would not 
gain traction and I believe it would be fairly self evident.

In short, I do expect wide ecosystem collaboration as part of any deployment 
strategy, both hashrate or flag day based.

Many thanks for taking the time to read over and consider my thoughts and 
proposal. I would be happy to discuss more if you have any further questions or 
suggestions.



- Jameson



On Sat, Feb 25, 2017 at 6:55 PM, shaolinfry via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> wrote:

Some thoughts about the activation mechanism for soft forks. In the past we 
used IsSuperMajority and currently use BIP9 as soft fork activation methods, 
where a supermajority of hashrate triggers nodes to begin enforcing new rules. 
Hashrate based activation is convenient because it is the simplest and most 
straightforward process. While convenient there are a number limitations with 
this method.

Firstly, it requires trusting the hash power will validate after activation. 
The BIP66 soft fork was a case where 95% of the hashrate was signaling 
readiness but in reality about half was not actually validating the upgraded 
rules and mined upon an invalid block by mistake[1].

Secondly, miner signalling has a natural veto which allows a small percentage 
of hashrate to veto node activation of the upgrade for everyone. To date, soft 
forks have taken advantage of the relatively centralised mining landscape where 
there are relatively few mining pools building valid blocks; as we move towards 
more hashrate decentralization, it's likely that we will suffer more and more 
from "upgrade inertia" which will veto most upgrades.

Upgrade inertia in inevitable for widely deployed software and can be seen for 
example, with Microsoft Windows. At the time of writing 5.72% of all Microsoft 
Windows installations are still running Windows XP, despite mainstream support 
ending in 2009 and being superseded by 4 software generations, Vista, 7, 8 and 
10.

Thirdly, the signaling methodology is widely misinterpreted to mean the hash 
power is voting on a proposal and it seems difficult to correct this 
misunderstanding in the wider community. The hash powers' role is to select 
valid transactions, and to extend the blockchain with valid blocks. Fully 
validating economic nodes ensure that blocks are valid. Nodes therefore define 
validity according to the software they run, but miners decide what already 
valid transactions gets included in the block chain.

As such, soft forks rules are actually always enforced by the nodes, not the 
miners. Miners of course can opt-out by simply not including transactions that 
use the new soft fork feature, but they cannot produce blocks that are invalid 
to the soft fork. The P2SH soft fork is a good example of this, where 
non-upgraded miners would see P2SH as spendable without a signature and 
consider them valid. If such an transaction were to be included in a block, the 
block would be invalid and the miner would lose the block reward and fees.

So-called "censorship" soft forks do not require nodes to opt in, because >51% 
of the hash power already have the ability to orphan blocks that contain 
transactions they have blacklisted. Since this is not a change in validity, 
nodes will accept the censored block chain automatically.

The fourth problem with supermajority hash power signaling is it draws 
unnecessary attention to miners which can become unnecessarily political. 
Already misunderstood as a vote, miners may feel pressure to "make a decision" 
on behalf of the community: who is and isn't signalling becomes a huge public 
focus and may put pressures onto miners they are unprepared for. Some miners 
may not be in a position to upgrade, or may prefer not to participate in the 
soft fork which is their right. However, that miner may now become a lone 
reason that vetoes activation for everyone, where the soft fork is an opt-in 
feature! This situation seems to be against the voluntary nature of the Bitcoin 
system where participation at all levels is voluntary and kept honest by well 
balanced incentives.

Since miners already have the protocol level right to select whatever 
transaction they prefer (and not mine those they don't), it would be better if 
a miner could chose to not participate in triggering activation of something 
they won't use, but, without being a veto to the process (and all the ire they 
may have 

[bitcoin-dev] Moving towards user activated soft fork activation

[shaolinfry via bitcoin-dev]

Some thoughts about the activation mechanism for soft forks. In the past we 
used IsSuperMajority and currently use BIP9 as soft fork activation methods, 
where a supermajority of hashrate triggers nodes to begin enforcing new rules. 
Hashrate based activation is convenient because it is the simplest and most 
straightforward process. While convenient there are a number limitations with 
this method.

Firstly, it requires trusting the hash power will validate after activation. 
The BIP66 soft fork was a case where 95% of the hashrate was signaling 
readiness but in reality about half was not actually validating the upgraded 
rules and mined upon an invalid block by mistake[1].

Secondly, miner signalling has a natural veto which allows a small percentage 
of hashrate to veto node activation of the upgrade for everyone. To date, soft 
forks have taken advantage of the relatively centralised mining landscape where 
there are relatively few mining pools building valid blocks; as we move towards 
more hashrate decentralization, it's likely that we will suffer more and more 
from "upgrade inertia" which will veto most upgrades.

Upgrade inertia in inevitable for widely deployed software and can be seen for 
example, with Microsoft Windows. At the time of writing 5.72% of all Microsoft 
Windows installations are still running Windows XP, despite mainstream support 
ending in 2009 and being superseded by 4 software generations, Vista, 7, 8 and 
10.

Thirdly, the signaling methodology is widely misinterpreted to mean the hash 
power is voting on a proposal and it seems difficult to correct this 
misunderstanding in the wider community. The hash powers' role is to select 
valid transactions, and to extend the blockchain with valid blocks. Fully 
validating economic nodes ensure that blocks are valid. Nodes therefore define 
validity according to the software they run, but miners decide what already 
valid transactions gets included in the block chain.

As such, soft forks rules are actually always enforced by the nodes, not the 
miners. Miners of course can opt-out by simply not including transactions that 
use the new soft fork feature, but they cannot produce blocks that are invalid 
to the soft fork. The P2SH soft fork is a good example of this, where 
non-upgraded miners would see P2SH as spendable without a signature and 
consider them valid. If such an transaction were to be included in a block, the 
block would be invalid and the miner would lose the block reward and fees.

So-called "censorship" soft forks do not require nodes to opt in, because >51% 
of the hash power already have the ability to orphan blocks that contain 
transactions they have blacklisted. Since this is not a change in validity, 
nodes will accept the censored block chain automatically.

The fourth problem with supermajority hash power signaling is it draws 
unnecessary attention to miners which can become unnecessarily political. 
Already misunderstood as a vote, miners may feel pressure to "make a decision" 
on behalf of the community: who is and isn't signalling becomes a huge public 
focus and may put pressures onto miners they are unprepared for. Some miners 
may not be in a position to upgrade, or may prefer not to participate in the 
soft fork which is their right. However, that miner may now become a lone 
reason that vetoes activation for everyone, where the soft fork is an opt-in 
feature! This situation seems to be against the voluntary nature of the Bitcoin 
system where participation at all levels is voluntary and kept honest by well 
balanced incentives.

Since miners already have the protocol level right to select whatever 
transaction they prefer (and not mine those they don't), it would be better if 
a miner could chose to not participate in triggering activation of something 
they won't use, but, without being a veto to the process (and all the ire they 
may have to experience as a consequence).

The alternative discussed here is "flag day activation" where nodes begin 
enforcement at a predetermined time in the future. This method needs a longer 
lead time than a hash power based activation trigger, but offers a number of 
advantages and perhaps provides a better tradeoff.

Soft forks are still entirely optional to use post activation. For example, 
with P2SH, many participants in the Bitcoin ecosystem still do not use P2SH. 
Only 11% of bitcoins[2] are stored in P2SH addresses at the time of writing. 
Miners are free to not mine P2SH transactions, however, the incentives are such 
that miners should still validate transactions so they don't accidentally 
include invalid transactions and cause their block to be rejected. As an 
additional safety measure for well designed soft forks, relay policy rules 
prevent non-standard and invalid transactions from being relayed and mined by 
default; a miner would have to purposefully mine an invalid transaction, which 
is against their own economic interest.

Since the