rpc: prevent non-zero value OP_RETURN outputs in sendrawtransaction

maflcko commented at 9:24 am on August 22, 2022: member

While some protocols require value attached to OP_RETURN outputs, this otherwise seems like a mistake.

Setting the value to 0 should really be done by the wallet/script creating the transaction (like createrawtransaction does for data outputs). However, as an additional check, similar to the high-fee check, sendrawtransaction could also check for non-zero value OP_RETURN outputs.

This should be configurable by a new RPC argument.

Useful skills:

Bitcoin Core RPC code
Transaction output types
Bitcoin Core functional tests

Want to work on this issue?

For guidance on contributing, please read CONTRIBUTING.md before opening your pull request.

maflcko added the label RPC/REST/ZMQ on Aug 22, 2022

maflcko added the label good first issue on Aug 22, 2022

bitcoin deleted a comment on Aug 22, 2022

sristis0202 commented at 5:45 pm on August 24, 2022: none

Hi! I would like to work on this. Please assign

amritabithi commented at 1:32 am on August 28, 2022: none

Considering all of the applications using nonzero outputs in op_return, wouldn’t it make more sense to just have an option to prune this before saving it to disk? Would it not be better to deal with one optional flag on the node instead of complicating countless apps that are already using the previously assumed behavior? Nothing is gained through this change that cannot be accomplished with existing pruning code for op_return, unless I am misunderstanding something.

achow101 commented at 2:46 am on August 28, 2022: member

Considering all of the applications using nonzero outputs in op_return

It’s unclear to me why any application needs to use non-zero op_returns. It is literally just burning money. While there are some applications where burning money is the point, I don’t think we should really be encouraging/enabling those. Just because someone uses a particular feature does not mean it is necessarily good or worth keeping. Furthermore, I would not be surprised if many of those applications are burning money accidentally. A few developers I have spoken to were surprised that 0 value op_returns were allowed because they were not aware of the exception to the dust limit for op_returns. Application developers may have the same misconception.

wouldn’t it make more sense to just have an option to prune this before saving it to disk?

Disk space is not the concern. Whether the amount is 0 or something else doesn’t matter, it still takes up the same amount of space. We’re already pruning op_returns from the UTXO set. Rather the point is to add a protection for users. The purpose is to prevent users from accidentally burning money. In general, we should erect barriers to users throwing away their money as it is often done by accident.

ghost commented at 6:05 am on August 28, 2022: none

It’s unclear to me why any application needs to use non-zero op_returns. It is literally just burning money. While there are some applications where burning money is the point, I don’t think we should really be encouraging/enabling those.

Why is burning an issue? Projects that do proof of burn and similar things won’t be able to use sendrawtransaction and figure out other ways to broadcast transactions.

maflcko commented at 6:45 am on August 28, 2022: member

Please read the description. It says “This should be configurable by a new RPC argument.” So everyone can still burn as much money as they want after they toggle the value of the new RPC optional argument.

ghost commented at 7:46 am on August 28, 2022: none

Sorry I misunderstood the issue and linked pull request. I thought all non zero OP_RETURN would get rejected.

glozow renamed this:
~~rpc: Reject non-zero value OP_RETURN outputs in sendrawtransaction~~
rpc: prevent non-zero value OP_RETURN outputs in sendrawtransaction
on Aug 29, 2022

officialfrancismendoza commented at 8:36 pm on February 22, 2023: none

I’d like to work on this. Please assign

achow101 closed this on Feb 23, 2023

ShitcoinsSuck commented at 6:22 pm on June 21, 2023: none

This change breaks RPC client libraries and applications, and potentially everything downstream of them.

One example–electrum wallet allows non-zero sends to OP_RETURN. There are valid use cases for this. This is broken in bitcoin 25.0 because to add the new argument would require changes to everything downstream of bitcoin core, including rust-bitcoincore-rpc, electrs, and electrum wallet. It could theoretically be hacked in by having a default setting at the direct client of the bitcoin core rpc (rust-bitcoincore-rpc in this case), but this would be a hack.

It might make more sense to either remove this new argument or change the default to 21quadrillion sats. This allows the downstream users to decide the level of “protection” they want vs prior bitcoin versions, rather than forcing the change on them.

maflcko commented at 7:00 pm on June 21, 2023: member

rust-bitcoincore-rpc

(Just picking the first example). This is also broken if you wanted to send 1BTC to fees, because the rust interface doesn’t set any options, looking at the current code: https://github.com/rust-bitcoin/rust-bitcoincore-rpc/blob/7bd815f1e1ae721404719ee8e6867064b7c68494/client/src/client.rs#L1081

I don’t think there is another solution other than to update the libraries and programs you are using when updating Bitcoin Core. Sure, if it is possible to avoid breaking the RPC interface, it should be considered. However, if there is a valid feature and it requires breaking the interface and reviewers are happy with that, I don’t see why the feature should be held back or removed after a release.

Generally it is not supported to use a library or program that speaks a different RPC protocol than the version of Bitcoin Core you are using, and I don’t think this is possible to achieve in general or should even be a goal to attempt.

If you want to learn more about the RPC interface, you can also read the docs: https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md#versioning

bitcoin locked this on Jun 20, 2024

rpc: prevent non-zero value OP_RETURN outputs in sendrawtransaction #25899

Useful skills:

Want to work on this issue?