e544413c0d
fed3cf6f0ewallet: Replace CWalletTx's vOrderForm with specific fields (Ava Chow)4f8823e8e1wallet: Drop vOrderForm from CommitTransaction (Ava Chow)a2b0bfcd85wallet: Drop mapValue from CWalletTx (Ava Chow)cb99864c91wallet: Throw if unknown entry is found in mapValue (Ava Chow)98d5cdae66wallet: Make CWalletTx "replaces_txid" and "replaced_by_txid" member variables (Ava Chow)7ef8a6efc2wallet: Make CWalletTx "comment" and "to" member variables (Ava Chow)2155e913d3wallet: Make CWalletTx "from" and "message" member variables (Ava Chow)c6ba98dcc8wallet: Drop mapValue from CommitTransaction (Ava Chow)00abb174a8wallet: Pass comment and comment_to to CommitTransaction (Ava Chow)1a219a37a2wallet: Pass replaces_txid to CommitTransaction outside of mapValue (Ava Chow) Pull request description: `mapValue` and `vOrderForm` are opaque data structures that contain transaction metadata. It is hard to determine what actual data each field contains, and they can ostensibly be misused where metadata is added in the future without developers realizing that such metadata exists. It's much clearer to have all of that metadata live in their own explicit member variables within `CWalletTx`. This PR implements that change. Since the serialization format of `CWalletTx` depends on `mapValue` and `vOrderForm`, the serialization remains unchanged, so when serializing these new members, they need to be shoved/extracted from a temporary `mapValue` or `vOrderForm`. This does end up breaking forwards compatibility as unknown fields in `mapValue` and `vOrderForm` are stripped out if the record is rewritten. However, I don't expect that we would continue to use these fields for future metadata, so I think that risk is low. ACKs for top commit: ajtowns: reACKfed3cf6f0ew0xlt: ACKfed3cf6f0ewith above nits/caveats. Eunovo: ACKfed3cf6f0eTree-SHA512: c7deab5aaeac13656012f8b13c0161fd420d2a5348eebd7649310e78ccb1216995aa6a7cbd506ac8d11d7b46b0856d6e6a897bc39965b51cfcf2268356ace261
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.