<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"><<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org" target="_blank">bitcoin-segwit2x@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 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>
> 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'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'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 "must happen" so Bitcoin can scale... we<br>
can'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>
<<a href="mailto:jaredr26@gmail.com">jaredr26@gmail.com</a>> wrote:<br>
>> The moral of the story here is we should be conservative/humble with the security assumptions of bitcoin.<br>
><br>
> No, the moral of the story is that you are literally choking the<br>
> growth of the ecosystem based on assumptions.<br>
><br>
>> but an example of a vulnerability found less than a year ago is Sergio Demian Lerner's FindAndDelete exploit.<br>
><br>
> Those aren't unsolvable issues related to blocksize. When those are<br>
> found, we fix them. End of story.<br>
><br>
>> however if there is a throughput increase to the system this can be setup faster (and cheaper).<br>
><br>
> ... Which was fixed. So now we can increase the blocksize.<br>
><br>
><br>
> Refusing to increase the blocksize is doing REAL measurable damage to<br>
> Bitcoin. If you don't have a real measurable attack that we<br>
> absolutely must protect ourselves against, increasing the blocksize is<br>
> a no brainer.<br>
><br>
><br>
> On Tue, Oct 10, 2017 at 7:29 AM, Chris Stewart <<a href="mailto:chris@suredbits.com">chris@suredbits.com</a>> wrote:<br>
>>>Can you please show an attack whereby bigger blocks decreases<br>
>> Bitcoin's "security model"? What's the game theory of that attack<br>
>> scenario? What's the metrics / measurement when Bitcoin should know<br>
>> it is in danger?<br>
>><br>
>> I don't have a specific vulnerability on hand -- and it would be extremely<br>
>> irresponsible of me to disclose it via a mailing list (!) -- but an example<br>
>> of a vulnerability found less than a year ago is Sergio Demian Lerner's<br>
>> FindAndDelete exploit.<br>
>><br>
>> <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>
>><br>
>> This was a serious vulnerability before it was patched. It is made worse by<br>
>> a throughput increase to our system as you can fit more of these txs in a<br>
>> block.<br>
>><br>
>> Another example of Christopher Jeffrey's exploit at breaking bitcoin. He<br>
>> emphasizes that the setup for this attack takes a long time -- which makes<br>
>> it unlikely -- however if there is a throughput increase to the system this<br>
>> can be setup faster (and cheaper).<br>
>><br>
>> <a href="https://www.youtube.com/watch?v=0WCaoGiAOHE&feature=youtu.be&t=8944" rel="noreferrer" target="_blank">https://www.youtube.com/watch?<wbr>v=0WCaoGiAOHE&feature=youtu.<wbr>be&t=8944</a><br>
>><br>
>> The moral of the story here is we should be conservative/humble with the<br>
>> security assumptions of bitcoin. We *still* have a lot to learn about<br>
>> bitcoin and consensus based protocols. If you can DoS the network in a way<br>
>> that causes the p2p network to fail there will be a severe disruption to<br>
>> bitcoin. As it stands the bitcoin protocol has an astounding track record in<br>
>> terms of up time -- I'd like it to keep it that way.<br>
>><br>
>> -Chris<br>
>><br>
>><br>
>> On Tue, Oct 10, 2017 at 9:16 AM, Jared Lee Richardson via Bitcoin-segwit2x<br>
>> <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>>><br>
>>> > If you want to redesign the system to force everyone into a weaker<br>
>>> > security model, you could do a LOT better to make it simpler and more<br>
>>> > efficient while you're at it.<br>
>>><br>
>>> Can you please show an attack whereby bigger blocks decreases<br>
>>> Bitcoin's "security model"? What's the game theory of that attack<br>
>>> scenario? What's the metrics / measurement when Bitcoin should know<br>
>>> it is in danger?<br>
>>><br>
>>><br>
>>> On Tue, Oct 10, 2017 at 7:03 AM, Jameson Lopp via Bitcoin-segwit2x<br>
>>> <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>>> ><br>
>>> ><br>
>>> > On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x<br>
>>> > <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>>> >><br>
>>> >> On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via<br>
>>> >> Bitcoin-segwit2x<br>
>>> >> wrote:<br>
>>> >> > The Bitcoin Core process is quite unrelated to this question.<br>
>>> >> > Regardless<br>
>>> >> > of which code they do or do not merge into their repositories, it is<br>
>>> >> > the<br>
>>> >> > existing set of nodes with the existing set of software that is the<br>
>>> >> > question.<br>
>>> >><br>
>>> >> The vast majority of people use either SPV wallets or online wallets.<br>
>>> >> They will just follow the longest chain.<br>
>>> >><br>
>>> >> I’d like to point out that the only people that will have to upgrade<br>
>>> >> are<br>
>>> >> the<br>
>>> >> people that run a Bitcoin Core node while they are not miners etc.<br>
>>> >> Those individuals are doing it wrong anyway.<br>
>>> >><br>
>>> >> Instead of badgering the SegWit-workgroup, I think a much higher rate<br>
>>> >> of<br>
>>> >> benefit can be reached by educating the people that run full nodes and<br>
>>> >> explaining how they are not in actual fact helping the network.<br>
>>> >> The simple fact is that if they didn’t run those nodes, this whole<br>
>>> >> discussion would not exist.<br>
>>> >><br>
>>> > If you want to redesign the system to force everyone into a weaker<br>
>>> > security<br>
>>> > model, you could do a LOT better to make it simpler and more efficient<br>
>>> > while<br>
>>> > you're at it.<br>
>>> ><br>
>>> > Yes, user sovereignty is a huge inconvenience to those who wish to push<br>
>>> > a<br>
>>> > contentious proposal. That's the whole point. You're free to create a<br>
>>> > new<br>
>>> > system without it, but I suspect you won't have much success convincing<br>
>>> > users who value financial sovereignty to voluntarily give it up.<br>
>>> >><br>
>>> >> --<br>
>>> >> Tom Zander<br>
>>> >> Blog: <a href="https://zander.github.io" rel="noreferrer" target="_blank">https://zander.github.io</a><br>
>>> >> Vlog: <a href="https://vimeo.com/channels/tomscryptochannel" rel="noreferrer" target="_blank">https://vimeo.com/channels/<wbr>tomscryptochannel</a><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>
>>> ><br>
>>> ><br>
>>> ><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>
>>> ><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>
>><br>
>><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>