[Bitcoin-segwit2x] SegWit2x Hard Fork Testing Update

[James Hilliard]

BIP148 is mandatory nversion signaling so that chain can be identified by
lite clients since nversion is in the header. Using something not in the
header like a large block to split the chain appears to be an attempt to
exploit a vulnerability in the lite client validation model however.

On Jul 13, 2017 2:48 PM, "Jared Lee Richardson" <jaredr26 at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170713/4d0ee11b/attachment-0001.html>