[Bitcoin-segwit2x] SegWit2x Hard Fork Testing Update

Jeff Garzik jeff at bloq.com
Thu Jul 13 13:27:45 UTC 2017


As stated ~20 hours ago, segwit2x will not merge a change that breaks all
wallets.

Opt-in mechanisms are welcome.


To all debaters:  Let's not get caught in attempting to divine motivations
of various posters.   Treat each suggestion, including hard fork bit
proposals such as James', on their merits.





On Thu, Jul 13, 2017 at 8:47 AM, Jared Lee Richardson via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> > if there are multiple valid headers chains
>
> Right, a condition that could happen with bip148, bip149, or any
> chainsplit, or if a group forked off today.
>
> The tradeoffs between breaking support for spv nodes versus giving them an
> easier choice of chain selection is a political one.
>
> On Jul 13, 2017 8:39 AM, "James Hilliard" <james.hilliard1 at gmail.com>
> 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
>
>


-- 
Jeff Garzik
CEO and Co Founder
Bloq, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170713/a9ffeff0/attachment.html>


More information about the Bitcoin-segwit2x mailing list