[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Mike Belshe mike at bitgo.com
Tue Oct 10 14:52:59 UTC 2017


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.

Mike


On Tue, Oct 10, 2017 at 7:49 AM, Jared Lee Richardson via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

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



-- 


*Mike Belshe*
*CEO, BitGo, Inc*408-718-6885
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171010/93d93e22/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list