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

Dr Adam Back adam at blockstream.com
Sat Oct 14 19:12:46 UTC 2017


Here's breadwallet's summary of how they so far think two networks may
behave for their SPV wallet.

https://breadapp.com/blog/how-bread-will-handle-segwit2x-fork-november/

Adam

On Sat, Oct 14, 2017 at 9:09 PM, Sjors Provoost via Bitcoin-segwit2x
<bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> 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
>
>
>
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>


More information about the Bitcoin-segwit2x mailing list