{"id":3550,"date":"2019-12-23T11:39:25","date_gmt":"2019-12-23T11:39:25","guid":{"rendered":"https:\/\/bitcoinsv.io\/?p=3550"},"modified":"2020-09-28T10:36:03","modified_gmt":"2020-09-28T10:36:03","slug":"bitcoin-sv-blocking-potential-p2sh-replay-attack-after-genesis-hard-fork","status":"publish","type":"post","link":"https:\/\/bitcoinsv.io\/2019\/12\/23\/bitcoin-sv-blocking-potential-p2sh-replay-attack-after-genesis-hard-fork\/","title":{"rendered":"Bitcoin SV \u2013 Blocking potential P2SH replay attack after Genesis hard fork"},"content":{"rendered":"\n
The Bitcoin SV Node team notes the recent public disclosure on\nReddit by Gregory Maxwell (a.k.a. \/u\/nullc) from the Bitcoin Core (BTC) of a\npotential replay attack vector on Bitcoin SV after the \u201cGenesis\u201d hard fork in\nFebruary 2020 which will be deprecating the P2SH (pay-to-script-hash) feature\nthat is not part of the Bitcoin design described by Satoshi Nakamoto.<\/p>\n\n\n\n
The post describes a possible theft via replay attack of P2SH\n(pay-to-script-hash) transactions from the BTC chain that could be executed to\nsteal unsplit funds of BTC users on the Bitcoin SV chain. The Bitcoin SV\nmission is to return Bitcoin to the vision described in Satoshi\u2019s whitepaper\nwhich uses the word \u201chonest\u201d no less than 15 times and we emphatically reject the\nnotion that obvious theft of coins by miners can fall within the definition of \u201chonest\u201d\nbehaviour.<\/p>\n\n\n\n
We note that Mr. Maxwell\u2019s\npublic disclosure in no way fits the broadly accepted definition of\n\u201cresponsible disclosure\u201d and by describing in detail the steps required to\nexploit and potentially cause loss of funds to BTC users, we would deem it both\nirresponsible to BTC users and poor security practice. Had the disclosure been made responsibly\naccording the guidelines set out in the Bitcoin SV Responsible Disclosure Policy<\/a>, it likely would have been eligible for a\nsubstantial bug bounty. It is\nparticularly puzzling to the BSV Node team that the disclosure was made in this\npublic way by a BTC core developer given the users most likely put at greater\nrisk by the disclosure are not <\/em><\/strong>those actively engaged with BSV,\nbut primarily those that are BTC users who may not even be interested in BSV. <\/p>\n\n\n\n We note for the record that the Bitcoin SV Node team has\npreviously made responsible\ndisclosures<\/a> to the Bitcoin Core and Bitcoin Cash development teams and intend\nto continuing to do so as part of our commitment to professionalizing Bitcoin\nsoftware development.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n We note for the record that Mr. Maxwell\u2019s post did bring to\nour attention some aspects of this issue that the Bitcoin SV team had not yet fully\nconsidered. So we thank him for the\ntechnical review and shedding some new light on the matter. <\/p>\n\n\n\n In fact, this event demonstrates that the public review\nprocess implemented by the Bitcoin SV team, in advance of finalizing the code\nin early January, is achieving the intended goal of improving security outcomes\nfor the ecosystem.<\/p>\n\n\n\n In response, the Bitcoin SV Node team will update the \u201cGenesis\u201d\nhard fork specification by upgrading the rule rejecting the P2SH script pattern\nfrom a policy rule to a consensus rule<\/strong>. \nThat is the specific script template \u201cOP_HASH160 <hash> OP_EQUAL\u201d\nwill not be allowed in new outputs and this rule will be directly implemented\nin the Bitcoin SV Node software. Whilst\nunfortunate to restrict the usage of a particular script pattern, we note that\nthe same effect can be achieved using variations of the script pattern e.g.\n\u201cOP_SHA256 OP_RIPEMD160 <hash> OP_EQUAL\u201d.<\/p>\n\n\n\n This change closes the attack vector and mitigates the need\nfor honest miners to forcibly reject blocks containing theft transactions. Whilst this could have triggered a valuable\ndemonstration of the principle of honest miners acting punitively against dishonest\nminers, the public disclosure by Mr. Maxwell raises the potential cost to those\nminers to an unacceptable level.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n 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\/<\/a> <\/p>\n\n\n\nMitigation<\/h2>\n\n\n\n
Segwit script pattern<\/h3>\n\n\n\n
Bug Bounty<\/h2>\n\n\n\n