[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Jared Lee Richardson jaredr26 at gmail.com
Tue Oct 10 14:41:38 UTC 2017


> 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
>
>


More information about the Bitcoin-segwit2x mailing list