Skip to main content

Crate cs_epic_wallet_libwallet

Crate cs_epic_wallet_libwallet 

Source
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§

AcctPathMapping
Map of named accounts to BIP32 paths
BlockFees
Fees in block to use for coinbase amount calculation
BlockIdentifier
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
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.
ScannedBlockInfo
Store details of the last scanned block
StoredProofInfo
Payment proof information. Differs from what is sent via the slate
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
WalletInitStatus
Enum to determine what amount of scanning is required for a new wallet

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
WalletLCProvider
Trait for a provider of wallet lifecycle methods
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§

scan
Check / repair wallet contents by scanning against chain assume wallet contents have been freshly updated with contents of latest block