bip-segwit-flagday.mediawiki

This has been moved to https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

I suggest allocating a protocol service bit for indicating implementation of this BIP, so that metrics about deployment can be obtained by network crawlers.

This approach seems like it has ample potential to go really badly. It needs extremely broad support in order to succeed. The level of risk deters support, and insufficient support further compounds the risk if we decide to proceed anyway.

I'll try to enumerate the possible outcomes:

1. Recalcitrant miners are so intimidated by this display of saber-rattling that they immediately begin signalling for segwit, which activates soon after. Resentment grows, and conspiracy theorists start to sound more reasonable. Low-cost success
2. All miners refuse to adopt mandatory segwit (mansegwit?).
   1. Few nodes adopted mansegwit, so the rest of the network experiences mild disruption to block propagation, if any. Mansegwit nodes are unable to participate in the network until they give up. Segwit advocates look like foolish extremists, and lose credibility. Low-cost failure
   2. A majority of nodes adopted mansegwit, so the network experiences major disruptions and most business grinds to a halt. Miners hold out, selling their coins over the counter until nodes give up. Price of bitcoin plummets, marking the beginning of a new bear market. Bitcoin Unlimited faction gains the upper hand. Costly failure
   3. Same as 2.ii., but nodes hold out until miners give up. New bear market, but we've got segwit. Costly success
3. Mansegwit is adopted by 51%+ of miners. Non-segwit miners have their blocks orphaned from October 1st until segwit activates, or until they give in and start signalling for segwit. Low-cost success
4. Mansegwit is adopted by a majority of economic nodes, but by a minority of miners. On October 1st, the blockchain splits, with mansegwit miners and nodes on one side. The other side consists of optional segwit (optsegwit, continuing the theme) and nonsegwit miners and nodes.
   1. Transaction throughput is significantly slowed at first due to the drop in hashrate. Optsegwit and nonsegwit miners are unable to sell their mined coins to pay their expenses, and soon give in. Some transactions on the nonsegwit chain disappear, and the recipients are pissed, but most people refrained from transacting during the fork. Low-cost success
   2. Optsegwit and nonsegwit miners hold out for a long time. Transaction throughput is significantly slowed, and difficulty adjustment and segwit activation take months.
      1. Optsegwit and nonsegwit miners gradually give in. Nonsegwit side of the fork evaporates, and people are out for blood because of it. Bitcoin Unlimited faction gains the upper hand, but we get to keep segwit. Costly success
      2. Optsegwit and nonsegwit miners hold out indefinitely. Bitcoin remains split into two currencies, both of them a sad mockery of what once was. Crypto-currencies are deemed non-viable by the general public for decades afterwards. CATASTROPHIC FAILURE

There's no need to rush this. If segwit fails to activate by the deadline, we can try again with a lower activation threshold. If Bitcoin Unlimited manages to activate in the meantime, things will be chaotic, but it'll ultimately fail. The economic majority is a lot stronger when resisting change than when imposing it. Let's not turn this into a race to see who can destroy Bitcoin first.

@maaku Good idea. Thank you. We can just use a service bit until the final timeout/activation.

Thinking about this some more:

GetMedianTimePast() is used for both the segwit activation criteria and this BIP's block validity criteria, rather than block height. Doesn't that set us up to potentially cause a permanent chain split and fail to activate segwit on our side if not enough mining power adopts this? If we end up with 10% hash power, we'll only find about 600 blocks between October 1st and November 15th; not enough to activate segwit.

I'm not a Bitcoin dev, so let me know if there's some major detail I'm missing, or if I'm otherwise not being helpful here.

Why are you using a non-zero DoS score? It's low, but it breaks in the established convention of setting DoS scores (10 for txs, 100 for blocks when a node should have, according to its own rules, not broken the relay). It seems there could be a potential network partition vulnerability here if the majority hashpower permanently rejects the fork (and some nodes continue relaying their blocks). With regards to network safety I would at the very least do one of:

• Rigorously reasoning about why a partition is impossible, in the BIP.
• Justifying the desirability of a partition and making it clear in the proposal.
• Set the DoS penalty to 0 for relaying non-compliant blocks (this seems reasonable because relaying these blocks is old nodes' honest/default behavior, and the check is cheap)

Overall though I do not like this proposal, I think it amounts to a hard fork w.r.t. the safety of its deployment as I've explained in the UASF section here: https://pdaian.com/blog/on-soft-fork-security/ , and is essentially codifying a network attack as a BIP (a very dangerous precedent to set in any event).

A partition is obviously possible in adversarial scenarios. I think that much is perfectly clear. ACK of this proposal would simply imply ACK of that strategy as an alternative to never being able to move forward.

However there must be contingency planning for the possible scenario of being left as the minority chain in hashing power for a long period. That would require drastic measures.

A partition is obviously possible in adversarial scenarios.

Aren't all scenarios we're concerned with here adversarial scenarios?

ACK of this proposal would simply imply ACK of that strategy as an alternative to never being able to move forward.

Then a strong NACK from me. Network partitions violate fundamental security assumptions in Bitcoin. A potential partition's interaction with miner attacks, malicious reorgs, and other adversarial strategies that have been analyzed in the ecosystem in the past is unstudied.

Not only that, but the proposal is created with absolutely no mention of this, or warning that "ACK of this proposal would simply imply ACK of [a potential partitioning vector]".

If you want to propose something of this sort (a completely new type of fork proposal), you need to study the risks and mechanism of this partition, and simulate or reason about adversarial scenarios far beyond what this proposal has provided.

Or just change the DoS score to 0, which removes the partitioning vector without (as far as I can tell) significantly negatively affecting the operation of the code beyond some resource exhaustion vectors.

Preferred peers would be a better strategy than this for dealing with such resource exhaustion.

This proposal is incomplete and (IMO) insecure as written.

I have to agree with @pdaian that the non-zero DoS score makes little sense and greatly increases risk. Network partitions should be avoided at any reasonable cost.

Blah political or not, not a good place to post this yet and most people looking at UASF will come here so posting my thoughts on this here:
I prefer an uncomplicated method that has been used before, rather than relying purely on signally intent. The act of voting publically when certain parties have to much power is being used as way to politically attack Bitcoin, and impend it to move forward. Hence, this has lead to the use of propaganda, fear, and gridlock with code that is nowhere near ready for production to cause damage due to relying only on miner voting which has never been nor will it ever be Bitcoin strong point.

Innovation has always come from need, and never from backing. Backing follows the lead of something that takes lead. Based on all of my knowledge, skills, and my experience in watching and using bitcoin my opinion is Segwit is they way forward and we need to take some action. At this point the damage of a change split is already happening both politically and economically. Upgrading will allow for so many types of new code and development to take place. This provides huge economic boost in Bitcoins

As soon as there is code available for flag day or something that pushes Segwit forward, I will support that in every way I can and I imagine most users will to as it allows bitcoin to move forward in terms of scalability and in terms of innovation of the network itself.

"Activation of segwit is defined by BIP9. After 15 Nov 2016 and before 15 Nov 2017 UTC, if in a full retarget cycle at least 1916 out of 2016 blocks is signaling readiness, segwit will be activated in the retarget cycle after the next one"

Just change BIP9 and the code to say "if in a full retarget cycle at least 1 out of 2016 blocks" and call it done. Wasting too much time on this.

EDIT: I mean modify the code to say: "If last block of last retarget cycle before 15 Nov 2017 has at least 1 block signalling SegWit, then activate it. Otherwise for other retarget cycle blocks in the Nov 2016-2017 range, use the 1916 threshold."

Second Edit: just hard code to activate SegWit via BIP9's process at 15 Nov 2017 or Oct 1st or whenever... no matter the number of blocks signalling support. Then no orphaning by us is guaranteed and we don't imply that miner say matters.

Editing again: So then BIP9 just becomes a way to activate SegWit before 15 Nov 2017, and: default activates it at the end, instead of currently it default just throws SegWit out

@praxeology-guy With that approach we'd end up with a chain split at some unknown point in the future, and 0.13.2/0.14.0 nodes would never activate segwit. I think it's probably better to know when the chain split is going to happen, so that the miners don't get complacent about it.

@chrisacheson

I appreciate your feedback. What are the different options and possibilities of what could happen?

1. If we UASF via orphaning blocks, then we are causing the fork to happen, unless they are ok with getting orphaned. If they are not ok with getting orphaned, and decide to fork due to our action in this manner, then I feel like we'd be responsible for the fork, and we would have to implement the replay attack protection. But yes then we would know exactly when the fork would happen. And orphaning their blocks could be considered a kind of rude way to go about the fork, when my proposal or other date-activating UASF proposals are possible.

2. Sure its true that with a soft fork you cannot know when or if a chain split will ever happen... especially when they are threatening to fork/refusing to adopt our soft fork. It is foolish for us to wait for miners to adopt policy change when they are refusing not by reason of merit, instead to strong arm. Without > 50% hash power a split is more likely yes.

3. The other option is maybe we can convince them to activate SegWit in the future. That does not seem likely to me. At least not in a reasonable time frame.

Uh... are there any other options?

===========

Let me go more into detail of what could happen if we adopt my UASF proposal:

1. Chain split due to Unlimited nodes actively rejecting SegWit blocks?
   That's a conflicting soft fork. I'm perfectly happy w/ them doing such. Sooner they fork the better.

2. Chain split due to someone making an invalid SegWit block, and then non-upgrading nodes mining on it? They would have to chose to:
   A. Pre-filter their blocks by connecting to their own instance of a SegWit node
   B. Upgrade
   C. Manually enter in checkpoints
   D. Fork. I'm perfectly happy w/ them doing such. Sooner they fork the better.

Pretty sure they would pretty rapidly do A or B in preparation for activation. Maybe some lazy people would do C/fail to do A/B and then scramble to do them. That's just a temporary problem for them where they waste some resources.

============

The strategy to strong-arm-delay-SegWit is long term ineffective in accomplishing their goal (which comprises our goal). I'm not going to compromise on bitcoin's distributed nature (end user synchronization). SegWit is good and we should activate it. Its a bluff for them to act like they won't accept SegWit. They will. Lets call them on it, 15 Nov 2017.

I don't really care about the short term economic consequences of their decision to perform a: conflicting soft fork/hard fork/build on invalid segwit block fork. It will just be fools losing money, temporary price variance. Long term we need to keep on making good policy changes and upgrades to bitcoin so that we can have better money... and as long as we are in overwhelming agreeing on a feature being good: sooner rather than later.

I know gmaxwell is uncertain to whether we should also bundle the effective block size to increase to 2MB in this update.

==============

We could propose that we release and use such a UASF. We run bitcoin nodes that use such a UASF. And then Unlimited/Classic can respond with what they are going to do in response. Then exchanges etc can prepare on how they want to handle what will happen. So then most every important party would be prepared for a fork if it happens.

@chrisacheson

Re: your enumerations of possible outcomes to orphaning USAF:
The Low-cost failure and Costly failure options are not possible long term... unless Bitcoin the invention has some problem not identified by you or anyone else yet. They can only be short term problems in marketing/price. Because we engineers and technical people who understand Bitcoin and why its valuable will maintain good policy... and we will also maintain the coin's price floor. Confidence will eventually be restored and more induction investors and herd investors will come back to our coin as they see how efficiently it moves money.

"Optsegwit and nonsegwit miners hold out indefinitely. Bitcoin remains split into two currencies, both of them a sad mockery of what once was. Crypto-currencies are deemed non-viable by the general public for decades afterwards. CATASTROPHIC FAILURE"

If Bitcoin technology is better than say monopoly enforced fiat money... and works in the long term, then this split is only a problem in the short. Long term Bitcoin technology will become a success in creating competing money choices. Its not true that the core branch would be a "sad mockery", instead it is an excellent technology full of great features and economic policy. The duration that the general public who doesn't use bitcoin for technical analysis reasons is only a short term problem that will be quickly resolved by intelligent thinking for self entrepreneurs who maintain Bitcoin's price floor.

I would agree that the short term effects of orphaning could likely be significantly worse than other proposals to UASF by hardcoded date on (or after) Nov 15. But I'd disagree that it will matter much in the long term... say 2-5 years out we'll have market confidence again. After the MtGox failure, it only took about 2 years for the market to realize it found the price floor and begin to build in price again.