[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Moe Adham moe at bitaccess.co
Tue Oct 10 15:06:28 UTC 2017


Agreed, Thanks Mike.

Many of us are on this mailing list to stay informed about the technical
requirements in supporting S2X. We may not all agree if it is going to
happen, or why; for those of us with businesses to run, we need to keep our
customers happy regardless the outcome (we all have customers in both
camps).

For that reason, it would be really beneficial if we could have one mailing
list on this subject that is strictly related *strictly to technical
details of this software version*, versus continuous political chatter.

--
*Moe Adham, MSc, BEng **|* Co-Founder

*bitaccess.co <http://www.bitaccess.co/>*
Cell: *+1 858 877 3420*

On Tue, Oct 10, 2017 at 10:52 AM, Mike Belshe via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> 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-transacti
>> on-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-s
>> egwit2x
>> >>> >
>> >>> >
>> >>> >
>> >>> > _______________________________________________
>> >>> > 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 <(408)%20718-6885>
>
> _______________________________________________
> 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/5fa91fe6/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list