[Bitcoin-segwit2x] replay protection and spinoffs vs collaboration

Jared Lee Richardson jaredr26 at gmail.com
Tue Jul 25 21:57:37 UTC 2017


> 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
>


More information about the Bitcoin-segwit2x mailing list