Expand description
Higher level wallet functions which can be used by callers to operate on the wallet, as well as helpers to invoke and instantiate wallets and listeners
Re-exports§
pub use crate::slate::ParticipantData;pub use crate::slate::ParticipantMessageData;pub use crate::slate::Slate;pub use crate::slate_versions::SlateVersion;pub use crate::slate_versions::VersionedCoinbase;pub use crate::slate_versions::VersionedSlate;pub use crate::slate_versions::CURRENT_SLATE_VERSION;pub use crate::slate_versions::EPIC_BLOCK_HEADER_VERSION;pub use api_impl::owner_updater::StatusMessage;pub use api_impl::types::InitTxArgs;pub use api_impl::types::InitTxSendArgs;pub use api_impl::types::IssueInvoiceTxArgs;pub use api_impl::types::NodeHeightResult;pub use api_impl::types::OutputCommitMapping;pub use api_impl::types::PaymentProof;pub use api_impl::types::SendTXArgs;pub use api_impl::types::VersionInfo;pub use slate_versions::ser as dalek_ser;
Modules§
- address
- Functions defining wallet ‘addresses’, i.e. ed2559 keys based on a derivation path
- api_
impl - lower-level wallet functions which build upon core::libtx to perform wallet operations
- slate
- Functions for building partial transactions to be passed around during an interactive wallet exchange
- slate_
versions - This module contains old slate versions and conversions to the newest slate version Used for serialization and deserialization of slates in a backwards compatible way. Versions earlier than V2 are removed for the 2.0.0 release, but versioning code remains for future needs
Macros§
- wallet_
lock - Helper for taking a lock on the wallet instance
Structs§
- Acct
Path Mapping - Map of named accounts to BIP32 paths
- Block
Fees - Fees in block to use for coinbase amount calculation
- Block
Identifier - Block Identifier
- CbData
- Wrapper for reward output and kernel used when building a coinbase for a mining node. Note: Not serializable, must be converted to necesssary “versioned” representation before serializing to json to ensure compatibility with mining node.
- Context
- Holds the context for a single aggsig transaction
- Error
- Error definition
- Node
Version Info - Node version info
- Output
Data - Information about an output that’s being tracked by the wallet. Must be enough to reconstruct the commitment associated with the ouput when the root private key is known.
- Scanned
Block Info - Store details of the last scanned block
- Stored
Proof Info - Payment proof information. Differs from what is sent via the slate
- TxLog
Entry - Optional transaction information, recorded when an event happens to add or remove funds from a wallet. One Transaction log entry maps to one or many outputs
- TxWrapper
- Dummy wrapper for the hex-encoded serialized transaction.
- Wallet
Info - a contained wallet info struct, so automated tests can parse wallet info can add more fields here over time as needed
Enums§
- Error
Kind - Wallet errors, mostly wrappers around underlying crypto or I/O errors.
- Output
Status - Status of an output that’s being tracked by the wallet. Can either be unconfirmed, spent, unspent, or locked (when it’s been used to generate a transaction but we don’t have confirmation that the transaction was broadcasted or mined).
- TxLog
Entry Type - Types of transactions that can be contained within a TXLog entry
- Wallet
Init Status - Enum to determine what amount of scanning is required for a new wallet
Traits§
- Node
Client - Encapsulate all wallet-node communication functions. No functions within libwallet should care about communication details
- Wallet
Backend - TODO: Wallets should implement this backend for their storage. All functions here expect that the wallet instance has instantiated itself or stored whatever credentials it needs
- Wallet
Inst - Combined trait to allow dynamic wallet dispatch
- WalletLC
Provider - Trait for a provider of wallet lifecycle methods
- Wallet
Output Batch - Batch trait to update the output data backend atomically. Trying to use a batch after commit MAY result in a panic. Due to this being a trait, the commit method can’t take ownership. TODO: Should these be split into separate batch objects, for outputs, tx_log entries and meta/details?
Functions§
- scan
- Check / repair wallet contents by scanning against chain assume wallet contents have been freshly updated with contents of latest block