[Bitcoin-segwit2x] replay protection and spinoffs vs collaboration

Jared Lee Richardson jaredr26 at gmail.com
Tue Jul 25 23:07:57 UTC 2017


>  /r/bitcoin is quite fine - except if you are suggesting that absolutely ALL contra-HF posts are faked - which is quite laughable.

No, I'm suggesting that they are a minority (though not a trivial
minority) in a place which has a massive selection bias to the point
where its measures can't be relied upon.  There would be no way to
compare the vocal opposition's "votes" in /r/bitcoin against the vocal
support in forums.bitcoin.com or among non-english-speaking users.

> Beside this I’m talking in several slack groups the last months (> 2000 people in these channels) and most of the time we are discussing hard and soft forks - and around 95% of the people are against a (rushed!) HF.

Again, not very useful for proving the strength of support, especially
since slack usually revolves around less than 10 people talking at any
given time, generally a few loudmouths like me who talk constantly and
would give an incorrect perception of support.  But at least if you
polled those people thoroughly and clarified the biases inherent in
the slack itself, that would be **SOME DATA** so I think it could be
helpful.  But as it stands now, just saying the people you talk to are
against a HF isn't evidence of anything except that you tend to
associate with the vocal opposition, which we could have already
guessed.

> Do you really want to imply that there are no existing people existing which are against this HF???

No, I never said anything to that effect.  I stated that they appear
to be a small minority of Bitcoin users.  You do realize that Coinbase
has signed up more than 100,000 accounts in a single day, right?  6000
votes on a sybilable twitter poll is strong evidence of just how few
people actually care about this debate either way.

Moreover, the vast majority of even those who oppose the hardfork will
likely switch to segwit2x when the alternative is an unusable chain
that has no value because it isn't accepted on exchanges.  This is the
same exact reason that bigblockers failed to actually hardfork away
for the past 1.5 years - Disagreeing with consensus is very very risky
and costly.

Jared

On Tue, Jul 25, 2017 at 3:49 PM, Peter BitcoinReminder.com
<segwit2x_mailinglist at bitcoinreminder.com> wrote:
> Why is it the worst metric?
>
> I only have to proof that there is NO consensus!
>
> /r/bitcoin is quite fine - except if you are suggesting that absolutely ALL
> contra-HF posts are faked - which is quite laughable.
>
> I doubt that you really want to imply this?
>
> Beside this I’m talking in several slack groups the last months (> 2000
> people in these channels) and most of the time we are discussing hard and
> soft forks - and around 95% of the people are against a (rushed!) HF.
>
> So feel free to believe me or not - but this discussion is getting
> ridiculous somehow.
>
> Do you really want to imply that there are no existing people existing which
> are against this HF???
>
> Am 26.07.2017 um 00:42 schrieb Charlie Shrem <charlie at decentral.ca>:
>
> Peter,
>
> r/bitcoin is by the worst metric you can have for "consensus".
>
> Please use quantifiable sources.
>
> Charlie
>
> On Tue, Jul 25, 2017 at 6:30 PM, Peter BitcoinReminder.com via
> Bitcoin-segwit2x <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>
>> I just see problems with your logic - because it’s quite simple:
>>
>> If there is consensus - no replay protection is necessary.
>> If there is no consensus - replay protection is necessary.
>>
>> Since there are many bitcoiners which don’t want a (rushed) HF - and I
>> talk also to many people directly these days - there is no consensus.
>>
>> So if you really want to HF - do it. But please do it in a safe way for
>> everyone - and please don’t be to lazy to code and offer new types of
>> wallets for this.
>>
>> > Am 26.07.2017 um 00:24 schrieb Jared Lee Richardson
>> > <jaredr26 at gmail.com>:
>> >
>> >> Lol. Just look at /r/bitcoin about the HF consensus.
>> >
>> > So your datapoint for support is a place that bans people for arguing
>> > against supporting it?
>> >
>> > And you don't see any problems with this logic?
>> >
>> > On Tue, Jul 25, 2017 at 3:04 PM, Peter BitcoinReminder.com
>> > <segwit2x_mailinglist at bitcoinreminder.com> wrote:
>> >> Lol. Just look at /r/bitcoin about the HF consensus.
>> >> You can’t negate this just by writing nice novels here.
>> >>
>> >>> Am 25.07.2017 um 23:57 schrieb Jared Lee Richardson
>> >>> <jaredr26 at gmail.com>:
>> >>>
>> >>>> a HF has no consensus at the moment as you can clearly see
>> >>>
>> >>> As in the other thread, please provide data to back this claim, or
>> >>> stop making it if you aren't going to support it.  A few minutes ago I
>> >>> gave examples of how someone could support that claim, and also
>> >>> provided several more datapoints indicating that the HF does indeed
>> >>> appear to have strong consensus among the measurable and relevant
>> >>> evidence.
>> >>>
>> >>>> it's also unprofessional to force all wallets to add proper replay
>> >>>> protection within 3 months.
>> >>>
>> >>> I'm not sure how you think that they would need to do this, or even
>> >>> how you think they could do it, so please explain.  Even so, the
>> >>> segwit2x team is approaching and discussing with the wallet providers
>> >>> as evidenced in the btc1 compatibility documentation on Github a few
>> >>> days ago.
>> >>>
>> >>> Jared
>> >>>
>> >>> On Tue, Jul 25, 2017 at 1:34 PM, Peter BitcoinReminder.com via
>> >>> Bitcoin-segwit2x <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>> >>>> I agree with Adam, you should add replay protection to ensure that
>> >>>> the
>> >>>> Segwit2x HF chain works as expected, even if the supporting hash rate
>> >>>> drops
>> >>>> and there will be a continuous hard fork.
>> >>>> In general: a HF has no consensus at the moment as you can clearly
>> >>>> see and
>> >>>> it's also unprofessional to force all wallets to add proper replay
>> >>>> protection within 3 months.
>> >>>>
>> >>>> Am 25.07.2017 um 21:39 schrieb John Heathco via Bitcoin-segwit2x
>> >>>> <bitcoin-segwit2x at lists.linuxfoundation.org>:
>> >>>>
>> >>>> I'd echo Jared's comments.  If we're looking at the overwhelming
>> >>>> majority of
>> >>>> hashing power and economic players supporting segwit2x, the legacy
>> >>>> chain
>> >>>> will be forced to update their codebase in order to reset difficulty.
>> >>>> In
>> >>>> that case it would make sense for that fork to implement replay
>> >>>> protection
>> >>>> if it's foreseen to be an issue.
>> >>>>
>> >>>> We haven't seen any evidence to support the view that there will be a
>> >>>> significant chunk of hashing power supporting the non-2x chain.  That
>> >>>> may
>> >>>> change in the upcoming weeks or months, but is definitely not the
>> >>>> case now.
>> >>>> 90%+ of blocks are still signaling intention to support NYA.
>> >>>>
>> >>>> On Tue, Jul 25, 2017 at 12:22 PM, Jeff Garzik via Bitcoin-segwit2x
>> >>>> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>> >>>>>
>> >>>>> A proposal that breaks all wallets has been rejected multiple times.
>> >>>>>
>> >>>>> Please review the mailing list archives since you appear to have
>> >>>>> missed
>> >>>>> this point.
>> >>>>>
>> >>>>> Repeating a rejected proposal over and over again just wastes
>> >>>>> everybody's
>> >>>>> time.
>> >>>>>
>> >>>>>
>> >>>>> On Jul 25, 2017 3:13 PM, "Dr Adam Back" <adam at blockstream.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> Yes, implement replay protection following BCC lead.  +1 to Peter
>> >>>>>> Todd's
>> >>>>>> comments.
>> >>>>>>
>> >>>>>> Also I provided (and others have similarly also provided) detailed
>> >>>>>> technical argument for why a number of your rationales are in
>> >>>>>> balance
>> >>>>>> incorrect, and so you're reaching the wrong conclusions.
>> >>>>>>
>> >>>>>> In IETF like process "Jeff" doesn't get to clobber technical
>> >>>>>> objections
>> >>>>>> by waving a wand, nor by ignoring inconvenient technical argument.
>> >>>>>>
>> >>>>>> Thanks
>> >>>>>>
>> >>>>>> Adam
>> >>>>>>
>> >>>>>>
>> >>>>>> On Tue, Jul 25, 2017 at 8:02 PM, Jeff Garzik <jeff at bloq.com> wrote:
>> >>>>>>>
>> >>>>>>> Adam,
>> >>>>>>>
>> >>>>>>> Do you have a specific technical proposal?
>> >>>>>>>
>> >>>>>>> This is not a mailing list for generalized sentiments. Please be
>> >>>>>>> specific and productive.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Jul 25, 2017 2:36 PM, "Dr Adam Back via Bitcoin-segwit2x"
>> >>>>>>> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>> >>>>>>>>
>> >>>>>>>> It will create even more work to deal with coins if there is no
>> >>>>>>>> replay
>> >>>>>>>> protection.
>> >>>>>>>>
>> >>>>>>>> It maybe interesting to read the BCC coin github and google-able
>> >>>>>>>> and
>> >>>>>>>> widespread objections to the initial absence of replay protection
>> >>>>>>>> from
>> >>>>>>>> ecosystem companies, probably there is some overlap with NYA
>> >>>>>>>> signers also
>> >>>>>>>> among those companies.  I'm seeing the spinoff as basically
>> >>>>>>>> identical to
>> >>>>>>>> segwit2x proposed HF.  This project could even consider merging
>> >>>>>>>> with them -
>> >>>>>>>> does bitcoin need two spinoffs?  So far theirs seems better able
>> >>>>>>>> to cope
>> >>>>>>>> with replay.
>> >>>>>>>>
>> >>>>>>>> As to the value of the spinoff focussed on medium security/more
>> >>>>>>>> centralised retail coin vs a conservative security and
>> >>>>>>>> decentralisation /
>> >>>>>>>> censorship resistant Bitcoin-current, I think the value
>> >>>>>>>> allocation is
>> >>>>>>>> unpredictable and many may have the wrong intuitions.  One has to
>> >>>>>>>> consider
>> >>>>>>>> what is the allocation of user value ascribed between digital
>> >>>>>>>> gold
>> >>>>>>>> investment thesis vs holding incidental to retail trade.  I think
>> >>>>>>>> coincidentally that Jihan, myself and Trace Mayer (and probably
>> >>>>>>>> others on
>> >>>>>>>> this group) all agree that digital gold investing is the higher
>> >>>>>>>> contributor
>> >>>>>>>> to market value.
>> >>>>>>>>
>> >>>>>>>> Which to be clear is not at all to say that scale isn't
>> >>>>>>>> important: many
>> >>>>>>>> have spent 1000s of hours working on scale within the bitcoin
>> >>>>>>>> project, and
>> >>>>>>>> many companies have volunteered time to accelerate Bitcoin in
>> >>>>>>>> that area, as
>> >>>>>>>> well as their own time.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> I dont think the "field experience" from P2SH nor Litecoin are
>> >>>>>>>> really
>> >>>>>>>> applicable for obvious reasons, many companies who signed the NYA
>> >>>>>>>> agreement
>> >>>>>>>> are themselves ready to go with segwit at some volume.  Others
>> >>>>>>>> are some way
>> >>>>>>>> along.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> I don't think Jeff's views about  compatibility at all costs
>> >>>>>>>> strike a
>> >>>>>>>> sensible balance here.  It's also also confusing and asymmetric
>> >>>>>>>> (some smart
>> >>>>>>>> phone wallets but not others and different from fullnodes).
>> >>>>>>>> There are fewer
>> >>>>>>>> pure SPV wallets left.  More wallets are working relative to a
>> >>>>>>>> hosted and
>> >>>>>>>> managed full node, and in some cases cross checking with SPV
>> >>>>>>>> nodes, and so
>> >>>>>>>> need changes either way.  SPV nodes saying conflicting things
>> >>>>>>>> will cause
>> >>>>>>>> confusion.  As was discussed, segregating DNS seeds does not
>> >>>>>>>> provide any
>> >>>>>>>> meaningful protection.  Effort is being put into tinkering with
>> >>>>>>>> fragile
>> >>>>>>>> best-effort approaches that don't protect users.  Almost all
>> >>>>>>>> smart-phone
>> >>>>>>>> wallets are auto-upgrade.  The rationale for medium security
>> >>>>>>>> use-cases is to
>> >>>>>>>> bring *new users*, they will use *new wallets* by default.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> I consider it more prudent to let BCC run the experiment and
>> >>>>>>>> focus
>> >>>>>>>> instead on optimising what we have, collaborating and adopting
>> >>>>>>>> best
>> >>>>>>>> practices that can significantly increase scale *today* (with no
>> >>>>>>>> bitcoind
>> >>>>>>>> changes) for example transaction batching, hosted netting,
>> >>>>>>>> multisig service
>> >>>>>>>> netting etc.  And make progress on scale via lightning,
>> >>>>>>>> schnorr/MASF, best
>> >>>>>>>> practices, and drivechain/sidechains to make a medium security
>> >>>>>>>> area that
>> >>>>>>>> doesnt have a floating value.
>> >>>>>>>>
>> >>>>>>>> Ecosystem companies would get more done faster along this
>> >>>>>>>> approach and
>> >>>>>>>> more safely too, because much infrastructure is not designed for
>> >>>>>>>> multiple
>> >>>>>>>> coins.  Re-architecting singleton data models in a 3month window
>> >>>>>>>> is putting
>> >>>>>>>> progress on other types of scaling, security and feature
>> >>>>>>>> improvement on
>> >>>>>>>> hold.  Not to mention the confidence hit from the controversy it
>> >>>>>>>> creates.
>> >>>>>>>>
>> >>>>>>>> Adam
>> >>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> 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
>> >>>>
>> >>
>>
>> _______________________________________________
>> Bitcoin-segwit2x mailing list
>> Bitcoin-segwit2x at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>
>
> <Jaxx_Decentral_Signature.png>
>
>


More information about the Bitcoin-segwit2x mailing list