-bip148 option #10428

Disabled by default, this optional parameter allows a user to choose bip148 enforcement.

Concept ACK

Concept ACK

utACK

Concept ACK

Does this mean that blocks from miners using Bitcoin Core generated block templates will be rejected by the same Bitcoin Core version running on users machines with this option?

@paveljanik No, since they signal segwit by default they will be accepted as long as they don't build on top of non-signalling blocks.

Thank you for submitting this.

Has someone done a risk analysis on the use of this by a minority?

I found this to be a good summary of the risks of various fork scenarios: https://blog.blockchain.com/2016/02/26/a-brief-history-of-bitcoin-forks/

If this optional parameter is permitted, then hard fork optional parameters such as -bip102 should be permitted as well.

@jgarzik This is still a soft fork, the difference is just how it is activated. Activation is done by economic majority, the reason one may want to use an optional parameter is because measuring if the network has reached a suitable economic majority is not as straight forward as measuring signalling blocks, one should activate the flag once they are confident a suitable percentage of the economy intends to activate the flag. The fork is convergent as long as there is an economic majority or miner majority backing it since miners ultimately mine the most profitable chain. A hard fork like BIP102 however is never convergent.

Concept ACK

If hash rate support is less than 50%, this option causes a hard fork - a contentious minority chain hard fork to be clear. This is risky and should not be allowed in the official client.

If you do allow this, you will need to allow other, less risky (only activate with 75% or more hash rate) hard fork proposals in options form as well!

@chaosgrid no it doesn't, it causes a chain split in that case. If it becomes minority chain at the start it can still potentially reorg the legacy chain if miners jump ship. A hard fork on the other hand splits and users or miners running legacy software pre-HF will never follow the HF'd chain no matter how much hash power it has.

Concept ACK for soft forks

Concept ACK @chaosgrid It should be noted that there is already precedence for giving users the ability to manually enable options that have the potential to cause a chain split. Using the invalidateblock command, for example, would also technically be a soft-fork that can be activated in a similar way to this proposal. These options are safe to include because they are off by default. No user will accidentally be out of consensus.

@forkwar All users that change default options without understanding what they do are at risk of being on another chain.

Shouldn't there be mechanisms in place to ensure direct connectivity to other bip148 nodes? Otherwise the network could become partitioned on Aug 1st.

Concept ACK, but the description should include a very strong warning of the risks involved. There is a lot of misinformation about bip148 (from both sides), including a lot of people being told it's the lower risk option. Without an appropriate warning I feel many people will be misled.

In fact, I'd strongly prefer the flag to be called "-very-dangerous-bip148" or something similar (which can also set precedent for other controversial like flags). If it is merged in without a similarly alarming prefix, it'll be taken as an endorsement. (e.g. from the reddit thread that is brigading this issue:)

This is important because many businesses support the UASF cause, however they only trust Core code. If it is in Core code, prepare for many businesses to support it.

Most previous arguments here against UASF are based on false assumptions. However UASF is most likely going to be hugely disruptive. I expect wallets, exchanges and companies not implementing sufficient protections for chainsplit. Not even Core is working on it.

However it seems like the ginny is out of the bottle, the disruption is unavoidable, it's hard to tell how big it will be.
I was wondering if having a temporary (and already unavoidable) UASF disruption is a bigger risk, than crippling the Bitcoin development and the scaling of Bitcoin?

While the answer to that question can be vague, but more importantly we should decide when does not merging UASF by default becomes a bigger systemic risk than merging it?

Concept NACK. This has high risk of leading to a consensus break and a chainsplit, and is a dangerous parameter as such. Not sure how all the usual suspects I see who generally argue against such are concept ACKing this...

Not sure how all the usual suspects I see who generally argue against such are concept ACKing this...

I am in general against bip148 for the reasons you state, however I don't have problem with the idea of adding support as an option. I guess it comes down to if you believe bitcoin core should allow people to choose dangerous options without forcing them to recompile.

Personally I think it should as long as it's very clear about the dangers and there isn't excessive maintenance cost in including it. However it's worth pointing out that this style of change is potentially a lot more disruptive than a simple controversial hard fork. (Not only may it lead to a prolonged chain split, it may lead to a wipe out of the original chain causing millions of dollars of loses)

@pdaian

Not sure how all the usual suspects I see who generally argue against such are concept ACKing this...

Please leave the personal attacks out of GitHub.

@rhavar 100% agree here. If it becomes clear that an economic majority has not been achieved, it is trivial for users to remove this option, therefore there is much less risk. But still, users should know this.

Likewise, once a large portion of the network is already running this option, it should become the default.... as it would then be the much safer choice for users.

I will add a warning today to the description explaining this. Any suggestions for verbiage would be appreciated.

This is not the place to debate the merits (or not) of BIP148. I kindly remind people to keep their comments to technical evaluation of the code and potential safety fixes, not game theoretic arguments about economic majorities. That discussion is important but this is not the place for it. If discussion gets out of hand this PR will be locked and nobody wants that.

Personally I think it should as long as it's very clear about the dangers and there isn't excessive maintenance cost in including it. However it's worth pointing out that this style of change is potentially a lot more disruptive than a simple controversial hard fork. (Not only may it lead to a prolonged chain split, it may lead to a wipe out of the original chain causing millions of dollars of loses)

Agreed. I think by that same logic, an option to remove enforcement of the blocksize limit is an obvious addition. I will prepare a separate PR. Thanks for discussion, all.

Can someone actually take a quick glance at the code and make sure I didn't fat finger something.

Disgusting

utACK.

Running test node built from earonesty/bitcoin/0.14 #a181fe95c850ab05aa7787cf154cdda238e2d3f9

Tested -bip148 flag activation from command line and bitcoin.conf.

Activation implementation looks to be the one specified in https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

Local unit tests & checks passed.

NACK

This can be implemented on top of -blocknotify and RPC invalidateblock, and useragent change without this dangerous modification. Any volunteer to contribute this solution?

This solution will also allow older clients to use BIP148 like solution without updating to the newest not yet released Bitcoin Core client.

@paveljanik This is an acceptance change for users to be able to enforce soft acceptance conditions of blocks in accordance to BIP148 . There is no point to accept a block, notify it and then invalidate it.

For uacomment signals see http://www.uasf.co/

If you would like to contribute a script for using blocknotify events and running invalidateblock requests according to bip148 please start a new pull request or check with the UASF repository and their contributed scripts section.

@paveljanik It would be nice if Bitcoin had a s plug-in architecture - not for consensus changes - but certainly for RPC handling, etc.

@earonesty Any particular reason why this have been PRed against 0.14?

Concept ACK @jgarzik, there is no equivalence between this commandline flag and a flag for hard fork changes

@jgarzik If you're going to comment on this, would you mind answering the question we all have about your apparent conflict of interest with the fact that your company owns anti-privacy coin deanonymization tech that would be made much less valuable if segwit activates and Lightning becomes widely used?

In particular, what are you plans for that technology?

@petertodd This is not the place to debate the merits (or not) of who owns what technology. I kindly remind people to keep their comments to technical evaluation of the code and potential safety fixes, not game theoretic arguments about businesses. That discussion is important but this is not the place for it. If discussion gets out of hand this PR will be locked and nobody wants that.

@jgarzik It's good manners and helpful to productive discussion when participants properly disclose potential conflicts of interest. You have one, and so far have not alleviated concerns about that conflict of interest.

That disclosure doesn't have to happen here, but it does need to happen.

I concur with this approach as proposed by @earonesty and others.

@rhavar Maybe just move everything into the experimental section?

@RHavar Maybe just move everything into the experimental section?

I don't really have any say, but imo "experimental" has the wrong connotations. What about -dangerous-consensus-breaking-bip148 or something? I think it needs to be obvious that it's not an endorsement, just the freedom to do something that is potentially harmful without forcing users to have to compile their own copy (or switch to another implementation of bitcoin).

@RHavar I agree with longer option containing the word "dangerous".

Rather than put some weird warning strings in the flag, perhaps have an "enable delta consensus" flag which needs to also be present, otherwise, just using the BIP148 flag fails?

--enable-delta-consensus --eBIP148

@GratefulTony I was thinking about it too. I don't have preference here.

ACK

@sneurlax @jameshilliard @petertodd . It does not matter if the fork is 'hard' or 'soft', this is a very contentious fork with only limited miner support and will almost certainly result in a chain split. As such this change should not be supported. It is dangerous and completely lacks miner and community support.

@AllanDoensen This fork does not require miner majority support to be convergent, it only requires economic majority due to the incentive structure of mining. The flag merely provides a way to activate the fork once it is clear that an economic majority will support it, this is explained in more detail here.

@jameshilliard the way I read the code is the there is no test for 'an economic majority' at all. So this flag provides a means of activating the fork...no economic majority needed. Or am I reading the code incorrectly?

@AllanDoensen Economic majority signalling is something that is difficulty to measure automatically like miner signalling, hence the need for a manual flag. If it ends up being unclear if there is an economic majority backing BIP148 one can stop transaction activity at the time of BIP148 activation and watch the markets to confirm that the BIP148 enforcing chain has an economic majority backing it.

Correct me if I'm wrong, but in case of long coexistance of two chains, and then BIP148 chain overpowering the old one, wouldn't it cause very long reorg? This could potentially cause disaster grater in size than MtGox

@jameshilliard back to the code. So if we pass our date and segwit is not active, then someone fires up a 10 thousand nodes on a VM and brings down the bitcoin network. This is an attack vector that has not been discussed. This is not a good solution to the problem. Again I repeat this change is dangerous and completely lacks community and miner support.

The warning label on cigarettes never really scared me. I'm okay with the word dangerous, except for the fact that there's some sort of cool factor that we might be promoting. Experimental is more in keeping with the nature of the flag, since it's experimental. Indeed since user support is growing quickly with at least one minor exchange on board, it might be more dangerous not to. Maybe it's better not to presume an outcome

@mcgravier That's actually a big reason why it's unlikely there will be a long coexistance of two chains, it's unlikely people will risk transacting on a chain that has a high probability of having its history wiped out, which is something only the non-BIP148 chain would be at risk of. @AllanDoensen Sounds like you're referring to an eclipse attack, BIP148 has nothing to do with node counts, it's based on economic support.

@jameshilliard back to the code. This change allows for an 'eclipse' style attack as you have suggested. As such it does have to do with node counts. Again I repeat this change is dangerous and completely lacks community and miner support.

unlikely there will be a long coexistance of two chains

I believe, just "unlikely" isn't good enough for a 30bln dollar market.

@AllanDoensen No, it does not do an eclipse attack like you seem to have incorrectly assumed. Bitcoin is already quite resistant to widespread eclipse attacks due mitigation measures in how peering is handled, they aren't really a major concern at this time.

@jameshilliard I do not believe I have incorrectly assumed anything with respect to this code. Motherhood statements will only get you so far, maybe you should spend more time writing & reviewing the actual code.

@AllanDoensen The node count relation is explained under the "Does node count determine activation?" section here already. I'm not sure where you are seeing eclipse attack code as absolute node counts aren't really relevant to activation of BIP148. I'd suggest you read through the FAQ as it explains these issues already in detail.

@earonesty

Indeed since user support is growing quickly with at least one minor exchange on board, it might be more dangerous not to. Maybe it's better not to presume an outcome

Currently, 40% of hash rate is signaling for emergent consensus block size control. Roughly 10% of nodes signal as well. "Maybe it's better not to presume an outcome" and also add an option for emergent-consensus block size or the revised BIP100?

unlikely here is nearly impossible. like order of 1/2e256.

all Bitcoin basis is on such value of probability theory.

we have bip149 in 2017 and bip148 in July 2018. segwit will activate before 2018aug, no matter of hash rate power.

segwit is favorite of market (see Litecoin).

uasf chain will win with full confidence. old chain or bu chain will be of Little economic value.

in one word, segwit unlikely fail. just like btc privkey unlikely be guessed.

@earonesty your code itself looks good. I mean no disrespect, but take issue with the concept not the implementation.

As for 'dangerous' or 'experimental', I find it somewhat hypocritical that there is support for this, but no support for doing similar for bip100/bip102 or EC which are arguably just as dangerous. Thus I would think it would be better if there was a general means of signalling support for bips (including segwit) rather then just the odd implementation for one off cases such as this. So I would think that your code should be made generic in parts to support a range of signalling for BIPS.

I also think that as there is a 'start date' for this, there should also be an 'end date' so that if it fails it is not active in the codebase forever. Would you consider an end date of 2 months(?) as a change to the code?

@jameshilliard I know you are referencing a pretty document with nice charts....but that is not what this code & this PR says. Please read the code and comment on the code rather then referencing a document that says what you think the code should be doing. You can read C++ yes?

unsubscribe....

@AllanDoensen

then someone fires up a 10 thousand nodes on a VM and brings down the bitcoin network.

In what way would a lot of nodes "bring down the bitcoin network"? BIP 148 nodes will disconnect from (and ban IIRC) non-BIP 148 nodes after they relay a number of bip148-invalid blocks. non-BIP 148 nodes will still be able to connect to other non-BIP 148 nodes and maintain a separate non-BIP148 blockchain. Node's won't be crashing or doing anything that would "bring down the network".

There would be risk for transaction replay and for blockchain reorganizations. The miners are incentivised to use BIP 148 the BIP 148 chain will not be able to be wiped out by the non-BIP 148 chain. However the opposite of that is true; the non-BIP 148 chain could be wiped out by the BIP 148 chain if it were to be longer than it.

Anyways, you should read the "petty document" since it does explain a lot of this stuff.

@AllanDoensen one consideration should be the risk of not implementing the optional BIP148 flag. You are saying it is risky to add but have you considered the risk of not implementing it on the network if it were to activate in August? Again, this is only an option that is disabled by default. Core should consider all possibilities and the risk of not taking action in the event of a chain split IMHO is greater than the risk of adding an option that is disabled by default.

@achow101 yes the network would not go down, that was probably overreach, but many issues would arise as you have alluded to.

@AllanDoensen please comment or review the actual code. I have doubt you have read the C++ code that is only 1 click away. As your statements and complaints have been false in relation to the pull request.

@AllanDoensen I think what @starrymoonlight is talking about is not about systemic risk, but individual risk.
This all comes down to this. If you prefer Bitcoin Core to outsource the risk for the users then this optimal PR should be merged. If you prefer Bitcoin Core to protect the network, then this optimal PR should be closed and if UASF gains so much adoption that it becomes riskier for the network not to merge it, an emergency release should be issued with UASF enabled by default.

Concept NACK. This is more dangerous than it is being given credit for. What makes a soft fork "soft" is that non-upgraded nodes continue on the same chain and consider the new rules valid. Without 50% of hashing power behind it, a UASF will cause a chain split. Old nodes will be on the "wrong" chain, and new nodes will be on another chain.

The fact that much development and care has gone into segwit is NOT an argument for adopting it. That's a sunken cost fallacy. Not insignificant chunks of the miners, users, and economic actors seem to be opposed it. Their reasons and motivation is not relevant. All that matters is that segwit does not have near-universal acceptance, which has always been the standard for upgrading the protocol.

If you're going to merge in options that allow users to break off onto a different chain under not-unlikely scenarios, why not also add in non-segwit base blocksize increases as options too? Or how about a pow=sha3 switch? Heck, let's just make it a barebones non-descript PoW blockchain client and have the users set all the consensus parameters they want. Then their client will only connect to whatever chain they want to be on. I mean, if the consensus chain doesn't require unanimous consensus, why not? There's no harm if we're now claiming that converging onto one chain isn't important.

Concept NACK. BIP 148 carries high, unnecessary risk of a chain split, as has been discussed on the mailing list. This project has always held high standards for deploying consensus-changing proposals while minimizing risks to consensus splits. In my view, BIP 148 as drafted is incompatible with the goals of this project, and putting it behind a command line option does not address the fundamental nature of this incompatibility. (I'll refrain from posting further on BIP 148 as I agree that GitHub is not the best place for these discussions but as this is my primary objection to this PR I see no other choice but to make some mention of it here. I'll take further analysis of these concerns to the mailing list.)

[There are also technical issues with this PR -- such as the peering concerns raised by @maaku (which are completely correct), and the lack of inclusion of any tests for this code. These could be addressed, of course, but as a purely technical matter, this PR is not currently suitable for merging, even if BIP 148 were not flawed.]

@sdaftuar To my knowledge, this PR properly isolates bip148 nodes from other peers. Also, this PR is not "for bip148" - it is an effort to prevent bitcoin fragmenting and protect exchanges from the negative consequences of a reorg.

Right now 10% of the nodes on the network are running non-core UASF code - including SPV wallet nodes and some small exchanges. Failing to protect users and miners by providing an option that puts them on the side of the fork that's less likely to encounter a reorg seems irresponsible.

If the current trend continues, and we try to roll something out as a last minute reaction - it could be too late to protect our most important users. Having it as an option allows users to enable it if needed to side with whatever the majority may be. If it comes to that, we can enable it by default, and make an announcement that people should either recompile or enable the option. Or the reverse: remove it from the code base and announce it will no longer be supported.

Concept ACK. Found some minor bugs.

There are circumstances where this won't upgrade cleanly from a non-BIP148 client: specifically, after July in the case where miners have produced invalid blocks, this will fail to reconsider them. However, this is an issue for all past softfork deployments (except BIP141) as well, so probably shouldn't be a blocker (and can be improved in a later PR).

Shouldn't there be mechanisms in place to ensure direct connectivity to other bip148 nodes? Otherwise the network could become partitioned on Aug 1st. @maaku This is no different from any other softfork. Unlike Segwit, there isn't a stripped block to be avoided. Perhaps some mechanism like this could be an improvement, but it probably isn't necessary, and can't be secure against sybil attacks anyway. @RHavar BIP148 is indeed truly the lower-risk option.

While the answer to that question can be vague, but more importantly we should decide when does not merging UASF by default becomes a bigger systemic risk than merging it? @nopara73 It is already a bigger risk to not merge BIP148, than to merge it.

This can be implemented on top of -blocknotify and RPC invalidateblock, and useragent change without this dangerous modification. Any volunteer to contribute this solution? @paveljanik Why should Core require an external script/program to remain a fully validating node?

Correct me if I'm wrong, but in case of long coexistance of two chains, and then BIP148 chain overpowering the old one, wouldn't it cause very long reorg? @mcgravier Only for non-full nodes (ie, failing to enforce BIP148). This is always and already a risk if miners create long invalid blockchains, it isn't a new thing introduced by BIP148 specifically. It is normal in a softfork that old nodes have this risk.

@jameshilliard back to the code. This change allows for an 'eclipse' style attack as you have suggested. As such it does have to do with node counts. @AllanDoensen What are you talking about? The code doesn't do anything you describe. Why do you pretend to read the code, when what you're saying has nothing to do with what the code actually does??

BIP 148 carries high, unnecessary risk of a chain split, as has been discussed on the mailing list. @sdaftuar As with any softfork, miners who create long invalid blockchains violating the rules can cause a chain split. Such a chain split is not caused by BIP 148, but by non-compliant miners creating invalid blocks. Furthermore, this risk is strictly reduced by increased adoption of the softfork, since it becomes less economically viable for miners to go on producing these invalid blocks very long. @earonesty This PR should be closed and rebased against master.

@earonesty: Failing to protect users and miners by providing an option that puts them on the side of the fork that's less likely to encounter a reorg seems irresponsible. If the current trend continues, and we try to roll something out as a last minute reaction - it could be too late to protect our most important users.

@luke-jr : It is already a bigger risk to not merge BIP148, than to merge it.

This kind of argument is weak I'm amazed it's been repeated so many times.

The simple existence of a soft fork patch that has the potential to wipe out the legacy chain does not warrant the inclusion of that patch in the official Core software, which must maintain a high standard for changes, as @sdaftuar and others have pointed out.

If say, BU releases a similar soft fork patch that also endangers the legacy chain in the event that they get 51% hash rate (in fact, they would be in a better position to do so), would you guys be OK with including that software patch into the Core client? No.

You know who else used similar logic / scare tactic to justify their action? the people that caused the Cold War nuclear arms race. "If you don't improve our nuclear capability -> the Russians might nuke us first." "If you don't include this patch in Core client -> the network might blow up."

TL;DR: This is the wrong sort of argument to be used for including changes in Core.

OK, I was working off the UASF branch, I'm closing this and reopening rebased to master.

Moved to #10442