[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Chris Stewart chris at suredbits.com
Tue Oct 10 14:29:56 UTC 2017


>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171010/6865dfe3/attachment.html>


More information about the Bitcoin-segwit2x mailing list