[Bitcoin-segwit2x] replay protection and spinoffs vs collaboration

[Jeff Garzik]

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
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170725/d08b82f6/attachment-0001.html>