[][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