[Bitcoin-segwit2x] replay protection and spinoffs vs collaboration

Tue Jul 25 22:04:22 UTC 2017

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