[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Tue Oct 10 14:51:15 UTC 2017

>... Which was fixed.  So now we can increase the blocksize.

Yes they were fixed. Which is awesome! But how do you know there aren't
more lurking in the bitcoin codebase -- that is the nature of a
vulnerability -- no one knows it exists until it does! We have found two
vulnerabilities of this nature in the last 1.5 years! That is alarming to
me. I don't think we should change rules to the protocol that can
exacerbate this flavor of vulnerabilities when we are still regularly
finding them.

Maybe this is where we differ in visions for bitcoin. It seems to me you
that are willing to accept much more technical risk than bitcoin currently
has. If the p2p network goes down or consensus fails we can get a group of
people together (probably the people that started segwit2x) to dictate what
the state of the ledger is. Is that a fair representation of your views?

I envision bitcoin to be an autonomous system that does not need humans
directly interacting with the protocol to determine what the state of the
ledger is.

-Chris

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