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

Emil Oldenburg emil at bitcoin.com
Tue Aug 22 03:00:01 UTC 2017


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, CTO
Emil 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
>       o The NYA will probably be perceived as an attack on the users
>       o Users will be disappointed for not having their tokens duplicated
>       o 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:
>       o Trading will not be stopped (reducing the ETH flippening risk
>         or BTC price collapse)
>       o Bitcoiners will love it for duplicating their tokens
>           + Market will expect Price of BTC + BTC2x > Original BTC 
>       o Both teams will compete in terms of innovation, security,
>         services to users and lower fees
>       o There will not be a significant incentive for miners/holders
>         to attack the competitive chain.
>       o It will be easier for devs to contribute to both teams/repos
>       o 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
> <mailto: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
>     <mailto: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
>     <http://petertodd.org>
>     _______________________________________________
>     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>
>
>
>
>
> -- 
> Gabriel Kurman
> Co-Founder
>
> www.RSK.co <http://www.RSK.co>
>
>
> _______________________________________________
> 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/20170822/1fcb9934/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list