BCH UX Suggestion: Mandatory CashAddr for P2SH

2019-01-08T22:15:41.000Z Honest Cash


Bitcoin Cash split from Bitcoin Core when the latter was about to activate SegWit. It also shared the same address format, and SegWit addresses are often in the pay-to-script-hash (P2SH) form (starting with 3) that also works on Bitcoin Cash, but of course Bitcoin Cash doesn't actually support SegWit. This let to people accidentally sending BCH to SegWit addresses, creating a transaction output on the Bitcoin Cash chain that "anyone can spend", provided one knows the public key behind the script hash. Safe recovery of these BCH coins consequently required cooperation with a trusted miner, as it does not involve a signature.

As of January 2018, Bitcoin Cash has its own address for the P2SH format named CashAddr (starting with q or p) that does not work on Bitcoin Core. Meanwhile on Bitcoin Core, native SegWit addresses (starting with bc1) have become more popular, which are not in the P2SH form and thus do not work on Bitcoin Cash. These accidents have therefore become easier to avoid. However, because some Bitcoin Cash services have been slow or reluctant to switch to the new CashAddr format, many wallets still support sending BCH to addresses in the legacy format, which could potentially be SegWit addresses. The accidents can thus still happen.

A plot twist

Perhaps surprisingly, the recent November 2018 upgrade of Bitcoin Cash made the problem worse. Namely, the BCH coins resulting from an accident are now "no-one can spend" instead of "anyone can spend", so even a trusted miner can no longer recover them for you. This is a side effect of the new clean stack rule that partially solves third-party malleability.

Third-party malleability is a man-in-the-middle attack where any relay node can modify some parts of the contents of a transaction as it gets relayed, without involvement of the sender, receiver, or even miners. This complicates handling 0-conf transactions and is obviously something we want to solve, but now some people fear about loss of BCH coins in SegWit accidents and consider reversing the rule change.

The sustainable solution

The much simpler and much more sustainable solution to this problem is to end the SegWit accidents once and for all. I think this is surprisingly easy:

Refuse sending BCH transactions to addresses starting with a 3.

Bitcoin Cash services that don't yet support CashAddr likely use pay-to-public-key-hash (P2PKH) legacy addresses (starting with 1). These have no risk of SegWit accidents and wallets can continue to accept them as inputs. The most common use case of P2SH (starting with 3) other than SegWit is legacy multi-signature wallets, but their usage is relatively rare, especially for hot wallets. Refusing sending transactions to addresses starting with 3 will thus have minimal impacts on backward compatibility, while it completely eliminates SegWit accidents.

So, in short:

  • Bitcoin Cash wallets should refuse sending funds to P2SH addresses in legacy format (starting with 3). Any option to override this should be hidden in advanced wallet settings where no noob can accidentally disable this safeguard.

  • Bitcoin Cash address convertors should warn to not send funds to P2SH addresses converted from legacy format (starting with 3) to CashAddr format (starting with p). Such address conversion should only be used to analyse transaction history, not for creating new transactions.

  • In rare cases Bitcoin Cash users still encounter P2SH addresses in legacy format (starting with 3), they should ask for an address in CashAddr format before sending any funds.

This allows Bitcoin Cash to move forward without risking irrecoverable loss of funds.


RE: BCH UX Suggestion: Mandatory CashAddr for P2SH

by @Big_Bubbler

I think I like this idea, but, I am not educated well enough on the situation to be sure. My main reason for commenting is to suggest you put this in the BCH or Bitcoin Cash discussion sections. I don't yet know if comments can be moved once placed, but, I hope so and think it should be possible.