C# Class BitSharper.Wallet

Adds the given ECKey to the wallet. There is currently no way to delete keys (that would result in coin loss).

Locates a keypair from the keychain given the hash of the public key. This is needed when finding out which key we need to use to redeem a transaction output.

Locates a keypair from the keychain given the raw public key bytes.

Returns the available balance of this wallet. See BalanceType.Available for details on what this means.

Note: the estimated balance is usually the one you want to show to the end user - however attempting to actually spend these coins may result in temporary failure. This method returns how much you can safely provide to CreateSend(Address, ulong).

Returns the balance of this wallet as calculated by the provided balanceType.

Returns true if this wallet contains a public key which hashes to the given hash.

Returns true if this wallet contains a keypair with the given public key.

Returns a wallet deserialized from the given file.

Returns a wallet deserialized from the given file input stream.

Uses Java serialization to save the wallet to the given file.

Uses Java serialization to save the wallet to the given file stream.

Sends coins to the given address, via the given Peer. Change is returned to the first key in the wallet.

Sends coins to the given address, via the given PeerGroup. Change is returned to the first key in the wallet.

Creates a new, empty wallet with no keys and no transactions. If you want to restore a wallet from disk instead, see loadFromFile.

Call this when we have successfully transmitted the send tx to the network, to update the wallet.

Statelessly creates a transaction that sends the given number of nanocoins to address. The change is sent to the first address in the wallet, so you must have added at least one key.

This method is stateless in the sense that calling it twice with the same inputs will result in two Transaction objects which are equal. The wallet is not updated to track its pending status or to mark the coins as spent until confirmSend is called on the result.

Creates a transaction that sends $coins.$cents BTC to the given address.

IMPORTANT: This method does NOT update the wallet. If you call createSend again you may get two transactions that spend the same coins. You have to call confirmSend on the created transaction to prevent this, but that should only occur once the transaction has been accepted by the network. This implies you cannot have more than one outstanding sending tx at once.

If the transactions outputs are all marked as spent, and it's in the unspent map, move it.

Handle when a transaction becomes newly active on the best chain, either due to receiving a new block or a re-org making inactive transactions active.

Called by the BlockChain when we receive a new block that sends coins to one of our addresses or spends coins from one of our addresses (note that a single transaction can do both).

This is necessary for the internal book-keeping Wallet does. When a transaction is received that sends us coins it is added to a pool so we can use it later to create spends. When a transaction is received that consumes outputs they are marked as spent so they won't be used in future.

A transaction that spends our own coins can be received either because a spend we created was accepted by the network and thus made it into a block, or because our keys are being shared between multiple instances and some other node spent the coins instead. We still have to know about that to avoid accidentally trying to double spend.

A transaction may be received multiple times if is included into blocks in parallel chains. The blockType parameter describes whether the containing block is on the main/best chain or whether it's on a presently inactive side chain. We must still record these transactions and the blocks they appear in because a future block might change which chain is best causing a reorganize. A re-org can totally change our balance!

Called by the BlockChain when the best chain (representing total work done) has changed. In this case, we need to go through our transactions and find out if any have become invalid. It's possible for our balance to go down in this case: money we thought we had can suddenly vanish if the rest of the network agrees it should be so.

The oldBlocks/newBlocks lists are ordered height-wise from top first to bottom last.

Updates the wallet by checking if this TX spends any of our outputs. This is not used normally because when we receive our own spends, we've already marked the outputs as spent previously (during tx creation) so there's no need to go through and do it again.