[−][src]Crate grin_wallet_libwallet
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_versions::SlateVersion; |
pub use crate::slate_versions::VersionedSlate; |
pub use crate::slate_versions::CURRENT_SLATE_VERSION; |
pub use crate::slate_versions::GRIN_BLOCK_HEADER_VERSION; |
pub use api_impl::types::BlockFees; |
pub use api_impl::types::CbData; |
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::SendTXArgs; |
pub use api_impl::types::VersionInfo; |
Modules
api_impl | lower-level wallet functions which build upon core::libtx to perform wallet operations |
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 |
Structs
AcctPathMapping | Map of named accounts to BIP32 paths |
BlockIdentifier | Block Identifier |
Context | Holds the context for a single aggsig transaction |
Error | Error definition |
NodeVersionInfo | Node version info |
OutputData | 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. |
ParticipantData | Public data for each participant in the slate |
ParticipantMessageData | Public message data (for serialising and storage) |
Slate | A 'Slate' is passed around to all parties to build up all of the public transaction data needed to create a finalized transaction. Callers can pass the slate around by whatever means they choose, (but we can provide some binary or JSON serialization helpers here). |
TxLogEntry | 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. |
WalletInfo | a contained wallet info struct, so automated tests can parse wallet info can add more fields here over time as needed |
Enums
ErrorKind | Wallet errors, mostly wrappers around underlying crypto or I/O errors. |
OutputStatus | 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). |
TxLogEntryType | Types of transactions that can be contained within a TXLog entry |
Traits
NodeClient | Encapsulate all wallet-node communication functions. No functions within libwallet should care about communication details |
WalletBackend | 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 |
WalletInst | Combined trait to allow dynamic wallet dispatch |
WalletOutputBatch | 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
check_repair | Check / repair wallet contents assume wallet contents have been freshly updated with contents of latest block |
restore | Restore a wallet |