crapstream
kiwifarms.net
I've decided to start this thread as a general discussion for anything relating to Bitcoin SV Original Satoshi Vision
Bitcoin SV – Blocking potential P2SH replay attack after Genesis hard fork
https://bitcoinsv.io/2019/12/23/bit...al-p2sh-replay-attack-after-genesis-hard-fork
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.
“The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.”
Satoshi Nakamoto
Wallets
● Electrum SV ● Atomic Wallet ● Bitaddress ● Bitpie ● CashPay Wallet ● Centbee ● coinomi ● Edge ● Exodus ● Guarda ● HandCash ● Hivr ● Hodler Tech ● IPayYou ● NextCash ● Pixel Wallet ● Simply Cash
Exchanges
● Okex ● Huobi Global ● BitHumb ● HitBTC ● Poloniex ● Gate.io ● Bitfinex ● Bittrex ● Korbit ● Kucoin ● YoBit
● FreeBitcoins XChange ● Electrum SV ● Atomic Wallet ● Bitaddress ● Bitpie ● CashPay Wallet ● Centbee ● coinomi ● Edge ● Exodus ● Guarda ● HandCash ● Hivr ● Hodler Tech ● IPayYou ● NextCash ● Pixel Wallet ● Simply Cash
Exchanges
● Okex ● Huobi Global ● BitHumb ● HitBTC ● Poloniex ● Gate.io ● Bitfinex ● Bittrex ● Korbit ● Kucoin ● YoBit
White paper
https://bitcoinsv.io/bitcoin.pdf
Hard Fork Latest Updates
https://bitcoinsv.io/genesis-hard-fork
Applications
● Bitcoin ATM ● Bitcoinplayspokemon ● Bitcoin Token ● Bitcoin Rewards ● Bitek ● Bitstocks ● CashPay ● Circle Invest ● Cryptograffiti ● Crypto Traders Pro ● Faucenet ● Fivebucks ● GifterCash ● GoUrl Bitcoin Payment Gateway ● GPS Tracker Shop ● Honey Badger ● Keyport TV ● Lighthouse ● Matter ● Money Button ● Netcoins ● Pedlr ● Premier Medical, Inc. ● Search BSV ● Tokenized ● Yours
Block Explorers
● WhatsOnChain ● Blockchair ● BestMiningPool ● SVBlox ● Huge+Block ● Tokenview BSV Explorer ● bchsvexplorer ● Bitfire ● Bitcoin Cash SV Explorer ● Bitcoin SV Explorer ● BSV Explorer ● BSV Test Net Explorer ● Satoshi IO
Developer Tools
● Oyo ● Trends ● BitcoinJ ● Nakasendo sdk ● bitdb ● BitSocket ● BSV JavaScript Library ● BSV DEVS ● DataPay ● Keyring Javascript Libraries
https://bitcoinsv.io/bitcoin.pdf
Hard Fork Latest Updates
https://bitcoinsv.io/genesis-hard-fork
Applications
● Bitcoin ATM ● Bitcoinplayspokemon ● Bitcoin Token ● Bitcoin Rewards ● Bitek ● Bitstocks ● CashPay ● Circle Invest ● Cryptograffiti ● Crypto Traders Pro ● Faucenet ● Fivebucks ● GifterCash ● GoUrl Bitcoin Payment Gateway ● GPS Tracker Shop ● Honey Badger ● Keyport TV ● Lighthouse ● Matter ● Money Button ● Netcoins ● Pedlr ● Premier Medical, Inc. ● Search BSV ● Tokenized ● Yours
Block Explorers
● WhatsOnChain ● Blockchair ● BestMiningPool ● SVBlox ● Huge+Block ● Tokenview BSV Explorer ● bchsvexplorer ● Bitfire ● Bitcoin Cash SV Explorer ● Bitcoin SV Explorer ● BSV Explorer ● BSV Test Net Explorer ● Satoshi IO
Developer Tools
● Oyo ● Trends ● BitcoinJ ● Nakasendo sdk ● bitdb ● BitSocket ● BSV JavaScript Library ● BSV DEVS ● DataPay ● Keyring Javascript Libraries
Bitcoin SV – Blocking potential P2SH replay attack after Genesis hard fork
https://bitcoinsv.io/2019/12/23/bit...al-p2sh-replay-attack-after-genesis-hard-fork
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.
“The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.”
Satoshi Nakamoto
