Please note, this is a STATIC archive of website bitcoinsv.io from October 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.
Bitcoin SV – Blocking potential P2SH replay attack after Genesis hard fork
by Steve Shadders
December 23, 2019 (5min read)
The Bitcoin SV Node team notes the recent public disclosure on Reddit by Gregory Maxwell (a.k.a. /u/nullc) from the Bitcoin Core (BTC) of a potential replay attack vector on Bitcoin SV after the “Genesis” hard fork in February...

The Bitcoin SV Node team notes the recent public disclosure on Reddit by Gregory Maxwell (a.k.a. /u/nullc) from the Bitcoin Core (BTC) of a potential replay attack vector on Bitcoin SV after the “Genesis” hard fork in February 2020 which will be deprecating the P2SH (pay-to-script-hash) feature that is not part of the Bitcoin design described by Satoshi Nakamoto.

The post describes a possible theft via replay attack of P2SH (pay-to-script-hash) transactions from the BTC chain that could be executed to steal unsplit funds of BTC users on the Bitcoin SV chain. The Bitcoin SV mission is to return Bitcoin to the vision described in Satoshi’s whitepaper which uses the word “honest” no less than 15 times and we emphatically reject the notion that obvious theft of coins by miners can fall within the definition of “honest” behaviour.

 We note that Mr. Maxwell’s public disclosure in no way fits the broadly accepted definition of “responsible disclosure” and by describing in detail the steps required to exploit and potentially cause loss of funds to BTC users, we would deem it both irresponsible to BTC users and poor security practice.  Had the disclosure been made responsibly according the guidelines set out in the Bitcoin SV Responsible Disclosure Policy, it likely would have been eligible for a substantial bug bounty.  It is particularly puzzling to the BSV Node team that the disclosure was made in this public way by a BTC core developer given the users most likely put at greater risk by the disclosure are not those actively engaged with BSV, but primarily those that are BTC users who may not even be interested in BSV.

We note for the record that the Bitcoin SV Node team has previously made responsible disclosures to the Bitcoin Core and Bitcoin Cash development teams and intend to continuing to do so as part of our commitment to professionalizing Bitcoin software development.

The Bitcoin SV team had been previously aware of variations of this attack vector and did in fact have a plan in place to mitigate it, in part involving a coalition of honest miners forcibly rejecting blocks that contain obvious theft attempts in order to protect the integrity of the chain. We note that this mechanism has subtle but important differences to an explicit consensus rule although has a similar effect. However, due to this public disclosure and explicit description of the method, we believe there is now a significantly higher risk of a dishonest miner attempting to execute this theft attack with a large amount of hashpower and consequently the economic cost to honest miners of implementing the proposed mitigation method is likely to be substantially higher as well. As such the Bitcoin SV team has determined that a stronger mitigation is now required.

We note for the record that Mr. Maxwell’s post did bring to our attention some aspects of this issue that the Bitcoin SV team had not yet fully considered.  So we thank him for the technical review and shedding some new light on the matter.   

In fact, this event demonstrates that the public review process implemented by the Bitcoin SV team, in advance of finalizing the code in early January, is achieving the intended goal of improving security outcomes for the ecosystem.

Mitigation

In response, the Bitcoin SV Node team will update the “Genesis” hard fork specification by upgrading the rule rejecting the P2SH script pattern from a policy rule to a consensus rule.  That is the specific script template “OP_HASH160 <hash> OP_EQUAL” will not be allowed in new outputs and this rule will be directly implemented in the Bitcoin SV Node software.  Whilst unfortunate to restrict the usage of a particular script pattern, we note that the same effect can be achieved using variations of the script pattern e.g. “OP_SHA256 OP_RIPEMD160 <hash> OP_EQUAL”.

This change closes the attack vector and mitigates the need for honest miners to forcibly reject blocks containing theft transactions.  Whilst this could have triggered a valuable demonstration of the principle of honest miners acting punitively against dishonest miners, the public disclosure by Mr. Maxwell raises the potential cost to those miners to an unacceptable level.

Segwit script pattern

To address an additional but unrelated issue related to native Segwit transaction replay an additional measure will be taken. This will be detailed in a later post.

An update to the Genesis hard fork specification will be published shortly and the code changes included in the next beta release of Bitcoin SV.  Release notification will occur through the usual channels noted here: https://bitcoinsv.io/genesis-hard-fork/

Bug Bounty

We take this opportunity to remind the security research community of the substantial bug bounty program offered by Bitcoin SV with a maximum reward of up to $100,000 USD (payable in BSV), rivalling the largest bug bounty programs in the world offered by multinational technology giants.

We offer a top-tier bug bounty program in order to encourage further scrutiny, review and responsible disclosures from all parties.  Gregory Maxwell is of course eligible to participate so long as he adheres to principles of Responsible Disclosure in the future.

Articles