[Bitcoin-segwit2x] SegWit2x Hard Fork Testing Update

[Jared Lee Richardson]

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

Oh, and I work for no company right now, though I'm not sure why it matters.
I don't need to for the time being, in no small part thanks to bitcoin.

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/f37b0de1/attachment.html>