OP_RETURN for coin-splitting?

The current way we do coin-splitting in ElectrumSV has some minor issues. The user may get errors that we cannot reproduce. They might need to split more often than the faucet allows. The faucet might be unresponsive due to people performing denial of service attacks on it. Or it might be empty due to overuse, or malicious people draining it.

It would be good to look at alternative ways of coin-splitting, that do not necessarily rely on including known BSV dust coins, and might take advantage of some other mechanism. We don’t have to stop offering the dust method, we can offer an alternative.

I am not a Bitcoin expert. I write these articles mainly to both record my thoughts and conclusions from research, and also to solicit feedback. I’m not 100% sure this article is correct, so please call me out loudly if it isn’t and let me know how.

Pre-Genesis BSV and BCH outputs

Output script evaluation

Both BSV and BCH share the same behaviour for transaction outputs that were confirmed before the BSV Genesis upgrade. If during the evaluation of the output script an OP_RETURN opcode is encountered, the script evaluation fails with an error.


When a block is mined, all the outputs are processed and added as UTXOs, even 0-value ones. The sole exceptions are those outputs that are classified as unspendable. For outputs mined before the BSV Genesis upgrade, on BCH these are any scripts that start with the OP_RETURN opcode, and on BSV these are any scripts that start with either the OP_RETURN opcode, or OP_FALSE OP_RETURN.

Post-Genesis BSV and BCH outputs

Output script evaluation

For BSV transaction outputs, an OP_RETURN stops the evaluation successfully. You can put an OP_RETURN on the end of a P2PKH script, and whether the spend succeeds or not would simply reflect whether that P2PKH script would successfully spend anyway without it.

It will no longer be possible to have 0-value non-UTXO scripts that start with OP_RETURN, these are now considered spendable and must meet the dust requirements in terms of their value. The only output scripts that can be 0-value are those that start with OP_FALSE OP_RETURN.

Mempool acceptance and unspendability

BCH still retains the notion of non-standard transactions. A script that is solely (or starts with for that matter) OP_FALSE OP_RETURN is non-standard on two different measures. The most obvious measure is that it is not one of their standard script types, as it does not match their acceptable “data carrier” template which requires starting with OP_RETURN not OP_FALSE (and it is obviously not P2PK, P2PKH, P2SH or bare multi-signature).

The next measure is that the only criteria for unspendability is that the script starts with OP_RETURN. This is obviously not met, which means that the value of the output is no longer allowed to be zero. Only “unspendable” transactions can have a value of zero, all other transactions must have at least the dust value (which is something like 400 or 500 satoshis).

This means that even if a transaction with an output that has a script that starts with OP_FALSE OP_RETURN is broadcast to BCH nodes, they will reject it. But the thing with non-standard transactions, is that miners can solicit them and include them in a block. Let’s explore that.


What if a malicious miner did collect these transactions and mine them, what would happen?

Each zero value OP_FALSE OP_RETURN output would be as unspendable as every other OP_RETURN script on BCH. But the difference is that since they do not actually meet the official “unspendable” criteria, which to recap only includes scripts that start with OP_RETURN the outputs would go in the UTXO set and would remain there with the other zero value outputs that were mined in the past when it was legal.

How would the BCH community respond? Would the miner have to mine their blocks as anonymously as possible in order to avoid the stigma of being called out for this behaviour?

Refocusing on coin-splitting

The goal with coin-splitting is to do something on the Bitcoin SV blockchain that safely moves a user’s BSV, without it also moving on the BCH blockchain.

Examining malicious mining

My understanding is that a malicious miner can mine almost anything that we might put into an output script in BSV. Even opcodes that are invalid on BCH, but are valid on BSV. If the transaction output has a value, then those coins are burned on BCH. Further, if the value is high enough and the script is custom, we have to know how to find it when searching for key usage while we still do seed-based restoration. If the value is just above dust, it is still a value which is lost and is that really necessary? What if we want to tag lots of transactions — maybe even every transaction — the user will be burning dust in each.

The problem with the malicious mining of non-standard transactions, is that if it happens all the coins in the transaction move on both blockchains. This complicates the coin-splitting process because if it is something we need to watch out for, which is not necessarily true, then the user can be told they are coin-splitting and unwittingly move the coins on both chains leaving them unsplit.

Keep in mind that a malicious miner cannot tell who they are messing with, is it a BCH or BTC user who is splitting off their BSV to sell? Is it a BSV user who wants to split their BCH away? There’s no attack on BSV here, it’s an attack on all users who have BSV. How feasible is it to check every single transaction that is rejected from the mempool for whether it is also viable to try and mine?

Is OP_FALSE OP_RETURN the best option?

Conveniently on BSV, OP_FALSE OP_RETURN is meaningless in and of itself. It is a throwaway output. And on BCH it is ignored without a malicious miner. It costs the user no dust on either blockchain beyond the fee for the output itself. And if it is mined on BCH beyond the complications to a process of successful coin-splitting, what does the user care — the BCH blockchain accrues garbage UTXO entries.

If we can design the process so that there are clear steps for the user to tell if their coins split successfully, using both ElectrumSV and Electron Cash, perhaps this is acceptable.

Obligatory OP_FALSE OP_RETURN in every transaction

There’s a school of thought that wallet recovery and wallet backup can make use of OP_FALSE OP_RETURN outputs. Now imagine that every transaction you make has one or more of these with encrypted data added to the end. Every transaction becomes non-standard on BCH, and further splits the users coins.

Final thoughts

I’ve spent the day reading over both Bitcoin ABC and Bitcoin SV source code, and I am not 100% sure I have understood it correctly. Please let me know if my understanding is flawed.

Beyond any discussion that eventuates this will go on the backburner while I complete the remaining user interface work for the 1.3.0 release.

Points of contact:

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store