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