[Bitcoin-segwit2x] Bitcoin Cash's mandatory replay protection - an example for B2X

I should also add this isn't about giving one chain preferential treatment. It's just deployment logistics. Adding replay protection to legacy chain requires full redeployment of all network infrastructure whereas adding it to the hard fork chain is just a few lines of code since the hard fork software needs to be fully redeployed anyhow. It's a purely practical matter. For the sake of reducing harm to users and businesses, it would be best to have a peaceful split. I would be happy to assist in ensuring as peaceful a split as possible. --- Eric On Tuesday, August 22, 2017, Eric Lombrozo <eric at ciphrex.com> wrote: > To be clear, it isn't up to any of us. A good portion of the community > wants to keep the legacy chain. NYA signers are free to create a hard fork, > but not adding replay protection suggests intent to destroy the legacy > chain. As long as a lot of people still want the legacy chain, attempts to > destroy it will be treated as an attack on the property of all these > people. It constitutes a serious cyberattack and decisive action against > it, both technical and legal, has been prepared. > > --- > Eric > > On Tuesday, August 22, 2017, Eric Lombrozo <eric at ciphrex.com > <javascript:_e(%7B%7D,'cvml','eric at ciphrex.com');>> wrote: > >> This is not going to happen. Sorry. >> >> Kind regards, >> Eric >> >> On Monday, August 21, 2017, Emil Oldenburg via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> As one of the signers of the New York Agreement, Bitcoin.com is strongly >>> against replay protection for the November 2xHF. >>> >>> If replay protection is added and it's similar to Bitcoin Cash, the New >>> York Agreement will die and the hard fork will never actually happen. This >>> is the latest tactic from the Core camp to kill the hard fork. >>> >>> The problem is relayed transactions is not new and has been well known >>> by everyone who signed the agreement. The spirit of the agreement was to >>> get a super majority support for the hard fork, enough to bring non-signers >>> over to the hard forked chain as the legacy chain would quickly be >>> abandoned. The difficulty of the bitcoin network is so high right now that >>> if 90% hard forks, the legacy chain will in practice be unusable. Exchanges >>> can only list activate and usable chains. >>> >>> There is a reason Luke-Jr and a few other Core supporters are preparing >>> for a PoW change, because they know this. >>> >>> Adding replay protection that breaks all wallets is a no go. Gavin's >>> op-return method is good enough, and Core can easily add a soft fork to >>> Core that works in a similar way. The replay protection responsibility >>> falls on to the minority chain, not the majority. >>> >>> >>> Emil Oldenburg, CTOEmil at bitcoin.com >>> Visit the all new https://bitcoin.com >>> Wechat: emilold >>> Telegram: emilold >>> >>> On 2017年08月22日 03:14, Gabriel Kurman via Bitcoin-segwit2x wrote: >>> >>> Dear all, >>> >>> Sergio, Diego and myself have been discussing the potential implications >>> of the November 2xHF and its lack of replay protection upon all the recent >>> information from Bcash and the reaction of the ecosystem. Below you will >>> find a summary of our thoughts. >>> >>> >>> New info: >>> >>> - The Bcash fork was successful and not contentious >>> - It was received as "free money" by Bitcoiners and the users seem >>> to be cool with ViaBTC >>> - All exchanges/wallets are working to make the coins available >>> - No major attacks have been registered and now both chains seem to >>> be working without permanent contentious attacks from the competing miners >>> - Bcash plans to launch an aggressive pipeline of innovation Schors, >>> Drivechain, Emergent consensus, LN and merge-mining to promote its use/price >>> - The ecosystem has now more development >>> diversification/decentralization >>> - Price of BTC + BCash > Original BTC >>> - *REPLAY PROTECTION (RP) was key for all the points addressed >>> before.* >>> - Bcash proved that is fairly easy and quick to add RP >>> - Past evidence shows that the name seems to stay with Devs/Repo >>> (happened with ETH and Bcash) >>> >>> Why are we worried: >>> >>> - The current version of the NYA does not include RP >>> - Without RP, at the HF there will be a lot of uncertainty and >>> confusion. Users & exchanges will be forced to halt their >>> transactions/trading until there is a clear outcome of the fork >>> which we think may take up to 2 weeks. >>> - Users willing to transact will be loosing their tokens in some of >>> the chains >>> - The NYA will probably be perceived as an attack on the users >>> - Users will be disappointed for not having their tokens >>> duplicated >>> - An endless war will be started between both groups, minimizing >>> the chances of independent Core developers contributing to the btc1 repo >>> - Even without RP it is hard to predict how the ecosystem will call >>> the 2x token >>> - *It is unclear how many of the original signatories of the NYA >>> still support it today given the new info and the no RP* >>> >>> Why btc1 should include RP: >>> >>> - Having RP on the NYA would bring the following benefits: >>> - Trading will not be stopped (reducing the ETH flippening risk >>> or BTC price collapse) >>> - Bitcoiners will love it for duplicating their tokens >>> - Market will expect Price of BTC + BTC2x > Original BTC >>> - Both teams will compete in terms of innovation, security, >>> services to users and lower fees >>> - There will not be a significant incentive for miners/holders to >>> attack the competitive chain. >>> - It will be easier for devs to contribute to both teams/repos >>> - Eventually the most successful blockchain will be called >>> Bitcoin in the long term >>> - Potential liabilities (?): All exchanges (specially those publicly >>> signing the NYA) should discuss with their technical and legal teams how >>> they are going to make the Core tokens available once their users claim them >>> >>> >>> Given that very few details has been discussed with the NYA signatories >>> back in May, it is very important to clarify whether having REPLAY >>> PROTECTION is open to discussion or not, so all signatories can >>> confirm/reject their support to the NYA. >>> >>> >>> Our goal has always been to try to keep the ecosystem together >>> protecting the network effect, however if a separation is inevitable, at >>> least it should be done in a way that protects users interests at all costs >>> . >>> >>> If the btc1 group agrees to include REPLAY PROTECTION, we would be happy >>> to allocate resources to collaborate in the development or testing of it. >>> >>> >>> >>> >>> >>> 2017-07-25 19:35 GMT-03:00 Jared Lee Richardson via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org>: >>> >>>> > We do not know what the views of the hashing power are; hashing power >>>> is free >>>> > to move from one pool to another, and can do so in a matter of >>>> minutes. >>>> >>>> That's fallacious logic. If individual miners indeed did not wish to >>>> support segwit2x, continuing to mine to a pool that signed support >>>> over a month ago and has been signaling support for weeks wouldn't >>>> make any sense - their inaction only makes support for segwit2x seem >>>> STRONGER. The fact that miners have not done the thing you are >>>> claiming that miners will do taking a matter of minutes is strong >>>> evidence that you're speculating without any evidence. >>>> >>>> Can you provide evidence that indicates miners are currently mining to >>>> a pool who'se agenda they do not support? >>>> >>>> Because if not, I can provide evidence showing the opposite. Slush, >>>> the only pool not signed/signaling /NYA/, was ~5% of the hashrate 1 >>>> month ago and is now 2.5% of the hashrate. If what you are saying is >>>> true that number would be going up, not down. Please provide evidence >>>> to support your claims. >>>> >>>> > that situation still allows for coins to be bought and sold >>>> >>>> Where? >>>> >>>> No exchange has stated they will support the legacy chain as bitcoin >>>> instead of the most-work chain. Moreover, 5% of the hashrate is not >>>> only insufficient to process anything approaching our current volume >>>> of transactions (even with segwit!), it is also a highly unstable >>>> equilibrium - Given the extreme lack of blocks, many neutral users >>>> will abandon it immediately, and any miners without strong convictions >>>> will abandon it within hours to protect their investments, making the >>>> slow blocks problem even worse. >>>> >>>> Even worse than that, the only significant pool I can find that isn't >>>> signaling /NYA/ has historically always allowed its' miners to vote, >>>> and doesn't own many miners to back its own convictions. That 5% >>>> hashrate itself may be split, weakening what was already nowhere near >>>> enough hashrate for viability. >>>> >>>> > The Ethereum chain was left with even less hashing power >>>> > immediately after the bailout fork - nearly 0% - but hashing power >>>> rapidly >>>> >>>> You mean like minutes afterwards? Because that wasn't true days >>>> afterwards. Regardless, Ethereum is not a good comparison, it >>>> continuously adjusts difficulty and wouldn't be stuck for 6+ months, >>>> and miners are already applying the new rules and indicating they are >>>> running the HF code. >>>> >>>> Please provide evidence of your claims. >>>> >>>> Jared >>>> >>>> On Tue, Jul 25, 2017 at 3:03 PM, Peter Todd <pete at petertodd.org> wrote: >>>> > On Tue, Jul 25, 2017 at 09:02:25AM -0700, Jared Lee Richardson wrote: >>>> >> Right now between signalling and signatories, btc1 has ~95% of the >>>> >> hashpower. ~5% of the hashpower is not enough to be viable without a >>>> >> hardfork, in which case it would be more appropriate and less >>>> damaging for >>>> > >>>> > The signalling has been done by mining *pools*, not hashing power. >>>> > >>>> > We do not know what the views of the hashing power are; hashing power >>>> is free >>>> > to move from one pool to another, and can do so in a matter of >>>> minutes. >>>> > >>>> > Equally, even if Bitcoin was left with just 5% of the hashing power, >>>> and B2X >>>> > with 95%, that situation still allows for coins to be bought and >>>> sold, with an >>>> > unknown outcome. The Ethereum chain was left with even less hashing >>>> power >>>> > immediately after the bailout fork - nearly 0% - but hashing power >>>> rapidly >>>> > moved from the bailout chain back to the Ethereum chain in response >>>> to market >>>> > demand. >>>> > >>>> > -- >>>> > https://petertodd.org 'peter'[:-1]@petertodd.org >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>> >>> >>> >>> -- >>> Gabriel Kurman >>> Co-Founder >>> >>> www.RSK.co >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing listBitcoin-segwit2x at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170822/1abb37aa/attachment-0001.html>