[Bitcoin-segwit2x] replay protection and spinoffs vs collaboration

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