This PR proposes to introduce a new interface to allow applications and second layers protocols to verify that their unconfirmed and non-propagated transactions are valid under Bitcoin Core transaction relay policy.
This new libstandardness interface is designed at the image of the bitcoinconsensus library, which already exposes some of the script verification internals to other applications. A new method is introduced libstandard_verify_transaction which indicate to the caller if the transaction is valid, i.e can propagate at current chain tip. For now, the policy rules as considered as a “black box”, there is no detail (i.e TxValidationState::m_reject_reason) on thepolicy rule violated.
This interface allows second layers like contracting protocols relying on pre-signed transactions and efficient propagation over the network mempools for the security of user funds. E.g for the Lightning Network, counterparties are exchanging signatures for the commitment transaction and second-stage HTLCs during the BOLT2’s commitment_signed message dance. A policy invalid commitment transaction with pending HTLC outputs not propagating on the network can be source of failure, a serious vulnerability for a Lightning implementation as CVE-2020-26895 showed it. Beyond being source of loss of funds, a policy rule violation can be a source of liquidity griefing for a Lightning node participating in a collaborative transaction flow (dual-funding / splicing), where inputs/outputs are freely added by the counterparties.
For some contracting protocols, where the pre-signed txn are malleable by the counterparty it doesn’t seem computationally plausible to testmempoolaccept all the combinationd valid under the protocol template and this would still assume some changes in our current transaction validation interface to bypass some stateful checks such as timelocks and mempool min fee.
As of today, there is no straightforward software tooling for applications and second-layers to verify the validity of the policy rules of their transactions, and most of implementations to the best of my knwoledge are re-implementing the policy rules in their backend, or delegate this verification to their bitcoin libraries. Such re-implementation is sometimes imperfect, must be updated at each Bitcoin Core policy rules changes (e.g packages policy rules) and be adapted for each protocol transaction templates (e.g for Lightning, commitment tx, second-stage tx, closing_tx, collaborative tx, legacy/anchor/taproot).
The proposed interface is introduced as a shared library rather than a RPC interface, as ideally policy rules could be enforced on embedded / resource constrained platforms such as L2 signers enforcing security rule validation of the second layer state machine (and from where one should be able to extract propagating pre-signed transactions in case of emergency recovery) and generally allow for more flexibility for applications and second layers, e.g on mobile phone where a full-node is not assumed (all caveats reserved on the lower security model in that latter case).
This interface has been proposed in the past, see previous PRs
Opening the PR for now to collect conceptual and implementation-approach feedbacks. If the new interface is judged as relevant and useful, I’ll add bindings in rust-bitcoin to test the interface end-to-end with adequate Lightning software.
TODO:
- write documentation for language bindings write in
doc/shared-libraries.mdand maybe indoc/policy/ - integrate as a config flag only feature in build system (e.g
BUILD_BITCOIN_LIBSTANDARDNESSinsrc/Makefile.amandconfigure.ac) - initialize the chainstate and its associated mempool with the spent utxos
- some other things
