[Bitcoin-segwit2x] SegWit2x Hard Fork Testing Update

Thu Jul 13 15:27:53 UTC 2017

Are the BreadWallet guys or anyone else representing a major SPV wallet on
the list? It'd be good to hear from those closest to the issue re: safety
concerns.

--
Matt Luongo
foldapp.com

On Thu, Jul 13, 2017 at 7:33 AM, Alex Petrov via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> Growing amount of SPV nodes is the next issue what we should solve quote
> soon & ASAP.
> Right now they seriously impact productivity & connectivity of full nodes.
> Also you 100% right SPV clients doesn't has any methods how to check chain
> validity & check full node what they connect to.
>
> Currently SPV as-is.
>
> 5 days full node stat, tier-1 (2x ipv4/1x ipv6 )
> 76342 connections
>
> = latest block (0...-100 blocks ) 9579 nodes only
> Short connections (<<20sec) or blocks <<473000 (more 2000 blocks away) -
> 65429
>
> 14979 - seed probes (19% connections)
> 1700 failed handshake
> 12042 - errors (socket/reset by peer/timeout)
>
> 988 - UASF
>
> 15965 - Misbehaving
>
> SPV -
> 1246 - Multibit 5.18/HD
> 4169 - bitcoinj
> 18423 - breadwallet
> 287 - /btcwire
> 486 - libbitcoin
> 36712 - AWS-SPV  52.0.0.0
>
>
> > On Jul 13, 2017, at 15:38, James Hilliard via Bitcoin-segwit2x <
> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> >
> > SPV clients not validating blocksize is the main issue in regards to
> > why they are broken if a mandatory large block is used for wipeout
> > protection, SPV clients detect the chain they are supposed to be on by
> > following the most work valid headers chain, if there are multiple
> > valid headers chains(but with different chain rules other than
> > headers) then SPV clients will be broken since they will not be able
> > to differentiate the chains, this is mostly a technical issue. Using a
> > HF bit fixes this issue since SPV clients would then be able to
> > determine the intended chain to follow by looking at the HF bit in the
> > header.
> >
> > On Thu, Jul 13, 2017 at 2:16 PM, Jared Lee Richardson
> > <jaredr26 at gmail.com> wrote:
> >> Spv clients don't care about blocksize.  Any reasons for or against
> breaking
> >> support for them would be political in nature, not technical.
> >>
> >> On Jul 13, 2017 7:05 AM, "James Hilliard via Bitcoin-segwit2x"
> >> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> >>>
> >>> The wipeout protection method used is completely broken for lite
> >>> clients and leaves them vulnerable to fraud, because of that nobody
> >>> should use a lite client without connecting it to their own full node.
> >>> Peter Todd was making the point that there should be wipeout
> >>> protection for lite clients and that they should not be left
> >>> vulnerable, I've yet to see any reasonable rational for leaving lite
> >>> clients vulnerable, especially since using the mandatory large block
> >>> requirement wipeout protection method is far more complex and failure
> >>> prone than just using the HF bit.
> >>>
> >>> On Thu, Jul 13, 2017 at 4:56 AM, Emil Oldenburg via Bitcoin-segwit2x
> >>> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> >>>> On 2017年07月13日 06:18, Peter Todd via Bitcoin-segwit2x wrote:
> >>>>
> >>>> On Wed, Jul 12, 2017 at 01:59:12PM -0700, Jared Lee Richardson wrote:
> >>>>
> >>>> Given the lack of consensus, it's hard to predict in
> >>>>
> >>>> advance what percentage of hashing power will be allocated to either
> >>>> side.
> >>>>
> >>>> Uh, no, we know quite well what the support is in advance.  84% signed
> >>>> on,
> >>>> 91% currently signalling, and that's without slash pool enabling s2x
> >>>> voting
> >>>> yet.  So > 91% on s2x, < 9% on legacy.  That means that the legacy
> chain
> >>>>
> >>>> There is nothing preventing that distribution from changing in the
> >>>> future.
> >>>> Equally, what you call "signalling" is not in fact signalling, just a
> >>>> non-technical show of support that could be easily withdrawn or
> modified
> >>>> with
> >>>> no major impact.
> >>>>
> >>>> After all, if it's 100% guaranteed for segwit2x to have a majority of
> >>>> hashing
> >>>> power, why was wipeout protection added? There's no need for it in the
> >>>> event
> >>>> that segwit2x remains at a majority of hashing power.
> >>>>
> >>>> People from the Core camp have many times mentions that lack of
> wipeout
> >>>> protection as something negative. Now when it's added, they still
> >>>> complain.
> >>>> Peter Todd is engaging in a master suppression technique called
> "double
> >>>> bind".
> >>>>
> >>>> https://en.wikipedia.org/wiki/Master_suppression_techniques#
> Double_bind
> >>>>
> >>>>
> >>>>
> >>>> will spend nearly 6 months before they reach the first difficulty
> change
> >>>> to
> >>>> get the chain unstuck, assuming every bit of the non signalling miners
> >>>> both
> >>>> stay behind and don't defect.
> >>>>
> >>>> Even in the worst case, the chain isn't "stuck", it's slow. While
> >>>> multi-hour
> >>>> confirmations would suck for many use-cases, they still don't prevent
> >>>> people
> >>>> from buying the coin, and thus supporting miners mining it. Equally,
> if
> >>>> such
> >>>> a
> >>>> market develops hashing power can very quickly move from one chain to
> >>>> another.
> >>>>
> >>>> While segwit2x has support by many, although certainly not all,
> >>>> companies,
> >>>> it's
> >>>> as yet unclear what Bitcoin owners will support, and thus the relative
> >>>> price
> >>>> of
> >>>> both coins. Obviously there's a number of risks to the segwit2x coin,
> >>>> such
> >>>> as
> >>>> the fact that many existing Bitcoin owners will not want to own a coin
> >>>> with
> >>>> an
> >>>> inexperienced dev team without a track record.
> >>>>
> >>>> There's also the problem that the price of a coin is kept high by
> >>>> holders of
> >>>> the coin first and foremost, not non-holding-related retail payments
> >>>> activity.
> >>>> The latter's impact on price decreases as the entire system becomes
> more
> >>>> efficient and the velocity of money increases.
> >>>>
> >>>> It also instantly puts the legacy chain in
> >>>> danger of 51% control from its own miners if it isn't halted by an
> >>>> outside
> >>>> miner attack.
> >>>>
> >>>> Bitcoin has withstood 51% control before, and in fact many believe
> there
> >>>> likely
> >>>> is 51% control by Bitmain right now. Fortunately the PoW and
> incentives
> >>>> security model is quite resiliant with multiple layers of protection.
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> > _______________________________________________
> > Bitcoin-segwit2x mailing list
> > Bitcoin-segwit2x at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>
>
> --
> THIS COMMUNICATION AND ANY ATTACHMENTS MAY CONTAIN CONFIDENTIAL
> INFORMATION OF THE SENDER. ALL UNAUTHORIZED USE, DISCLOSURE OR DISTRIBUTION
> IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE NOTIFY THE
> SENDER IMMEDIATELY AND DESTROY ALL COPIES OF THIS COMMUNICATION. THANK YOU.
> _______________________________________________
> 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/20170713/e09b12fe/attachment.html>