forked from etotheipi/BitcoinArmory
-
Notifications
You must be signed in to change notification settings - Fork 12
Python-Based Bitcoin Software
License
Unknown, Unknown licenses found
Licenses found
Unknown
LICENSE
Unknown
LICENSE.py
killerstorm/BitcoinArmory
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
################################################################################ # # # Copyright (C) 2011-2012, Alan C. Reiner <alan.reiner@gmail.com> # # Distributed under the GNU Affero General Public License (AGPL v3) # # See LICENSE or http://www.gnu.org/licenses/agpl.html # # # ################################################################################ ******************************************************************************** * * Project: Armory * Author: Alan Reiner * Orig Date: 02 Feb, 2011 * Descr: Armory is a full-featured Bitcoin client, offering a dozen * innovative features not found in any other client software! * Manage multiple wallets (deterministic and watching-only), * print paper backups that work forever, import or sweep private * keys, and keep your savings in a computer that never touches * the internet, while still being able to manage incoming payments, * and create outgoing payments with the help of a USB key. * * Multi-signature transactions are accommodated under-the-hood * about 80%, and will be completed and integrated into the UI soon. * * ***As of version 0.7-alpha, Armory NO LONGER requires holding the * blockchain in RAM, and systems with even 1GB of RAM should be able * to use Armory. The drawback is that full rescans will take approx * 30-120 seconds depending on the system, and currently one is done * on every load. * * ***Armory has no independent networking components built in. * Instead, it relies on on the Satoshi client to securely connect * to peers, validate blockchain data, and broadcast transactions * for us. Although it was initially planned to cut the umbilical * cord to the Satoshi client and implement independent networking, * that could be a multi-month task, and instead I may resort to * cannabilizing the Satoshi code, or a related project, to integrate * and existing, secure, robust, networking system into Armory with * out risks of major bugs and blockchain forks. * * ******************************************************************************** * * Please take a moment to donate 1.0 BTC! 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv * ******************************************************************************** ******************************************************************************** * STATUS: Last Updated - 28 Mar, 2012 * Legend: * _ not implemented * . implemented but not tested * + implemented and partially tested * X implemented and tested * * * Library Functional Status (armoryengine.py) * * --------------------------------------------------------------- * (01) Ser/Unser Block Objects X * (02) Hash160/Hash256 X * (03) Difficulty calcs X * (04) Address Generation X * (05) Address Verify/Manip X * --------------------------------------------------------------- * (06) BlkHeaders read/scan/org X * (07) BlkHeaders reorgs X * (08) Blockchain read/scan/org X * (09) Blockchain reorgs X * (10) Blockchain verify integrity X * --------------------------------------------------------------- * (11) NonStd Tx Detection + * (12) Arbitrary script parsing X * (13) OP_CHECKSIG/CHECKMULTISIG X * (14*) Arbitrary script eval X * (15) ECDSA Sign/Verify X * --------------------------------------------------------------- * (16) Address/Wallet tracking X * (17) Scan blkchain for Tx X * (18) Scan blkchain for NonStd X * (19) Reorg w/ double-spend X * (20) Add new blockdata real-time X * --------------------------------------------------------------- * (21) SecureBinaryData X * (22) Crypto++ ECDSA Hooked X * (23) Crypto++ AES Hooked X * (24) Crypto++ RandNumGen Hooked X * (25) Key-derivation (time&mem bound) X * --------------------------------------------------------------- * (26) Address Encrypt (AES) X * (27) Address Encrypt (Change Passwd) X * (28) Deterministic Addr Gen (ECDSAPriv) X * (29) Deterministic Addr Gen (ECDSAPub) X * (30) Deterministic Addr Gen (Random) * --------------------------------------------------------------- * (31) PyWallet/Addr File I/O X * (32) SelectCoins for tx X * (33) Tx fee calculations X * (34) Tx construct given inputs X * (35) Distribution Proposals (std) X * (36*) Distribution Proposals (multi-sig) . * --------------------------------------------------------------- * * * GUI/Client Functionality Status (ArmoryQt.py + supporting python files): * --------------------------------------------------------------- * (01) Multiple wallets X * (02) Deterministic Wallets X * (03) Watching-only wallets X * (04) Printing Paper Backups X * (05) Restore paper backup (typed) X * --------------------------------------------------------------- * (06) Restore paper backup (scann QR) * (07) Import/Sweep Hex Priv Keys X * (08) Import/Sweep Base58 Priv Keys X * (09) Import/Sweep Mini-Priv Key Format X * (10) Zero-confirmation transactions X * --------------------------------------------------------------- * (11) Spend change outputs immediately X * (12) User modes (Std/Adv/Dev) X * (13) SelectCoins customization X (impl but no GUI options, yet) * (14) Guaranateed Tx Fee calculation X (impl but tx will not be accepted) * (15) Full Wallet encryption with KDF X * --------------------------------------------------------------- * (16) Change encryption passphrase X * (17) Change key-derivation time/mem * (18) COMPLETE OFFLINE WALLET MANAGEMENT X * (19) Individual Key/Address backup X * (20) Convert Satoshi wallets to Armory X * --------------------------------------------------------------- * (21) Address books * (22) System-tray notifications * (23) Multi-signature Tx handling . * * * ******************************************************************************** Building Armory from Source: http://bitcoinarmory.com/index.php/building-armory-from-source ******************************************************************************** Information on dependencies (mainly for developers) (much of this information may be out-of-date: use at your own risk!) ******************************************************************************** Armory contains over 20,000 lines of code, between the C++ and python libraries. This can be very confusing for someone unfamiliar with the code (you). Below I have attempted to illustrate the CONOPS (concept of operations) that the library was designed for, so you know how to use it in your own development activities. There is a TON of sample code in the following three files: [**SWIG**] unittest.py (this has almost everything!) [ C++ ] cppForSwig/BlockUtilsTest.cpp [ Python ] armoryengine.py But of course, sample code alone does not make great documentation. I will attempt to provide reference info for everything else you need to know, here. For a list of library features, see the STATUS table in the README. Note that all features with an X in either column are accessible in SWIG. ################################################################################ ***Dependencies (from README) *** - Crypto++ Linux: Install package "libcrypto++-dev" Windows: Download from "http://www.cryptopp.com/#download" (MSVS: Copy cryptopp source dir into same location as .sln) - SWIG Linux: Install package "swig" Windows: "http://www.swig.org/download.html" (MSVS: Copy swigwin-2.x directory next to cryptopp as "swigwin") - Python 2.6/2.7 Linux: Should be preinstalled... Windows: "http://www.python.org/getit/" - Python Twisted -- asynchronous networking Linux: Install package 'python-twisted' Windows: "http://twistedmatrix.com/trac/wiki/Downloads" - PyQt 4 (for Python 2.X) Linux: Install "libqtcore4", "libqt4-dev" and "python-qt4" Windows: "http://www.riverbankcomputing.co.uk/software/pyqt/download" Also will need the QtSDK - qt4reactor.py -- combined eventloop for PyQt and Twisted All OS: https://launchpad.net/qt4reactor Windows Only: qt4reactor relies on pywin32 (for win32event module) http://sourceforge.net/projects/pywin32/files/pywin32/Build216/ - pywin32 - py2exe (OPTIONAL - if you want to make a standalone executable in Windows) Windows: http://www.py2exe.org/ *** Compiling *** Linux: From the cppForSwig directory "make" to make the C++ code alone, "make swig" to create and compile the SWIG wrappers sudo apt-get install git-core build-essential libcrypto++-dev swig libqtcore4 libqt4-dev python-qt4 python-dev python-twisted git clone git://github.com/etotheipi/BitcoinArmory.git cd BitcoinArmory git checkout qtdev cd cppForSwig make swig cd .. python ArmoryQt.py NOTE: If you get a "undefined reference in QtCore.so", it's likely due to another library installed that hijacked the system Qt installation. In my case, it was a CUDA installation which provided its own, older version of QtCore which was causing this issue. Windows: MSVS 2010 vcxproj included but not maintained. Only compiles C++. MSVS 2005 vcproj included. Setup to compile everything, and even runs swig and py2exe as pre- and post-build events. In windows you're going to have to do a bit more work than just installing the programs below. Specifically, you need to add a few libraries I couldn't distributed through git (for various reasons), and also make sure the MSVS has the right includes for your python version/location. Most importantly, check that the following settings match your python installation (currently configured for Python 2.6 in the MSVS 2005 project): C/C++ --> General --> Additional Include Directories: Linker --> General --> Additional Library Directories: Linker --> Input --> Additional Library Directories: SWIG Notes: Running SWIG takes in all the source code and the CppBlockUtils.i and creates a C++ source file called CppBlockUtils_wrap.cxx, as well as CppBlockUtils.py. The result of compiling this source file in linux: _CppBlockUtils.so In windows, compiling will generally produce _CppBlockUtils.dll --> MUST BE RENAMED --> _CppBlockUtils.pyd The previously-created CppBlockUtils.py expects to find this shared-object or pyd in the same directory. PyQt4 Notes: Getting PyQt4 setup in Linux is trivial: "apt-get" install as above Getting PyQt4 setup in Windows was a pain. I'm still not positive I could repeat the process and succeed. It does involve: -- Getting and installing QtSDK -- Getting mingw matching you QtSDK version -- Unzip mingw somewhere and referencing it when install QtSDK -- Download PyQt4 matching your python version -- Manipulate your PATH (environment variables) to make sure it has PyQt4 directory (C:\Python2X\Lib\site-packages\PyQt4) ################################################################################ # # NOTE: 05 Dec, 2011 # This documentation is accurate, but only represents a fraction of the # available functionality in the libraries. I will update this as soon # as I get the first client release out of the way. For now, you can # can see most of the C++ methods below (accessed via Python), and then # do an "import armoryengine; help(armoryengine)" to see a MASSIVE # list of the available classes and methods. Seriously... it's huge. # ################################################################################ *** Documentation *** This documentation is broken into three sections: - SWIG - C++ - Python Most of what you need to know is actually in the C++ section, since every C++ function call is mapped directly into python calls through SWIG. These C++ functions are at the heart of everything you do that touches the block- chain. If you are impatient, just jump to the "C++ Code Overview" and you will see 80% of what you need in the methods lists there. Python will be needed for anything involving Base-58 address strings, or ECDSA operations. Signing and verification works, though, it's not part of any demo, besides unittest.py which verifies a tx from the blockchain I will eventually be adding sample projects that exhaustively demonstrate each feature of the library in the combined SWIG interface. ################################################################################ *** SWIG Code Overview *** There is no explicit library file for combining python and C++ methods. You import both CppBlockUtils and pybtcengine in python, and off you go. The one important thing to know is that the modules are spread out in the project directory, and thus you need to add some directories to your path. The best solution is to append the paths you need at the top of your python file. You need to make sure that the directories containing pybtcengine.py CppBlockUtils.py _CppBlockUtils.so (linux) _CppBlockUtils.pyd (windows) are all on your path. For instance, if you are running the example blockexplorer in the pyqt dir, you will need the following lines at the top of your script to point python to search the other directories for the modules: import sys sys.path.append('..') sys.path.append('../cppForSwig') from pybtcengine import * from CppBlockUtils import * Most of the CONOPS for using the combined library is actually knowing how to use the C++ code. Most calls you make will be on SWIGified objects pulled in through the .dll(.pyd)/.so. In this case, the best documentation really is the example code. Look at cppForSwig/testswig.py; this file has examples of nearly every function. You can use this as a reference for what functions require C++ calls, and which ones are from pybtcengine.py. In general, if it came from the BlockDataManager: bdm = BlockDataManager_FullRam.GetInstance() bdm.getTxByHash(...) ... Then the resulting objects will be C++/SWIG objects. The list of useful methods in the C++ documentation, below, will identify all the available methods. **** One other important note: SWIG does *not* work with any overloaded methods involving BinaryData objects: this is because I created a SWIG typemap to simplify passing binary data between python and C++, but it led to a few important methods getting disabled. Instead of BtcWallet::addAddress(...) use: BtcWallet::addAddress_1_(...) BtcWallet::addAddress_3_(...) BtcWallet::addAddress_5_(...) The number at the end specifies how many arguments the method takes. The original method has 4 optional arguments, but SWIG didn't know what to do with it. The same thing needed to be done with BlockDataRef::unserialize() replaced with: BlockDataRef::unserialize_1_() This might be necessary for a few other methods, but I haven't run into any of them yet. ################################################################################ *** C++ Code Overview *** What's there: - Blockchain reading from file, scanning - Checking blk0001.dat file integrity - Organizing and finding the longest chain - Efficient access to ALL data in the blockchain - Standard and Non-standard script detection - Binary wallet tracking, with address ledgers What's NOT there: - BigNum library: cannot do any Base58/address manipulations. - ECDSA library: cannot do any signing/verification operations (however, crypto++ is linked, could be easy to add) - Address storage: addresses that have not information on a given address, you must do a full scan of the blockchain, which takes about 5s. If you need to do this quicker, you can revive some old code I had which took about 30s - Constructing transaction packets: this could be easy to add, since the library does make it easy to find all TxOuts for a given wallet The basics: The goal of the C++ code is to provide an optimized layer for accessing the blockchain. It reads the specified blk0001.dat file (where the blockchain is stored in raw, binary form) and maintains a series of maps and pointers to this data with minimal copy operations. IT IS VERY FAST. The C++ code has no BigNum or ECDSA code in it, which means it cannot sign/verify anything, or calculate address strings. ************************* Class BinaryData: This class is a simple wrapper for {vector<uint8_t>, uint32_t size}. It has a ton of convenience methods for searching, slicing and hashing these objects. All data that isn't human-readable strings will be passed around with BinaryData objects (typedef'd to "HashString") ************************* Class BinaryDataRef: This class is REFERENCE class for what would otherwise be used by BinaryData. It holds a {uint8_t*, uint32_t size}. Since many of our objects are persistent (see rule 1), it's safe to pass around references to them. This class has easy conversions to and from BinaryData, and has most of the same methods. ************************* Class BtcUtils: This is a helper class that contains methods and constants that might be shared between multiple classes. THIS IS A STATIC-METHOD-ONLY class. Therefore all methods and members must be scoped with BtcUtils:: Useful Methods: BtcUtils::GenesisHash_; BtcUtils::EmptyHash_; BtcUtils::MagicBytes_; BtcUtils::readVarInt() BtcUtils::readVarIntLength() BtcUtils::getHash256() BtcUtils::getHash160() BtcUtils::calculateMerkleRoot() BtcUtils::calculateMerkleTree() BtcUtils::TxInCalcLength() BtcUtils::TxOutCalcLength() BtcUtils::TxCalcLength() BtcUtils::getTxInScriptType() BtcUtils::getTxOutScriptType() BtcUtils::getTxOutRecipientAddr() BtcUtils::convertDiffBitsToDouble() BtcUtils::getOpCodeName() BtcUtils::convertScriptToOpStrings() ************************* Classes in BlockObjRef: These are the core of the library; all these objects have a serialize() and unserialize() method which uses the specified formats in: https://en.bitcoin.it/wiki/Protocol_specification These objects do not hold any serialized information, only a BinaryDataRef to where it is serialized in RAM by the BlockDataManager. All data that is not officially part of its serialized state is stored as extra members Useful methods: BlockHeaderRef BlockHeaderRef::getVersion() BlockHeaderRef::getPrevHash() BlockHeaderRef::getMerkleRoot() BlockHeaderRef::getDifficulty() BlockHeaderRef::getTimestamp() BlockHeaderRef::getNonce() BlockHeaderRef::pprint() BlockHeaderRef::serialize() BlockHeaderRef::unserialize() BlockHeaderRef::getThisHash() BlockHeaderRef::getDifficultySum() BlockHeaderRef::getBlockSize() // in bytes BlockHeaderRef::getTxRefPtrList() // access to all Tx's in this block BlockHeaderRef::getTxHashList() // access to all Tx's in this block BlockHeaderRef::verifyMerkleRoot() BlockHeaderRef::verifyIntegrity() // checks merkleroot and hash zeros OutPointRef OutPointRef::getTxHash() OutPointRef::getTxOutIndex() OutPointRef::serialize() OutPointRef::unserialize() TxInRef TxInRef::getOutPoint() TxInRef::getScript() TxInRef::getSequence() TxInRef::isCoinbase() TxInRef::pprint() TxInRef::serialize() TxInRef::unserialize() TxInRef::getSize() // number of serialized bytes TxInRef::getScriptSize() // number of serialized bytes TxInRef::getScriptType() TxInRef::isScriptStandard() TxInRef::isScriptCoinbase() TxInRef::isScriptSpendCB() TxInRef::isScriptUnknown() TxInRef::getSenderAddrIfAvailable() // Coinbase TxIns don't have this TxInRef::getCopy() // Creates TxIn; not used much/ever TxInRef::getParentTxPtr() // Coinbase TxIns don't have this TxOutRef TxOutRef::getValue() TxOutRef::getScript() TxOutRef::pprint() TxOutRef::serialize() TxOutRef::unserialize() TxOutRef::getSize() // number of serialized bytes TxOutRef::getScriptSize() // number of serialized bytes TxOutRef::isScriptStandard() TxOutRef::isScriptCoinbase() TxOutRef::isScriptUnknown() TxOutRef::getRecipientAddr() TxOutRef::getParentTxPtr() TxOutRef::getCopy() // Creates TxOut; not used much/ever TxRef TxRef::getVersion() TxRef::getNumTxIn() TxRef::getNumTxOut() TxRef::getTxInRef(index) TxRef::getTxOutRef(index) TxRef::getLockTime() TxRef::pprint() TxRef::serialize() TxRef::unserialize() TxRef::getSize() // number of serialized bytes TxRef::getThisHash() TxRef::getHeaderPtr() TxRef::setHeaderPtr() TxRef::getBlockTimestamp() TxRef::getBlockHeight() ************************* Classes in BlockObj: These are not used much, except for OutPoint which is used as the key for some of the maps. Generally these objects are used if you need to make a copy of a *Ref object, but this isn't common. Also, because of their lack of use, they may not have all methods you would expect them to have. (NOTE: you cannot create a BlockObjRef from a BlockObj, because the BlockObj does not store a serialization of itself, which is what is needed to create a *Ref object. You can only go the other way. ) ************************* Class TxIORefPair: All Bitcoin transfers are simply converting older TxOuts to newer TxOuts by signing a TxIn to prove that you own them. As such, each TxOut has exactly one or zero TxIns. If it has a TxIn, it is spent and can be forgotten. If not, it is unspent, and availble for use. Given the above, maintaining a wallet is much simpler if these objects are paired intelligently. Finding a TxOut during a blockchain scan will create an unspent TxIORefPair in your wallet (and a pointer to the Tx in which it is found). When you find a TxIn, it must reference a TxOut that you have already seen, and so we retreive the TxIORefPair and update it. It has now been spent. One major benefit of this technique is that it becomes painfully obvious which of your TxOuts are available to be spent, and if you are creating a lightweight client, you can purge all TxIORefPairs that have both objects to save space. Useful methods: TxIORefPair::hasTxOut() TxIORefPair::hasTxIn() TxIORefPair::hasValue() TxIORefPair::getValue() TxIORefPair::getTxOutRef() TxIORefPair::getTxInRef() TxIORefPair::getTxRefOfOutput() TxIORefPair::getTxRefOfInput() TxIORefPair::setTxInRef() TxIORefPair::setTxOutRef() TxIORefPair::isUnspent() TxIORefPair::isSpent() TxIORefPair::isStandardTxOutScript() ************************* Class LedgerEntry: This is a reduced form of a transaction. IT HAS DUAL-UTILITY: it can represent a ledger entry for a single address, or for an entire wallet. This is an important distinction since an address is maintained via a list of TxIns and TxOuts, but a wallet only cares about the sum of TxIns and TxOuts in the transaction. When we use the BtcWallet::scanTx() method, the list of ledger entries for both wallet and child addresses will be updated. They can also be sorted by timestamp, or made invalid Useful methods: LedgerEntry::getAddrStr20() LedgerEntry::getValue() LedgerEntry::getBlockNum() LedgerEntry::getTxHash() LedgerEntry::getIndex() // index of Tx for wallet, TxIn/TxOut for addr ************************* Class BtcAddress: Holds as much information as we know about a given address. Will also hold an updated balance/ledger everytime it's parent BtcWallet is updated Since there are multiple ways to represent each field, we label each member with the number of bytes NOTE: The C++ address objects no longer have fields for public and private keys. All that data will be handled by Python/SWIG Useful Methods: BtcAddress::get/setAddrStr20() BtcAddress::get/setFirstBlockNum() BtcAddress::get/setFirstTimestamp() BtcAddress::get/setLastBlockNum() BtcAddress::get/setLastTimestamp() BtcAddress::getBalance() BtcAddress::cleanLedger() // remove invalid entries, sort by time BtcAddress::addTxIO() // add a ref/ptr to this address's list BtcAddress::addLedgerEntry() BtcAddress::getTxIOList() // Get all relevant TxIORefPair objects BtcAddress::getTxLedger() // get a vector of ledger entries ************************* Class BtcWallet: This basically just holds a bunch of BtcAddresses, and will aggregate information relevant to all addresses in it. Useful methods: BtcWallet::addAddress() BtcWallet::addAddress_X_() // needed to play nicely with SWIG BtcWallet::hasAddr() BtcWallet::scanTx() BtcWallet::scanNonStdTx() BtcWallet::getBalance() BtcWallet::getNumAddr() BtcWallet::getAddrByIndex() BtcWallet::getAddrByHash160() BtcWallet::getTxLedger() BtcWallet::cleanLedger() BtcWallet::getTxIOMap() // all relevant TxIORefPairs BtcWallet::getNonStdTxIO() // in this list if TxOut has nonstd script BtcWallet::getUnspentOutPoints() // all relevant TxIORefPairs BtcWallet::getNonStdUnspentOutPoints() // all relevant TxIORefPairs BtcWallet::lockTxOut() // may want to lock when attempting tx BtcWallet::unlockTxOut() ************************* Class BlockDataManager (BDM): This is your one-stop-shopping location for anything related to the blockchain. It is a SINGLETON meaning only one of them can ever be created, and it is accessed via: BlockDataManager bdm = BlockDataManager::GetInstance() Useful methods in BlockDataManager: BlockDataManager::readBlkFile_FromScratch (filename) BlockDataManager::organizeChain (void) BlockDataManager::getHeaderByHash (BinaryData) BlockDataManager::getHeaderByHeight (uint32_t) BlockDataManager::getTxByHash (BinaryData) BlockDataManager::scanBlockchainForTx_FromScratch (BtcWallet) BlockDataManager::scanBlockchainForTx_FromScratch (vector<BtcWallet>) BlockDataManager::findAllNonStdTx (void) *** Using the C++ code *** ***RULE 1: DON'T COPY PERSISTENT OBJECTS The following object types are stored EXACTLY once by BlockDataManager: -BlockHeaderRef -TxRef The following object types are stored EXACTLY once by BtcWallet/BtcAddress: -TxIORefPair All operations involving one of these object types should use pointers to the single instance of them. This is not as hard as it sounds, because all methods that using these objects as inputs/outputs only use pointers. While the point of the *Ref classes was to not have to worry about copy operations, THEY CONTAIN POST-CONSTRUCTION MEMBERS that may be large and slow/complicated to re-compute. For instance: TxRef contains a pointer to a BlockHeaderRef. However, this pointer can change (upon reorg) and thus, if we had multiple copies of the TxRef, we'd have to make sure they all get updated. ***RULE 2: ONLY COPY OutPointRef, TxInRef, TxOutRef OBJECTS Unlike BlockHeadeRef and TxRef, these three classes contain no members that are created post-construction. They are also very fast to recompute given a pointer to where they are serialized. Therefore, we rarely use ptrs/refs to these objects, and instead create new ones on the fly whenever we need them. Use uint32_t TxRef::getNumTxIn (void); uint32_t TxRef::getNumTxOut (void); TxInRef TxRef::getTxInRef (index i); TxOutRef TxRef::getTxOutRef (index i); ***RULE 3: TxIns ARE COMPLICATED (I know this isn't "rule", but it is important) We'd like to think that TxIns contain all the information we need about where and how much money is coming from in a Tx. However, this is not actually the case. Standard TxIn serializations do not hold the values and MAY NOT EVEN HOLD THE SENDER ADDRESS. To get this information, you have to follow its OutPoint and get it's TxOut, you need the help of the BlockDataManager to find it. Three convenience methods have been created for this purpose: TxOutRef BlockDataManager::getPrevTxOut (TxInRef & txin); BinaryData BlockDataManager::getSenderAddr20 (TxInRef & txin); int64_t BlockDataManager::getSentValue (TxInRef & txin); ***RULE 4: ALWAYS RESCAN YOUR WALLET(S) AFTER BLOCKCHAIN UPDATES (OR PASS NEW TX DATA DIRECTLY TO YOUR WALLET, IN ADDITION TO BDM) You create a BtcWallet object and then add your addresses to it. However, the BlockDataManager has no persistent knowledge of your wallet. You must update your wallet balances/ledgers with a call to: BlockDataManager::scanBlockchainForTx_FromScratch(MyBtcWallets) Or you can plug the new Tx information directly into the wallet: BtcWallet::scanTx( TxRef, txIndex, blockNumber, blockTimestamp) The extra information is to make sure that you wallet can update all of its pointers correctly, and store first-seen information (to improve searching) ################################################################################ *** Python Code Overview *** Coming soon! Until then, there are examples of every python capability distributed throughout random scripts. Here's the most useful example code: unittest.py (mostly lower-level stuff, like Base58-ops, endianness, etc) extras/mysteryHex.py extras/createTestChain.py (includes block creation, signing) Less-useful example code: extras/extractKeysFromWallet.py extras/findaddr.py
About
Python-Based Bitcoin Software
Resources
License
Unknown, Unknown licenses found
Licenses found
Unknown
LICENSE
Unknown
LICENSE.py
Stars
Watchers
Forks
Packages 0
No packages published
Languages
- C++ 59.3%
- Python 31.2%
- C 4.7%
- Assembly 2.0%
- Racket 1.7%
- Perl 0.8%
- Other 0.3%