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

Tue Aug 22 08:03:30 UTC 2017

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> 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
> <javascript:_e(%7B%7D,'cvml','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/4af74ac4/attachment-0001.html>