[Bitcoin-segwit2x] SegWit2x Hard Fork Testing Update

Thu Jul 13 02:16:30 UTC 2017

> and when they look over the list archives your actions may call into
question whether due care was taken here,

Great, I encourage it.  I suggested early on that the hardfork should
probably have replay protection, and it was decided not do that.  I don't
know that I've specifically changed my mind on that point, I just accepted
that the WG just felt confident enough in their unity that they expect the
legacy chain to fully stop.  No recent data has shaken that belief;
segwit2x support signalling continues to rise, and moderates on both rbtc
and rbitcoin continue to support segwit2x and argue in favor of it.

> considering it from an exchange or
wallet perspective where they may feel they have a fiduciary or legal
responsibility to protect both halves.

Those who have that level of responsibility can run nodes on both chains
and identify any discrepancies that occur, if any do.  Moreover, most of
them are represented here on this list, and they were not shy about
requesting that BU add replay protection.  No one spoke up when I suggested
replay protection before, nor have they since.

This thread was about the hardfork bit, and now it has become about replay
protection.  The hardfork bit is not a very good argument and makes almost
no difference.  That I oppose and will continue to oppose.

Replay protection I am inclined to agree with, but if that were being done
then the activation of segwit should have happened on bit4 only and
required an upgrade to the segwit2x client.  In my opinion, no one should
take advantage of the compromise activated segwit if they do not agree to
the compromise.  That change could enable segwit and phase in the replay
protection for the hardfork and position most users for a smoother hardfork.

That accomplishes every goal that you and Peter describe, yet somehow I get
the feeling that you would not support using a bit4-only activation, just
like so many other pro-core people opposed the bit4-only segwit activation
when I brought that up before.  Correct me if I am wrong there.

Those are plenty safe, so if you don't like those ideas still, the only
conclusion I can reach is that none of these arguments are ACTUALLY about
safety, they are about control.  Sorry, that's not a good reason.  The
group made the decision on the replay protection long ago, and it is
unlikely to change.  The hardfork bit unnecessarily breaks spv clients for
reasons that are not good enough to justify that change.  As Jeff said, if
there is a signal we can use that will not break that spv clients, that's
worth discussing.  I haven't seen any suggestions to that effect since he
proposed that idea.

Jared

On Jul 12, 2017 9:07 PM, "Dr Adam Back" <adam at blockstream.com> wrote:

Jared

It may help if you try to think about things neutrally and try putting
on the hat of either chain, or considering it from an exchange or
wallet perspective where they may feel they have a fiduciary or legal
responsibility to protect both halves.  You are projecting opinions
which are heavily biased and it appears to be colouring your ability
to think clearly about safety.  What you want may not happen, or it
may be inverted to the way you hope it would play out; there are
likely billions of dollars of HODLers money that has the opposing view
to yourself.  They may not appreciate your animosity towards their
financial interests, and when they look over the list archives your
actions may call into question whether due care was taken here, should
that become relevant.

I don't know if it has occurred to you but the cavalier attitude about
other people's interests, actually exacerbates the chances of a split,
because it forces people to defend their financial interests - it is
better to act calmly, professionally and with care for people's value
whether you have the same priority for medium security retail or for
self-sovereign bearer ecash.  In reality we really do not know where
the HODLers come down in dollar terms.  Consider that the risks being
contemplated to rush a hard-fork, are almost entirely motivated by
reducing fees and getting a bit more scale for retail use cases -
conversely investors are not as sensitive to fees, and are quite risk
averse, and even some invested in bitcoin to hedge some types of risks
- if forced by a chain split trigged by actions of the NYA group, they
may choose the more conservative chain with more experienced
developers, security first, and an atmosphere of due diligence and
care.

Anyway I thought you might benefit from the perspective of trying to
swap hats, as if you were playing chess and thinking about black's
perspective and then white - but with respective empathy for their
interests - there are no winners in a chain split, but being uncaring
and derogatory of other peoples interests, increases the chance of a
chain split.

Adam

ps Which company do you work for if you don't mind asking?

On Thu, Jul 13, 2017 at 1:21 AM, Jared Lee Richardson via
Bitcoin-segwit2x <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>> even though you're well aware that it risks users losing money.
>
> It does not do this any more than a replay protected fork would, in fact
it
> is likely to be safer the way it is now.  As things stand now, most
> transactions will appear on both chains if there are two viable chains and
> then the new state can become clear.
>
> If we did what you are suggesting, instead immediately every merchant
would
> need to decide and communicate which chain to use to every user.  That's
> pointlessly messy since the legacy fork is unlikely to be viable, and will
> create a mess just as big even if it is.
>
>> Adding either after the split happens is a classic case of closing the
>> door after the horse is bolted - the losses have already happened.
>
> Adding it before complicates users behavior, wallet and merchant
> interactions, the fork itself, and much much more, and at this point looks
> very unlikely to be needed.
>
> You need to be honest here.  If your concern was genuinely for users
> hardships, you wouldn't be fighting this the way you are.  You're fighting
> it for your own egotistical reasons and trying to play it off as if it
were
> concern for users.
>
> Be honest.  If there are going to be two viable chains, it is going to be
> messy no matter what.  The only reason there would be two viable chains
when
> the consensus is nearly unanimous against you is what you are doing right
> here, right now.
>
> The things you're demanding are not going to be done here, and it's
> dishonest to pretend that you're looking out for the users best interests.
> The users best interests would be your support and genuine assistance even
> though you aren't getting exactly what you wanted.  Go review your tweets;
> your actions are not selfless.
>
> Personally, I find it frustrating that my last response even agreed with
> your points in part, and your response did nothing of the sort.  It
doesn't
> seem like you are interested in a discussion, your purpose seems to be
> trying to force things that hurt this project, or simply trying to make
this
> project look bad.  Hasn't two years of this shit been enough for you?
Where
> does it end?
>
> Jared
>
> On Jul 12, 2017 7:36 PM, "Peter Todd" <pete at petertodd.org> wrote:
>
> On Wed, Jul 12, 2017 at 03:23:31PM -0700, Jared Lee Richardson wrote:
>> > I'd suggest you step back, take a deep breath, and think about this
from
>> the perspective of what happens where there does exist two chains
>>
>> You are absolutely correct on that point, and that is why I said
>> advantages
>> and disadvantages, and also why I said rational people could
>> disagree(despite my misgivings, I would definitely argue that both you
and
>> Mr. Maxwell are rational people).
>>
>> In the event that two viable chains survive, you would be correct, a
>> hardfork bit would probably be desirable.  I've said as much in the
github
>> in the last few days though you may not have seen that comment.  Indeed,
>> in
>> that case replay protection would also be needed.
>>
>> This too is not without precedent; it happened with eth/etc and was
solved
>> by the minority chain finally adding two way replay protection.  Based on
>> what happened with BU and ETC, I believe the exchanges will unanimously
>> demand that the minority chain (as best as they can decide that) add
>> replay
>> protection.  If segwit2x's support remains as strong and broad as it
>> appears to be now, they may demand that from the legacy chain.  If
>> segwit2x
>> is as weak as you and core hopes, they will demand it of us.
>>
>> We cannot know whether two viable chains will result.  The decisions that
>> are the best option for one case are not the best decisions for the other
>> case.  The decision has been made here, and for sound reasons.  Your
>> objections are sound as well, but from a different set of concerns and
>> desires.
>
> Right, so it sounds like the attitude here is to maintain a false sense of
> compatibility even though you're well aware that it risks users losing
> money.
>
> From a users perspective, they want their funds to be safe, while segwit2x
> has
> made technical choices that are greatly increases the risk to users of
> losing
> money and being defrauded, apparently for the sake of increasing adoption
of
> segwit2x.
>
>> To address your concerns, if we wind up in a two-viable chain situation
>> where the exchanges are demanding that s2x adds replay protection, it can
>> be added at that point.  Likewise if we end up in the situation I
>> described(stuck chain), then Luke-Jr can add a hardfork bit and replay
>> protection to that fork(and the exchanges will require it).  This is not
>> an
>> intractable problem that cannot be addressed in the future.
>
> The time to add replay protection is *prior* to the split, not after.
> Equally,
> the time to add protections to lite clients is prior to the split. Adding
> either after the split happens is a classic case of closing the door after
> the
> horse is bolted - the losses have already happened.
>
> Equally, it's the professional responsibility of the group making the
> protocol
> change - the segwit2x group - to address these issues.
>
> What is the plan right now to ensure that lite clients aren't defrauded
when
> segwit2x's hard-fork results in a chain split? What is the plan to ensure
> user's are defrauded through replay attacks?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
>
>
> _______________________________________________
> 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/20170712/1d714f97/attachment-0001.html>