[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Jameson Lopp jameson.lopp at gmail.com
Tue Oct 10 14:33:03 UTC 2017


I was referring to SPV vs full node security models. Deep dive into them
available here: https://www.coindesk.com/bitcoins-security-model-deep-dive/

SPV is a weaker security model. It also has pretty bad scaling properties
that need to be addressed if the intention is for all users to run SPV
clients. Deep dive available here:
https://www.coindesk.com/spv-support-billion-bitcoin-users-sizing-scaling-claim/

- Jameson

On Tue, Oct 10, 2017 at 10: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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171010/b0da2313/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list