[Bitcoin-segwit2x] replay protection and spinoffs vs collaboration

Tue Jul 25 20:34:53 UTC 2017

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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:Bitcoin-segwit2x at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x>
> 
> 
> 
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org <mailto:Bitcoin-segwit2x at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170725/a666d206/attachment-0001.html>