<div dir="ltr">Hey - this thread is degrading into unproductive, off-topic noise.  If no more points are to be made about technical discussion of split-chain/replay protection, then lets just stop.<div><br></div><div>Mike</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 10, 2017 at 7:49 AM, Jared Lee Richardson via Bitcoin-segwit2x <span dir="ltr">&lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org" target="_blank">bitcoin-segwit2x@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; SPV is a weaker security model.<br>
<br>
</span>Yes, for those USERS.  Guess what... Most users do not need Fort Knox<br>
levels of security.<br>
<br>
Properly done SPV wallets can become trustless up to millions of<br>
dollars of economic value transferred because of the economic penalty<br>
properties of mining.<br>
<br>
Since there is no such vulnerability inherent in the ecosystem;<br>
Blocksizes can be increased now.<br>
<span class=""><br>
&gt; It also has pretty bad scaling properties that need to be addressed if the intention is for all users to run SPV clients.<br>
<br>
</span>Oh, isn&#39;t that the thing you wrote and multiple core developers<br>
reviewed and approved but you literally forgot that computers can do<br>
caching and can batch requests, which ruins pretty much all of the<br>
math you did?<br>
<br>
And it isn&#39;t even a very good argument after ignoring that.  Those are<br>
completely fixable problems.  Are things being prioritized to work on<br>
that?  I can say that 2x is prioritizing it.  But I guess if no one<br>
prioritizes the things that &quot;must happen&quot; so Bitcoin can scale... we<br>
can&#39;t ever scale!  Yay!<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Tue, Oct 10, 2017 at 7:41 AM, Jared Lee Richardson<br>
&lt;<a href="mailto:jaredr26@gmail.com">jaredr26@gmail.com</a>&gt; wrote:<br>
&gt;&gt; The moral of the story here is we should be conservative/humble with the security assumptions of bitcoin.<br>
&gt;<br>
&gt; No, the moral of the story is that you are literally choking the<br>
&gt; growth of the ecosystem based on assumptions.<br>
&gt;<br>
&gt;&gt; but an example of a vulnerability found less than a year ago is Sergio Demian Lerner&#39;s FindAndDelete exploit.<br>
&gt;<br>
&gt; Those aren&#39;t unsolvable issues related to blocksize.  When those are<br>
&gt; found, we fix them.  End of story.<br>
&gt;<br>
&gt;&gt; however if there is a throughput increase to the system this can be setup faster (and cheaper).<br>
&gt;<br>
&gt; ... Which was fixed.  So now we can increase the blocksize.<br>
&gt;<br>
&gt;<br>
&gt; Refusing to increase the blocksize is doing REAL measurable damage to<br>
&gt; Bitcoin.  If you don&#39;t have a real measurable attack that we<br>
&gt; absolutely must protect ourselves against, increasing the blocksize is<br>
&gt; a no brainer.<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Oct 10, 2017 at 7:29 AM, Chris Stewart &lt;<a href="mailto:chris@suredbits.com">chris@suredbits.com</a>&gt; wrote:<br>
&gt;&gt;&gt;Can you please show an attack whereby bigger blocks decreases<br>
&gt;&gt; Bitcoin&#39;s &quot;security model&quot;?  What&#39;s the game theory of that attack<br>
&gt;&gt; scenario?  What&#39;s the metrics / measurement when Bitcoin should know<br>
&gt;&gt; it is in danger?<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t have a specific vulnerability on hand -- and it would be extremely<br>
&gt;&gt; irresponsible of me to disclose it via a mailing list (!) -- but an example<br>
&gt;&gt; of a vulnerability found less than a year ago is Sergio Demian Lerner&#39;s<br>
&gt;&gt; FindAndDelete exploit.<br>
&gt;&gt;<br>
&gt;&gt; <a href="https://bitslog.wordpress.com/2017/01/08/a-bitcoin-transaction-that-takes-5-hours-to-verify/" rel="noreferrer" target="_blank">https://bitslog.wordpress.com/<wbr>2017/01/08/a-bitcoin-<wbr>transaction-that-takes-5-<wbr>hours-to-verify/</a><br>
&gt;&gt;<br>
&gt;&gt; This was a serious vulnerability before it was patched. It is made worse by<br>
&gt;&gt; a throughput increase to our system as you can fit more of these txs in a<br>
&gt;&gt; block.<br>
&gt;&gt;<br>
&gt;&gt; Another example of Christopher Jeffrey&#39;s exploit at breaking bitcoin. He<br>
&gt;&gt; emphasizes that the setup for this attack takes a long time -- which makes<br>
&gt;&gt; it unlikely -- however if there is a throughput increase to the system this<br>
&gt;&gt; can be setup faster (and cheaper).<br>
&gt;&gt;<br>
&gt;&gt; <a href="https://www.youtube.com/watch?v=0WCaoGiAOHE&amp;feature=youtu.be&amp;t=8944" rel="noreferrer" target="_blank">https://www.youtube.com/watch?<wbr>v=0WCaoGiAOHE&amp;feature=youtu.<wbr>be&amp;t=8944</a><br>
&gt;&gt;<br>
&gt;&gt; The moral of the story here is we should be conservative/humble with the<br>
&gt;&gt; security assumptions of bitcoin. We *still* have a lot to learn about<br>
&gt;&gt; bitcoin and consensus based protocols. If you can DoS the network in a way<br>
&gt;&gt; that causes the p2p network to fail there will be a severe disruption to<br>
&gt;&gt; bitcoin. As it stands the bitcoin protocol has an astounding track record in<br>
&gt;&gt; terms of up time -- I&#39;d like it to keep it that way.<br>
&gt;&gt;<br>
&gt;&gt; -Chris<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Oct 10, 2017 at 9:16 AM, Jared Lee Richardson via Bitcoin-segwit2x<br>
&gt;&gt; &lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &gt; If you want to redesign the system to force everyone into a weaker<br>
&gt;&gt;&gt; &gt; security model, you could do a LOT better to make it simpler and more<br>
&gt;&gt;&gt; &gt; efficient while you&#39;re at it.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Can you please show an attack whereby bigger blocks decreases<br>
&gt;&gt;&gt; Bitcoin&#39;s &quot;security model&quot;?  What&#39;s the game theory of that attack<br>
&gt;&gt;&gt; scenario?  What&#39;s the metrics / measurement when Bitcoin should know<br>
&gt;&gt;&gt; it is in danger?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Tue, Oct 10, 2017 at 7:03 AM, Jameson Lopp via Bitcoin-segwit2x<br>
&gt;&gt;&gt; &lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x<br>
&gt;&gt;&gt; &gt; &lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via<br>
&gt;&gt;&gt; &gt;&gt; Bitcoin-segwit2x<br>
&gt;&gt;&gt; &gt;&gt; wrote:<br>
&gt;&gt;&gt; &gt;&gt; &gt; The Bitcoin Core process is quite unrelated to this question.<br>
&gt;&gt;&gt; &gt;&gt; &gt; Regardless<br>
&gt;&gt;&gt; &gt;&gt; &gt; of which code they do or do not merge into their repositories, it is<br>
&gt;&gt;&gt; &gt;&gt; &gt; the<br>
&gt;&gt;&gt; &gt;&gt; &gt; existing set of nodes with the existing set of software that is the<br>
&gt;&gt;&gt; &gt;&gt; &gt; question.<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; The vast majority of people use either SPV wallets or online wallets.<br>
&gt;&gt;&gt; &gt;&gt; They will just follow the longest chain.<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; I’d like to point out that the only people that will have to upgrade<br>
&gt;&gt;&gt; &gt;&gt; are<br>
&gt;&gt;&gt; &gt;&gt; the<br>
&gt;&gt;&gt; &gt;&gt; people that run a Bitcoin Core node while they are not miners etc.<br>
&gt;&gt;&gt; &gt;&gt; Those individuals are doing it wrong anyway.<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; Instead of badgering the SegWit-workgroup, I think a much higher rate<br>
&gt;&gt;&gt; &gt;&gt; of<br>
&gt;&gt;&gt; &gt;&gt; benefit can be reached by educating the people that run full nodes and<br>
&gt;&gt;&gt; &gt;&gt; explaining how they are not in actual fact helping the network.<br>
&gt;&gt;&gt; &gt;&gt; The simple fact is that if they didn’t run those nodes, this whole<br>
&gt;&gt;&gt; &gt;&gt; discussion would not exist.<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt; If you want to redesign the system to force everyone into a weaker<br>
&gt;&gt;&gt; &gt; security<br>
&gt;&gt;&gt; &gt; model, you could do a LOT better to make it simpler and more efficient<br>
&gt;&gt;&gt; &gt; while<br>
&gt;&gt;&gt; &gt; you&#39;re at it.<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; Yes, user sovereignty is a huge inconvenience to those who wish to push<br>
&gt;&gt;&gt; &gt; a<br>
&gt;&gt;&gt; &gt; contentious proposal. That&#39;s the whole point. You&#39;re free to create a<br>
&gt;&gt;&gt; &gt; new<br>
&gt;&gt;&gt; &gt; system without it, but I suspect you won&#39;t have much success convincing<br>
&gt;&gt;&gt; &gt; users who value financial sovereignty to voluntarily give it up.<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; --<br>
&gt;&gt;&gt; &gt;&gt; Tom Zander<br>
&gt;&gt;&gt; &gt;&gt; Blog: <a href="https://zander.github.io" rel="noreferrer" target="_blank">https://zander.github.io</a><br>
&gt;&gt;&gt; &gt;&gt; Vlog: <a href="https://vimeo.com/channels/tomscryptochannel" rel="noreferrer" target="_blank">https://vimeo.com/channels/<wbr>tomscryptochannel</a><br>
&gt;&gt;&gt; &gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt; &gt;&gt; Bitcoin-segwit2x mailing list<br>
&gt;&gt;&gt; &gt;&gt; <a href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org">Bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt;&gt; &gt;&gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>segwit2x</a><br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt; &gt; Bitcoin-segwit2x mailing list<br>
&gt;&gt;&gt; &gt; <a href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org">Bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt;&gt; &gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>segwit2x</a><br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt; Bitcoin-segwit2x mailing list<br>
&gt;&gt;&gt; <a href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org">Bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt;&gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>segwit2x</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
______________________________<wbr>_________________<br>
Bitcoin-segwit2x mailing list<br>
<a href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org">Bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>segwit2x</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><p style="font-size:12.8px"><b style="font-size:12.8px;line-height:17px"><font color="#0b5394">Mike Belshe<br></font></b><b style="font-size:12.8px;line-height:17px"><font color="#0b5394">CEO, BitGo, Inc<br></font></b><span style="font-size:12.8px;line-height:17px;color:rgb(102,102,102)">408-718-6885</span></p></div></div></div></div></div></div></div></div></div></div>
</div>