If I use RPC command sendrawtransaction and supply an tx hex that is not acceptable (e.g. 1. if a signature is invalid, 2. contains a double spend) bitcoind will reject it, and if the transaction is verified, bitcoind will then propagate the transaction
It would be great if there could be a RPC call that allows verifyrawtransaction, which means it will only verify the transaction without propagating.
One thing such a feature should have is the ability to take a list of transactions— since you may need to also provide the parents which you also don’t want to broadcast yet.
An interesting question is should it be validating against the blockchain or against the memorypool?
+1 on taking a list of transactions
I feel that it should be validated against the memorypool. In other words, if verifyrawtransaction returns true, then it should be also propagatable with sendrawtransaction
I agree with the general idea, and think this could be pretty useful.
While "decoderawtransaction" can be used to check the structure of transactions, and in a hacky way "signrawtransaction" can be used to verify scripts and signatures, it’s feels more like an incomplete workaround.
A few random use cases that come to my mind, more or less related to this topic:
"verifytxoutproof")Related to the first point is a discussion over at https://github.com/CryptoConsortium/CCSS/issues/15, which indicates that relying on external API providers seems to be pretty common.
It should probably be differentiated between stateless and stateful verification (e.g. consider the mempool, or be able to check transactions to a limited degree with an unsynchronized offline client).
We’ve discussed this on IRC a while ago, and this still seems useful.
One thing such a feature should have is the ability to take a list of transactions— since you may need to also provide the parents which you also don’t want to broadcast yet.
Yes, it should definitely be able to take a list of transactions.
An interesting question is should it be validating against the blockchain or against the memorypool?
Probably either - should be a parameter, like for gettxout.
What is intended by:
validating against the mempool
Do we mean simply checking it against policy? (no double spends, RBF, yada yada)
For information, such feature would be very useful for LN. There is several rule (like dust one) which can make a tx commitment unbroadcastable. This would result into theft.
If such function existed, a LN node would just have to check verifyrawtransaction before releasing the revocation hash of the previous commitment.
Do we mean simply checking it against policy? (no double spends, RBF, yada yada)
See it as the difference between ’take into account 0conf’ (blockchain+mempool) and ‘don’t take into account 0-conf’ (blockchain).
