This has been moved to https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
Last active
March 20, 2023 01:14
-
-
Save shaolinfry/743157b0b1ee14e1ddc95031f1057e4c to your computer and use it in GitHub Desktop.
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@chrisacheson
I appreciate your feedback. What are the different options and possibilities of what could happen?
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.
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.
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:
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.
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.