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

Eric Lombrozo eric at ciphrex.com
Tue Aug 22 07:52:27 UTC 2017


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 <javascript:_e(%7B%7D,'cvml','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/decentralizati
>    on
>    - 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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.org <javascript:_e(%7B%7D,'cvml','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/c4e6e6d8/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list