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

Jacob Eliosoff jacob.eliosoff at gmail.com
Mon Aug 21 19:11:50 UTC 2017


I don't think anyone is against adding replay protection.  The question is
how to implement it cleanly without giving one chain or the other
preferential treatment.  If an old non-upgraded wallet sends a tx after the
split, how are the two chains supposed to know which one the user
intended?  Assuming *either* one will harm some users.

I've argued before for making txs include a "chain marker", and then making
each chain reject txs with another chain's marker.  This leaves open the
question of what to do with txs without a marker (ie, from non-upgraded
software), but at least this approach would ensure *upgraded* senders avoid
replay effects.  For the legacy txs, there are nuances but I'd advocate,
say, making both chains reject them for the month after the split.

I don't think adding 1x-favoring replay protection is such a terrible
idea.  I just think 1. *symmetric* protection is strongly preferable and 2.
fallout from not implementing any protection is probably being exaggerated;
the ecosystem has a lot more time to prepare and a lot more experience than
in the ETC/ETH case, and even those problems were short-lived.


On Aug 21, 2017 2:31 PM, "Jeff Garzik via Bitcoin-segwit2x" <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> Replay protection is absolutely open for discussion.
>
> Further, it is an open issue at github, which is the standardized way to
> track specific open issues for a project:  https://github.com/btc1/
> bitcoin/issues/34
>
> This is, definitionally, Proof-of-Replay-Protection-Open-For-Discussion.
>  ;p
>
>
> On Mon, Aug 21, 2017 at 2:14 PM, Gabriel Kurman via Bitcoin-segwit2x <
> bitcoin-segwit2x at lists.linuxfoundation.org> 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 list
>> Bitcoin-segwit2x at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>
>>
>
>
> --
> Jeff Garzik
> CEO and Co Founder
> Bloq, Inc.
>
>
> _______________________________________________
> 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/20170821/935e51f2/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list