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

Sjors Provoost sjors at sprovoost.nl
Sat Oct 14 19:09:20 UTC 2017


Unupgraded SPV wallets *might* follow the longest chain.

This assumption has not been well tested. Perhaps there are private
experiments that I'm not aware of. I asked multiple specific questions
about the expected behavior of SPV wallets on various pull requests, the
answer was generally "not sure, we should probably check". This topic is
not well understood (by anyone, not just the SegWit2x team).
There's three problems:

1 - the wallet actually needs to find the longest chain in order
to follow it
2 - if they initially followed the shorter chain, they may need to
handle a very large reorg; typical reorgs are just a few blocks, so
these wallets may not have been stress tested for larger reorgs. They
crash or misbehave in other ways.
3 - more recent, Luke-Jr proposed a fairly trivial upgrade to SPV
wallets that could be rolled out to most users before the fork. It
basically tells the wallet to inspect the size of the hard-fork block
494784. The wallet can then give users a choice or default to what the
wallet author believes is safe. They might listen to Core for advice,
but it's not up to Core.
It's worth your (staff's) time trying to understand what Adam is
pointing at.
As for (b) I have still not heard a formal statement from the SegWit2x
leadership that the consensus rules and code are frozen and will not
have any replay protection. Of course I don't know what the decision
making process is there. Whether code is open source doesn't really
matter for such decision making process; I hope the plan isn't to just
wait and see which replay protection branch miners run. :-)
Sjors

On Sat, Oct 14, 2017, at 19:13, Mike Belshe via Bitcoin-segwit2x wrote:> 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

> _________________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171014/6020c886/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list