[Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening?

Hey Adam - Your long and winding messages are often hard to follow ;-) A few succinct replies: a) The SPV wallets will follow the longest chain; if Core diverges from the longest chain, Core will be alienating 15+million wallets. I think this is a shame, but I know we disagree. b) Counter to your claim, BTC1 is not changing up to 5 days before the fork. It's an open source project, so I don't control it, but general sentiment is that it is done for now. The team prefers to keep it stable rather than add various opt-in replay protections that both sides seem to not like anyway. c) You claim that "most smart phone wallets" will not follow the longest chain. I believe this is untrue. Can you tell me which wallets you're referring to? Mike On Sat, Oct 14, 2017 at 4:19 AM, Dr Adam Back via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > A lot of what you described doesn't work the way you seem to expect. > > There's a few levels: > > Mining economics: I do some mining, and there are a number of data > points from alt-coins that share mining algorithms: miners short / mid > term mine what is profitable. That is driven by relative price. > Difficulty adjusts to equilibrium. This is a feature, it is the > incentive that secures blockchains. Bitcoin security works by > economically incentivised creation of valid blocks as measured by the > nodes on the network. > > Nodes and wallets mechanically todays software: Existing full nodes > won't follow. Most smart phone wallets will not automatically switch > but either ignore a new chain, stop functioning, go into some kind of > warning state pending bugfix, some older wallets may get stuck on > random chain. And because there is no proper replay protection > randomly transactions will be made on one or both chains unless mixed > with new coinbase over time. That will be pretty disruptive because > people writing wallet software don't know what segwit2x code will be > as they keep changing. Bitcoin cash changed up to 5days before > release. > > Services: Also it's a big job to defend all existing all existing > services and wallets. Never the less as both chains have value each > service and wallet must over time offer some solution even if it is > replay protected withdrawal. So nothing is achieved in practice vs > proper replay protection other than disruption. > > Due Care & safety: Doing reckless and risky things to the network may > not be a good advertisement for service or wallet. Users will > research and make some decision about which wallets and services will > preserve their coins and allow them to split and sell or hold > whichever of the 3 or 4 spinoffs are created. People will likely not > recommend software and services that promote dand advocated for > creating the disruption and risk. > > Financial, support tickets: users will complain via support tickets > and formal complaints about experience and asset loss as that happens. > > Would be interested in proponents views of how their companies (if > they have users) will handle this, and also how they suppose different > use cases from other services and wallets will interoperate. > > It sort of feels like there is an expected game-theory reaction here > that no one is talking about, but maybe people have different views of > what the logical game theory is? > > ps please trip replies list posts are bouncing as too large. > > Adam > > On Sat, Oct 14, 2017 at 2:20 AM, Ben Peters via Bitcoin-segwit2x > <bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > I think there is a fundamental misunderstanding about the nature of the > > NYA/Segwit2x endeavour. What is happening here is that an alternative, > > minimally modified, version of the Bitcoin code is being developed that > will > > implement a change that has long been sought by the mining community and > > many in industry and beyond (a change that they presumably feel is > important > > for the future success of Bitcoin and thus their respective investments). > > > > That candidate code will be offered to the miners and mining pools, who > may > > or may not opt to apply hashing power to it. If they apply more than the > > threshold amount of hashing power, then that new code will effectively > > takeover from the previous consensus rule, and take most SPV wallets and > > economic activity along with it. > > > > Rather than lobbying this technical working group to “call off” their > > efforts, your time might be better spent lobbying the miners. The > function > > of this group is to produce candidate code, thus fulfilling the > obligations > > as set out under the NYA. > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- *Mike Belshe* *CEO, BitGo, Inc*408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171014/68d37417/attachment.html>