e3b026bf56
9784818442mining: add getTransactionsByWitnessID() IPC method (Sjors Provoost)d282ae6883mining: add getTransactionsByTxID() IPC method (Sjors Provoost)0d5e4d4712test: restart node after IPC option override test (Sjors Provoost)f16b3613cdipc: Serialize null CTransactionRef as empty Data (Sjors Provoost)0f466e1094mempool: add lookup by witness hash (Sjors Provoost) Pull request description: For Stratum v2 custom job declaration to be bandwidth efficient, the pool can request[^0] only the transactions that it doesn't know about. The spec doesn't specify how this is achieved, but one method is to call the `getrawtransaction` RPC on each transaction id listed in [DeclareMiningJob](https://stratumprotocol.org/specification/06-Job-Declaration-Protocol?query=DeclareMiningJob#644-declareminingjob-client-server) (or a subset if the pool software maintains a cache). Using RPC is inefficient, made worse by the need to make multiple calls. It also doesn't support queuing by witness id (yet, see #34013). This PR introduces two new IPC methods: - `getTransactionsById()`: takes a list of `Txid`'s - `getTransactionsByWitnessID()`: : takes a list of `Wtxid`'s Both return a list of serialised transactions. An empty element is returned for transactions that were not found. Unlike the RPC counterpart, the IPC methods do not take advantage of `-txindex`. This could be done in a followup. For `Wtxid` that would involve adding a `-witnesstxindex`. I thought about having a single (or overloaded) `getTransactions()` that works with both `Txid` and `Wtxid`, but I prefer that clients are intentional about which one they want. A unit and functional test cover the new functionality. Sv2 probably only needs `getTransactionsByWitnessID()`, but it's easy enough to just add both. To rest with Rust use: - https://github.com/2140-dev/bitcoin-capnp-types/pull/11 [^0]: there's two reasons the pool requests these transactions: to approve the template and to broadcast the block if a solution is found (the miner will also broadcast via their template provider). See also https://github.com/stratum-mining/sv2-spec/issues/170 ACKs for top commit: achow101: ACK9784818442sedited: Re-ACK9784818442ViniciusCestarii: Re-ACK9784818442ismaelsadeeq: Code review ACK9784818442Tree-SHA512: 3c6ceb572ab7d8bd090a8f31b5e331304a7a19a3d1f1551c9c2e1ee41339d76f96ca6c41bd634c87fca0a969e7d9bfa6a16c26fb06c0dd2315f6ca1c76a16a31
Internal c++ interfaces
The following interfaces are defined here:
-
Chain— used by wallet to access blockchain and mempool state. Added in #14437, #14711, #15288, and #10973. -
ChainClient— used by node to start & stopChainclients. Added in #14437. -
Node— used by GUI to start & stop bitcoin node. Added in #10244. -
Handler— returned byhandleEventmethods on interfaces above and used to manage lifetimes of event handlers. -
Init— used by multiprocess code to access interfaces above on startup. Added in #19160. -
Ipc— used by multiprocess code to accessInitinterface across processes. Added in #19160. -
Rpc— used bybitcoin-clito be able to call RPC methods over a unix socket instead of TCP.
The interfaces above define boundaries between major components of bitcoin code (node, wallet, and gui), making it possible for them to run in different processes, and be tested, developed, and understood independently. These interfaces are not currently designed to be stable or to be used externally.