It's an all-or-nothing deal. Either load the whole blockchain into RAM, or don't load any of it. It's too inefficient and pointless to try and use virtual memory.
Very few transactions need to read the entire blockchain. A reasonable blockchain index could be kept in RAM and the entire blockchain mmap'd to virtual memory. As best I can tell, Bitcoin transactions tend to access recent blocks far more often than ancient blocks. The OS virtual memory system should handle that access pattern efficiently. One possible implementation would be an in-memory index mapping a Bitcoin address to the first block in which it appeared. Private key sweep code must only traverse, and possibly fetch from disk, subsequent blocks. With this kind of access pattern, the OS is likely to keep the last several thousand blocks in RAM and rarely fetch extra data from disk. I need to look more into mmap and the Windows equivalent. I seem to remember concluding that you still needed the address space for the file in RAM, but instead behaved as a sort of RAM-based cache for the file. Also, I didn't like the platform-dependence of it. But for such a big change it might be worth fighting that battle... if it truly does save the RAM. Right now Armory doesn't maintain any disk-index at all. It completely rescans the blockchain on every load, and reaccumulates the balance and outputs of each wallet. This is possible because of how extraordinarily fast my blockchain scanning code is... even on my slow computer, it takes less than 20s to cold-boot Armory on the main network and that's only single-threaded! Sure, this is not a good long-term design, but it wasn't intended to be -- 10s-20s load time is perfectly acceptable to me for the next couple months until I get something more sane in there. And there's no issues with synchronizing index files to the blk0001.dat file... there are no index files! Data structures are my specialty, and I already know how to handle all the maps/indexes for a more-efficient, non-scanning-every-load client (even easier if mmap does what I need). It's easy enough to maintain a master index of addresses and blockchain locations, I've even done implemented it and saw that it takes something like 150 MB. It's just not a priority before my first release, since its runtime is already acceptable. |
|
|
|
|
Btw, if anyone has any experience with PyQt/PySide, I could really use some help with tableView column sizing. Everything I tried only gets me 80% of the way there. I haven't found a robust way to do this: I tried tableview.width() to get the table size and then setting columns to percentages of it, but it seems the size is always off, and the columns sizes end up being butchered.
If anyone has a good paradigm for getting this right, I'd love to be educated and integrate it. Right now there seems to be cross-platform SNAFU issues with the tableViews.
|
|
|
|
Building in Ubuntu is ridiculously easy (Windows instructions are considerably more involved... I'll get to that soon!). I'm not sure what state the code is in (remember, I'm planing to release next week). Nonetheless, I know people want to try it, so here it is: 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 The big issue I'm facing right now is that something went awry with address importing in encrypted wallets. You can try that feature, but you might temporarily bork your wallet. Although it might work to remove the address through the dialog.... For now I really need to buckle down on development, and so I'm going to try to cut myself off from email/web for a while. P.S. -- I hardcoded testnet into the client, because I don't want anyone using real coins with it yet. You can get some testnet coins from the Testnet FaucetEDIT: REMEMBER: make sure you run the Satoshi client with the -testnet option, and let it download the blockchain. Then you can start Armory, it will connect automatically. And since Testnet is so small, you could technically do this on any modern computer... testnet blockchain is only 30 MB (compared to 830 MB for main-network blockchain). |
|
|
|
Uh, using mmap() or similar on Windows would let you access the blockchain through virtual memory, loading it from disk as needed.
Could this resolve your issue ?
That would defeat the purpose of loading the blockchain into RAM in the first place. You'd have to read the entire blockchain from disk every time you did a scan, which wouldn't be any faster than the traditional client. Besides, ram is incredibly cheap these days. You can get an 8GB kit for $32. Well, at least if your system accepts DDR3. If you're still stuck on DDR2, it'll be a bit more expensive. I wouldn't say it defeats the purpose... I do want a disk-based blockchain implementation--making the user wait 10-20s to import/sweep an address isn't the end of the world--some of them won't be able to even use the software if full-RAM is the only option. But the full-RAM implementation does add some kick for the users that don't mind. This is actually why I'm going to make sure both options are there (at least for the adv/dev modes). |
|
|
|
Uh, using mmap() or similar on Windows would let you access the blockchain through virtual memory, loading it from disk as needed.
Could this resolve your issue ?
Is this really a solution? I thought you still needed the full address space of the file in order to use mmap (i.e. 1 GB or RAM for a 1GB file) but that mmap prevents you from needing to read it all from disk until you actually access it. If I have it wrong, please let me know. The other issue was with portability. Since mmap is linux-specific, I would have to do something completely different for Windows, and I was trying to avoid platform-specific code. But if I have this wrong, maybe it will be an easy upgrade after all  very interesting, one note would be if you're allowing paper backups to integrate a QR reader into the app to recgonize a scaned image of your backup when you want to recover it!
My primary goal for putting the QR code there was so that your computer could easily transfer a wallet to your phone, if someone were to make a smartphone app. While it is annoying to type in the root/chain codes... it should be a rare event, and I selected a character set that is easy to type. On the other hand, I have a two-factor authentication scheme nearly ready-to-go, requiring only 2-of-2 transactions without a third-party, but I need a phone app to do. The computer would generate both wallets and the phone would scan the paper QR code and then be used for signing only (no blockchain). Armory will delete the private keys on the computer but keep a watching-only version, then move all your money into a 2-of-2 transaction requiring both computer and phone. More details in this thread... However, while the low-level code is well-commented, I haven't really done any high-level documentation of how to do high-level stuff -- for now you'll have to settle for looking at unittest.py until I get around to making a walk-thru of the high-level interface.
Donated a few btc for having unit tests and comments. Sounds like great work, will check it out when it's in alpha. Thanks! I don't know if there's a way to do a project of this order of magnitude without testing and comments. I'm constantly having to go back to code I haven't touched in months, and tweak it, or remind myself how the interface works. On that note, the entire wallet file format is described in the PyBtcWallet class comments. If anyone wants to see how the wallet file is constructed, it should all be described there. The address format is described in the PyBtcAddress serialize function. I'm going to work on build instructions right now. But for those of you jumping ahead please checkout the qtdev branch of the repo. Virtually no GUI development has been merged into master yet. This is great. I'm also interested in why you did it. After all there are several open source bitcoin clients that could need patches for these features. Hope you get and accept the support to push this client to a bright future.
Bitcoin is my calling. It combines every one of my strongest skills (cryptography, math, programming, data structures, algorithm optimization, GUI design). I started this project 6 months ago, and was disappointed with the utter lack of python support. I quickly figured out that anything blockchain related is devastatingly slow in python, but I was determined to do it anyway (and hence the C++/SWIG layer). After participating in the forums, I realized just how many features were missing from it that I knew exactly how to implement. It would've been a tremendous amount of work to gut someone else's project (there were very few), and it might not even be quicker! Maybe I'm just stubborn and like doing things my own way... On the other hand, if you want C++ blockchain-only tools, the implementation I ended up with is the absolute fastest thing possible for reading and scanning the blockchain. It's not verifying the blockchain, but in terms of collecting unspent outputs and computing balances, I don't think any single-threaded app could be any faster (0.65s to get the balance of a wallet with the blockchain in RAM, 10-15s if it's a cold-start from disk). And of course, multi-threading this process is in my long-term plans |
|
|
|
This is EXACTLY what I needed to be able to move forward with one of my projects.
Two questions:
1) How well does it handle wallets with many thousands of generated addresses? Say, 50-100k addresses in a single wallet file?
2) When do we get a Windows exe?
The blockchain-wallet scanning should be O(log(n)) in the number of addresses in your wallet. If you have the RAM to try it, I'd be interested to see how long it takes to do the scan and collect the balances, but I would guess it's less than 5s. As for the wallet format: there are no arbitrary limits on how big the wallets can be. I have had 500 addresses in one of my wallets before, without problem -- there are no artificial limits. Perhaps you will be able to help me find the breaking point for wallet sizes. I'm having a problem with PyQt and py2exe in Windows. I have a MSVC++ runtime error when trying to install the pywin32 module, which linked but not actually needed by my software. So I can comment out the imports and the software runs fine, but py2exe complains that it needs it in order to make the executables. it's going to take a little bit more work (and maybe switching systems), before I get an executable made. I spontaneously got an exe built once (so I know it works), but for some reason I couldn't repeat it... For now, I still have some dev left before officially making exe's... maybe I shouldn't have posted so soon (remember, releasing next week) But I'll put up build instructions tonight or tomorrow, and plan to have a Windows exe built by next week. For now, I still have some pretty important bugs to quash before I would trust this software with anything but testnet coins... |
|
|
|
Excellent work, if I do so say so myself. Is it possible to run it without a GUI via the terminal / command line?
You can get to 90% of the functionality of Armory via a python shell (loading the blockchain, creating wallets, importing keys, getting blockchain data, scanning addresses, getting unspent-output lists, crypto ops, etc)., but you have to know what calls to use. You can get some hints from unittest.py, which contains most of the unit-tests for the project. However, while the low-level code is well-commented, I haven't really done any high-level documentation of how to do high-level stuff -- for now you'll have to settle for looking at unittest.py until I get around to making a walk-thru of the high-level interface. If you want pure-python without any external dependencies, go look at PyBtcEngine which should work without any of the C++/SWIG stuff (it's my own project I forked Armory from a couple months ago, when I had to take the leap from pure-python to hybrid). From there you can make all kinds of scripts, or setup a simple socket/IO interface to pipe commands to and from a running server. There's a lot of possibilities... and for now I'll work on build-instructions and try to post them tonight so that all these committed people have a chance to get up and running tonight I guess pre-alpha is the new alpha! |
|
|
|
Sure, but isn't the plan to make it standalone at some point? If the "no validation" is only supposed to remain while it uses the Satoshi client then it's not a problem.
You are right: once I sever the umbilical cord to the Satoshi client, it will not do block-validation. However, I don't see this as a problem. The entire future of Bitcoin will revolve around lite-clients which don't have block-validation, and I don't have a problem having my program be one of them. However, it's not out of the question to do some kind of validation on zero-conf transactions, but it's not my first priority. As I said before: it's up to you to pick your own "comfort level" with 0 and 1-conf transactions, but if you wait for 6 like is globally suggested on the network, all types of nodes should have equal confidence. The only thing to take away from this is that once Armory has standalone networking, those zero-conf transactions should be treated even more cautiously than on a full node. I'm more focused on having rock-solid wallet management, instead of real-time operational details like this (it's just a matter of priorities).. |
|
|
|
On that note: I should've mentioned that this client does no blockchain validation. The assumption is made, that if the data made it into the longest blockchain, it is valid. I let miners do the work so I don't have to.
This may fly for blocks buried deep enough in the chain. But for recent blocks you need to check they are actually valid before propagating them further. Otherwise you get into a situation that nobody does any checking because he trusts that everyone else will do the checking and only feed him clean data. But, of course, no one should really ever be trusting zero-conf transactions...
I disagree, there are certainly situations where 0-confirm transactions are to be trusted (notable example is paying for a latte). "Deep enough" is the standard 6 blocks. If the rest of the world is building off a blockchain with your transaction 6 blocks deep I'm happy to accept it. If you flood my node with 100% dishonest connections and start sending me poisoned blocks... well there's nothing the Satoshi client with full node-validation can really do with that, either. As long as you have 1 honest node out of 100 connections, you will get the longest chain. As for 0-conf transactions, you are allowed to trust them as much as you want, but I won't encourage it. All you need is 1 dishonest node out of 100 connections to start sending you invalid transactions. They can even send you transactions that would appear valid, but since my node doesn't check&forward them, I don't know that they weren't sent to any miners and won't actually be included in the blockchain. The only way to avoid this is with full-validation, but that's not something that any lite-client will be doing. However, since Armory connects through the Satoshi client, all data is filtered through it's full-validation behaviors. So you can trust the 0-confirmation transactions a bit more than you could on a real, light node, but I still wouldn't trust it too much. I mostly use it for confirmation that an expected payment entered the system, but there's too many things that can go wrong with 0-confs. Even 1-confirmation transactions have holes that could be exploited by determined (there's some posts on 1-conf exploits I participated in a while ago... I can dig them up if you are super-interested). In terms of risk in accepting transactions, as a function of the number of confirmations, I would apply the following ranking (normalized by zero-confimation risk) 0: 100%
1: 30%
2: 3%
3: 2%
4: 1%
5: 1%
6: 1% That's not just exponential decay... there's just extraordinarily fewer options for an attacker once the tx is 2 blocks deep. That's also why I change the text color from light gray to not-so-light-gray after 2 confirmations (but you can't hold me responsible for things going wrong if you don't wait for 6) Finway: Check out the Using_Armory.README file for more information about how to compile -- or wait for me to post specific/updated instructions. There might be more hints in the PBE block-explorer demo thread (but you need to add a few things, like python-twisted, etc). |
|
|
|
Very cool. Finally my 16GB will be of use . What about bulk generation of addresses? I'm not sure what you mean by "bulk generation." The deterministic wallet feature will generate an infinite number of addresses, but it is kind of slow, because each step in the sequence requires ECC operations to be performed on the CPU. I believe it will extend the sequence at about 100 addr/sec. awesome  can you add a option to download the blocks but dont check them and only check the blocks from the last week/month/user defined time Right now, there is no blockchain downloading-- it leaches completely off the Satoshi client and its blockchain file. On that note: I should've mentioned that this client does no blockchain validation. The assumption is made, that if the data made it into the longest blockchain, it is valid. I let miners do the work so I don't have to. However, for zero-confirmation transactions, I might add a check to make sure that the previous output is at least in the blockchain. But, of course, no one should really ever be trusting zero-conf transactions...Pretty awesome... looking forward testing it..
One thing "Multi wallet" does that also include "multi blockchain"? What i alook for is a single client to hold my BTC, LTC and so on wallets...
Unfortunately, I do not have multi-network support. The network has to be specified at runtime, and then everything after that is hard-coded. However, I was surprised to see how painless it was to switch between main-network and testnet, so you could probably add your own network parameters (genesis hash, magic bytes, network port), and run a separate instance of Armory. I'm not sure it would be any more resource intensive than if I had them all integrated into the same interface... but I recognize it's not as convenient to run multiple instances. Unfortunately, this feature is not on my radar in terms of near-term improvements. |
|
|
|
Thanks for all the compliments. I've been looking forward to this moment for a while So much that I can't believe I botched the donation address I usually keep in my signature! (I tried changing it and forgot to restore the address). Feel free to donate now: 1Gffm7LKXcNFPrtxy6yF4JBoe5rVka4sn1, but I'm definitely more interested in having you donate from the software itself. If it works well enough to donate, then we're both happy! I still need to work out some lingering bugs and interface issues. I have tested the hell out of most of the stuff under-the-hood, and it just needs to be prettied up on the user-interface side. Once I finish implementing and testing the offline-wallet interface, I'll try to post instructions for those that want to run it themselves. I plan to make binaries in Windows (though I am struggling with py2exe issues right now), and Ubuntu should only be a few command-line calls (I have a bare VM setup to test that this is true). Of course, these things never work out as smoothly as I hoped, and I know it's going to be a pain to support multiple OS's... but I suppose that's part of the fun! If you're interested in helping me test right now... well, I'll make a post tonight or tomorrow with initial build instructions. Once I have the offline interface working, I'll try to make binaries and post them on my (future) webpage. As you all have noted, this is a heavy program. I understand not everyone will be able to use it. But those than can... well I think you will enjoy it I plan to spend half of my immediate development activities (after alpha) on creating a file-based blockchain, but it might be a while before I can get it implemented and tested. But no doubt: I will be keeping the full-RAM implementation in there, it will be modified to scan the blockchain in batches (so no huge RAM reqt) and also could be easily ported to some kind of server as people have suggested. I would love to see the full-RAM implementation used in a server: with nothing but a blk0001.dat file, I can scan the entire blockchain and collect the balance/unspent-outputs of an address/wallet in less than 1s. From a cold boot, it's probably 15-20s with all the file ops and blockchain organization ops. |
|
|
|
Finally! I am about a week away from releasing Armory. I have started a thread in the Alternate clients forum: https://bitcointalk.org/index.php?topic=56424Please let me know if you want to help test the pre-alpha version, but it might be kind of bumpy while I work out the platform/configuration variations, etc.
|
|
|
|
Sep 16, 2013: Most Secure Bitcoin Wallet Armory Raises $600k Led by Trace Mayerhttp://www.coindesk.com/bitcoin-wallet-armory-raises-600k-seed-funding/If anyone has been anxiously awaiting "something big" that was it. Armory just got a huge injection of money, and we're going to start taking Armory -- and Bitcoin -- to the next level It's a shame I couldn't get the new version of the software out in time, but oh well. I'll have it soon! To allay any concerns about "selling out", I want to reassure you all that the reason I picked Trace as my investor (I had a lot of investors approach me) is because his vision is very well-aligned with Armory's. He is very insistent that money & revenue is irrelevant for the next 6-12 months. He wants to see Armory get easier to use, multi-sig implemented, Android app, HW wallets, and a server version that can replace bitcoind. He believes that Bitcoin needs these things more than he needs short-term return on this investment. This is very cool, because it means that I can focus on developing cool stuff, instead of figuring out how to make money. Of course, I will eventually have to spend effort on the revenue side, but the top priority for the next 12 months is getting Armory usability expanded for both new users and power users. Part of it is that Trace and the other investors have a lot of Bitcoin investments, and are really trying to figure out how to get Bitcoin into great adoption/acceptance. Funding Armory to do this development benefits them even if Armory fails as a business (but succeeds as an open-source project). For months, he has been saying that wallet apps are the weakest point of the Bitcoin system, and we need more wallet usability, functionality and security. I'm very excited that Armory will eventually be able to provide all that. For now, I have a ton of work to do. But you guys can sleep easy knowing that I'm officially on this full-time! Thanks for all your guys' support on this. Armory's reputation doesn't come from nowhere... it takes a userbase to like it enough to talk about it, share it, promote it, etc. So thanks everything for helping me get to this point.
In case you're wondering: the way you guys interact with me and Armory will not really change, I plan to remain very active on the forums, and will probably even continue code development on github. What might change is that I'll have a couple new code wizards joining the team, and will probably be on here answering forum posts and responding to emails. I'm hoping that once these guys are up to speed, we'll really be able to take off. For reference, we currently have two other employees in addition to me, and we'll probably be getting a third. But we're still working out some budget stuff and not sure whether I have time to organize that many brains
Note: I am no longer updating this top post (though the thread is still used for discussion). Please see the Get Armory! page for information on the latest release. ( Armory Homepage) ( Get Armory) ( Quick Start) ( Cold Storage) ( Donate!) ( Github Project Page) ( Report Issues) ( Announcements) ---------------------------- Armory Bitcoin Client http://www.bitcoinarmory.com Armory is a python-based Bitcoin client (with C++/SWIG backend for fast blockchain processing), designed from the ground up to provide a dozen innovative features not found in any other Bitcoin client! This is the most advanced Bitcoin client to date, by a mile!Features:- Deterministic wallets: Your entire wallet is recoverable from only the root address and a "chaincode." You only need to backup your wallet once, and your funds will be safe forever (with the exception of imported private keys, which must be backed up separately)
- Multi-wallet interface: Manage as many wallets as you want simultaneously. Armory was designed from the start for multi-wallet operations without limit on number.
- Usermode Options: Choose between "Standard", "Advanced" and "Developer", to scale the functionality according to your experience level. "Standard" user mode has a reduced set of functionality and only presents information necessary for basic wallet management and transactions. "Advanced" mode gives you access to all the features advertised here. "Developer" mode is the same as "Advanced" but with more options and a plethora of extra information (viewing scripts, copying raw hex data, etc).
- Paper-backups: Print a paper backup of your wallet on one sheet of paper, and keep it in a book on your bookshelf, or in a safe with your cash. Paper wallets are superior to digital media, because paper is cheap, easy to store, and you can verify the integrity of the backup by eye. If you backup your wallet to a USB key, how do you know that it will still work when you plug it in two years from now? If you can read the characters on the paper backup, you can recover all the funds you ever received to it!
- Watching-only wallets: "Watching-only" wallets can be used generate addresses and confirm incoming payments, but cannot spend the money. Keep the full wallet on an offline computer, and maintain it safely from the online computer. Or create a master wallet for your business, and give a watching-only copy to your employees to do business. It's impossible for a hacker (or employee) to steal your Bitcoins if your private keys are on a computer that never touched the internet!
- Offline Wallet Interface: This is the holy-grail feature of Armory! You can use Armory to create a wallet on a computer that will never touch the internet again, and then make a watching-only copy to use on the internet computer. You can monitor transactions online, and sign transactions offline without needing the blockchain. And since it doesn't need the blockchain, even a computer with 512 MB of RAM can be used as the offline system. Please see the offline-wallet tutorial! (you will need a USB key to shuttle data between computers, but the entire process for offline transactions can be done in under one minute!).
- Wallet encryption with GPU-resistent key derivation function: AES256 in-place key encryption. Encryption key is generated with a scrypt-based algorithm to renders GPU-acceleration useless for brute-force passphrase guessing. Speed and memory parameters are determined via system speed test.
- Corruption-resistent wallet files Wallet code auto-corrects bit-flips on your hard-drive, and also uses a synchronous backup wallet scheme that guarantees no matter which nanosecond the power goes out, your wallet will never be corrupted (or automatically recovered if it does).
- Import/Sweep Addresses: Import trusted private keys into your wallets, or just "sweep" the funds to another address in your wallet. Supports private keys in hex, base58, and mini-private-key format used on Casascius physical bitcoins (it does work with Vanitygen addresses!)
- Optional Transaction fees: Calculates and inserts guaranteed-acceptable fees to transactions (with confirmation, of course). Advanced users can force zero-fee transactions by manually modifying the setting file (designed to be possible but non-trivial -- I want to allow the determined users to do it, but I don't want to be responsible for folks getting transactions stuck)
- Get your private keys! There is no database software obscuring key data. All keys are stored in a straightforward binary wallet format. Unencrypted data can be pulled out directly. If it is encrypted, you can use the in-application dialog for viewing key data after you unlock your wallet.
- Developer Tools! Thoroughly-commented Python code. Thoroughly-commented C++ code. Thousands of lines of unit-test code for verifying almost every sub-function of the entire library. Simple wallet files. And the "Developer" user mode will give you everything you could possibly need to help you with your own development: browse the blockchain, examine tx scripts, etc.
- Windows and Linux! Compiled and runs on both. Exhaustive instructions for compiling on the Building Armory page. Some users have gotten OSX compiled, but the instructions are not complete yet. If you have successfully compiled on OSX, please consider doing complete documentation of the process (preferably from a fresh install). I've been known to donate to users who help with OSX compiling
You can stay up-to-date on Armory news, developments and tutorials through the webpage: http://www.bitcoinarmory.comCaveats:- Armory must have access to the Satoshi-created blk0001.dat file -- read-only access to see new blocks (usually autodetected)
- You must have the Satoshi client open and on the same network as the Armory client (main-net or testnet -- namecoin is untested)
- Satoshi client must be currently synchronized with the blockchain. Armory is not very good at "drinking from the firehose" when the client is downloading thousands of blocks very quickly...
Short-term development plans: (DONE) - Customizable SelectCoins algorithm: optimize for anonymity or minimal transaction fees.
- Enabling table sorting
(DONE) - System-tray and status-bar objects
(DONE) - Options/preferences dialog
(DONE) - Tutorials for using the codebase for potential developers/forkers.
(see extras/sample_armory_code.py) - Better and more robust layouts for cross-platform aesthetics
(DONE) [/list] Beta-version development plan:- File-based blockchain operations -- reduce RAM footprint from 1.5 GB to 100 MB.
(file-based blockchain DONE -- foot print still large) - Multi-signature transactions! These are actually implemented 95% under-the-hood, but just needs some testing and interface development.
Long-term plans:- Standalone networking -- will either implement native networking, or integrate Satoshi-client code for finding peers, downloading the blockchain, block validation, security, etc. Will remove requirement to have bitcoin/bitcoind in the background
- Sister smartphone client
- Two-factor authentication using phone and computer without third-party as described here. If anyone wants to help make this happen, I'm 90% done with this, I mainly just need an Android/iPhone app to support the wallet file and ECDSA signing.
And some screenshots!      See all screenshots on the Armory screenshots pageLICENSE:Armory is currently licensed under the AGPL v3. However, dual-licensing can be negotiated if someone wants to develop with Armory in closed-source software. PLEASE DONATE. This was a TON of work, and I'm not sure I can continue neglecting my girlfriend without getting some kind of compensation for the development time. Please use the "Donate" button on the send-bitcoins dialog in Armory. Here's the address if you are feeling generous without using the program 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX (yes, it's real!) Source Code: For anyone interested in development: Here is the Armory source code. Yes, there's a lot of code (and unit-tests!). Build Instructions:I have posted complete build instructions at following website: http://bitcoinarmory.com/index.php/building-armory-from-source[/list] |
|
|
|
|
You can add points together--that is the core operations of ECC math. Scalar multiplication is just an extension of that. If you have point P, then 5*P is just P+P+P+P+P. There is no such thing as point-to-point mulitplication.
|
|
|
|
Piachu, I just pulled out the three transactions I referenced in my first post, and put them into a form that you should be able to copy them right into your tests. Since all of them contain signature-checks, you will need the full serialized transaction -- which I have included. If you don't want the scripts separately, you can just concatenate the scripts: <TxIn | TxOut> 2-of-2 Transaction without OP_CHECKMULTISIG Testnet Tx Hash: 1c9608650a912be7fa88eecec664e6fbfa4b676708697fa99c28b3370005f32d
PrevTxOutScript: 526b006b7dac7ca914fc1243972b59c1726735d3c5cca40e415039dce9879a6c936b7dac7ca914375dd72e03e7b5dbb49f7e843b7bef4a2cc2ce9e879a6c936b6c6ca2
CurrTxInScript: 483045022017462c29efc9158cf26f2070d444bb2b087b8a0e6287a9274fa36fad30c46485022100c6d4cc6cd504f768389637df71c1ccd452e0691348d0f418130c31da8cc2a6e8014104e83c1d4079a1b36417f0544063eadbc44833a992b9667ab29b4ff252d8287687bad7581581ae385854d4e5f1fcedce7de12b1aec1cb004cabb2ec1f3de9b2e60493046022100fdc7beb27de0c3a53fbf96df7ccf9518c5fe7873eeed413ce17e4c0e8bf9c06e022100cc15103b3c2e1f49d066897fe681a12e397e87ed7ee39f1c8c4a5fef30f4c2c60141047cf315904fcc2e3e2465153d39019e0d66a8aaec1cec1178feb10d46537427239fd64b81e41651e89b89fefe6a23561d25dddc835395dd3542f83b32a1906aeb
CurrRawTx: 01000000011c9608650a912be7fa88eecec664e6fbfa4b676708697fa99c28b3370005f32d01000000fd1701483045022017462c29efc9158cf26f2070d444bb2b087b8a0e6287a9274fa36fad30c46485022100c6d4cc6cd504f768389637df71c1ccd452e0691348d0f418130c31da8cc2a6e8014104e83c1d4079a1b36417f0544063eadbc44833a992b9667ab29b4ff252d8287687bad7581581ae385854d4e5f1fcedce7de12b1aec1cb004cabb2ec1f3de9b2e60493046022100fdc7beb27de0c3a53fbf96df7ccf9518c5fe7873eeed413ce17e4c0e8bf9c06e022100cc15103b3c2e1f49d066897fe681a12e397e87ed7ee39f1c8c4a5fef30f4c2c60141047cf315904fcc2e3e2465153d39019e0d66a8aaec1cec1178feb10d46537427239fd64b81e41651e89b89fefe6a23561d25dddc835395dd3542f83b32a1906aebffffffff01c0d8a700000000001976a914fc1243972b59c1726735d3c5cca40e415039dce988ac00000000
Pretty TxIn Script:
[PUSHDATA -- 72 BYTES:]
3045022017462c29efc9158cf26f2070d444bb2b087b8a0e6287a9274fa36fad30c46485022100c6d4cc6cd504f768389637df71c1ccd452e0691348d0f418130c31da8cc2a6e801
[PUSHDATA -- 65 BYTES:]
04e83c1d4079a1b36417f0544063eadbc44833a992b9667ab29b4ff252d8287687bad7581581ae385854d4e5f1fcedce7de12b1aec1cb004cabb2ec1f3de9b2e60
[PUSHDATA -- 73 BYTES:]
3046022100fdc7beb27de0c3a53fbf96df7ccf9518c5fe7873eeed413ce17e4c0e8bf9c06e022100cc15103b3c2e1f49d066897fe681a12e397e87ed7ee39f1c8c4a5fef30f4c2c601
[PUSHDATA -- 65 BYTES:]
047cf315904fcc2e3e2465153d39019e0d66a8aaec1cec1178feb10d46537427239fd64b81e41651e89b89fefe6a23561d25dddc835395dd3542f83b32a1906aeb
Pretty TxOut Script:
2
OP_TOALTSTACK
OP_0
OP_TOALTSTACK
OP_TUCK
OP_CHECKSIG
OP_SWAP
OP_HASH160
[PUSHDATA -- 20 BYTES:]
fc1243972b59c1726735d3c5cca40e415039dce9
OP_EQUAL
OP_BOOLAND
OP_FROMALTSTACK
OP_ADD
OP_TOALTSTACK
OP_TUCK
OP_CHECKSIG
OP_SWAP
OP_HASH160
[PUSHDATA -- 20 BYTES:]
375dd72e03e7b5dbb49f7e843b7bef4a2cc2ce9e
OP_EQUAL
OP_BOOLAND
OP_FROMALTSTACK
OP_ADD
OP_TOALTSTACK
OP_FROMALTSTACK
OP_FROMALTSTACK
OP_GREATERTHANOREQUAL
2-of-3 Transaction without OP_CHECKMULTISIG Testnet Tx Hash: 2f654d4d1d7246d1a824c5b6c5177c0b5a1983864579aabb88cabd5d05e032e2
PrevTxOutScript: 526b006b7dac7ca9143cd1def404e12a85ead2b4d3f5f9f817fb0d46ef879a6c936b7dac7ca9146a4e7d5f798e90e84db9244d4805459f87275943879a6c936b7dac7ca914486efdd300987a054510b4ce1148d4ad290d911e879a6c936b6c6ca2
CurrTxInScript: 4730440220151ad44e7f78f9e0c4a3f2135c19ca3de8dbbb7c58893db096c0c5f1573d5dec02200724a78c3fa5f153103cb46816df46eb6cfac3718038607ddec344310066161e01410459fd82189b81772258a3fc723fdda900eb8193057d4a573ee5ad39e26b58b5c12c4a51b0edd01769f96ed1998221daf0df89634a7137a8fa312d5ccc95ed8925483045022100ca34834ece5925cff6c3d63e2bda6b0ce0685b18f481c32e70de9a971e85f12f0220572d0b5de0cf7b8d4e28f4914a955e301faaaa42f05feaa1cc63b45f938d75d9014104ce6242d72ee67e867e6f8ec434b95fcb1889c5b485ec3414df407e11194a7ce012eda021b68f1dd124598a9b677d6e7d7c95b1b7347f5c5a08efa628ef0204e1483045022074e01e8225e8c4f9d0b3f86908d42a61e611f406e13817d16240f94f52f49359022100f4c768dd89c6435afd3834ae2c882465ade92d7e1cc5c2c2c3d8d25c41b3ea61014104ce66c9f5068b715b62cc1622572cd98a08812d8ca01563045263c3e7af6b997e603e8e62041c4eb82dfd386a3412c34c334c34eb3c76fb0e37483fc72323f807
CurrRawTx: 01000000012f654d4d1d7246d1a824c5b6c5177c0b5a1983864579aabb88cabd5d05e032e201000000fda0014730440220151ad44e7f78f9e0c4a3f2135c19ca3de8dbbb7c58893db096c0c5f1573d5dec02200724a78c3fa5f153103cb46816df46eb6cfac3718038607ddec344310066161e01410459fd82189b81772258a3fc723fdda900eb8193057d4a573ee5ad39e26b58b5c12c4a51b0edd01769f96ed1998221daf0df89634a7137a8fa312d5ccc95ed8925483045022100ca34834ece5925cff6c3d63e2bda6b0ce0685b18f481c32e70de9a971e85f12f0220572d0b5de0cf7b8d4e28f4914a955e301faaaa42f05feaa1cc63b45f938d75d9014104ce6242d72ee67e867e6f8ec434b95fcb1889c5b485ec3414df407e11194a7ce012eda021b68f1dd124598a9b677d6e7d7c95b1b7347f5c5a08efa628ef0204e1483045022074e01e8225e8c4f9d0b3f86908d42a61e611f406e13817d16240f94f52f49359022100f4c768dd89c6435afd3834ae2c882465ade92d7e1cc5c2c2c3d8d25c41b3ea61014104ce66c9f5068b715b62cc1622572cd98a08812d8ca01563045263c3e7af6b997e603e8e62041c4eb82dfd386a3412c34c334c34eb3c76fb0e37483fc72323f807ffffffff01b0ad5407000000001976a9146a4e7d5f798e90e84db9244d4805459f8727594388ac00000000
Pretty TxIn Script:
[PUSHDATA -- 71 BYTES:]
30440220151ad44e7f78f9e0c4a3f2135c19ca3de8dbbb7c58893db096c0c5f1573d5dec02200724a78c3fa5f153103cb46816df46eb6cfac3718038607ddec344310066161e01
[PUSHDATA -- 65 BYTES:]
0459fd82189b81772258a3fc723fdda900eb8193057d4a573ee5ad39e26b58b5c12c4a51b0edd01769f96ed1998221daf0df89634a7137a8fa312d5ccc95ed8925
[PUSHDATA -- 72 BYTES:]
3045022100ca34834ece5925cff6c3d63e2bda6b0ce0685b18f481c32e70de9a971e85f12f0220572d0b5de0cf7b8d4e28f4914a955e301faaaa42f05feaa1cc63b45f938d75d901
[PUSHDATA -- 65 BYTES:]
04ce6242d72ee67e867e6f8ec434b95fcb1889c5b485ec3414df407e11194a7ce012eda021b68f1dd124598a9b677d6e7d7c95b1b7347f5c5a08efa628ef0204e1
[PUSHDATA -- 72 BYTES:]
3045022074e01e8225e8c4f9d0b3f86908d42a61e611f406e13817d16240f94f52f49359022100f4c768dd89c6435afd3834ae2c882465ade92d7e1cc5c2c2c3d8d25c41b3ea6101
[PUSHDATA -- 65 BYTES:]
04ce66c9f5068b715b62cc1622572cd98a08812d8ca01563045263c3e7af6b997e603e8e62041c4eb82dfd386a3412c34c334c34eb3c76fb0e37483fc72323f807
Pretty TxOutScript:
2
OP_TOALTSTACK
OP_0
OP_TOALTSTACK
OP_TUCK
OP_CHECKSIG
OP_SWAP
OP_HASH160
[PUSHDATA -- 20 BYTES:]
3cd1def404e12a85ead2b4d3f5f9f817fb0d46ef
OP_EQUAL
OP_BOOLAND
OP_FROMALTSTACK
OP_ADD
OP_TOALTSTACK
OP_TUCK
OP_CHECKSIG
OP_SWAP
OP_HASH160
[PUSHDATA -- 20 BYTES:]
6a4e7d5f798e90e84db9244d4805459f87275943
OP_EQUAL
OP_BOOLAND
OP_FROMALTSTACK
OP_ADD
OP_TOALTSTACK
OP_TUCK
OP_CHECKSIG
OP_SWAP
OP_HASH160
[PUSHDATA -- 20 BYTES:]
486efdd300987a054510b4ce1148d4ad290d911e
OP_EQUAL
OP_BOOLAND
OP_FROMALTSTACK
OP_ADD
OP_TOALTSTACK
OP_FROMALTSTACK
OP_FROMALTSTACK
OP_GREATERTHANOREQUAL
2-of-3 Transaction with OP_CHECKMULTISIG Testnet Tx Hash: bb664ff716b9dfc831bcc666c1767f362ad467fcfbaf4961de92e45547daab87
PrevTxOutScript : 537a7652a269537a829178a91480677c5392220db736455533477d0bc2fba65502879b69537a829178a91402d7aa2e76d9066fb2b3c41ff8839a5c81bdca19879b69537a829178a91410039ce4fdb5d4ee56148fe3935b9bfbbe4ecc89879b6953ae
CurrTxInScript: 00493046022100d73f633f114e0e0b324d87d38d34f22966a03b072803afa99c9408201f6d6dc6022100900e85be52ad2278d24e7edbb7269367f5f2d6f1bd338d017ca460008776614401473044022071fef8ac0aa6318817dbd242bf51fb5b75be312aa31ecb44a0afe7b49fcf840302204c223179a383bb6fcb80312ac66e473345065f7d9136f9662d867acf96c12a42015241048c006ff0d2cfde86455086af5a25b88c2b81858aab67f6a3132c885a2cb9ec38e700576fd46c7d72d7d22555eee3a14e2876c643cd70b1b0a77fbf46e62331ac4104b68ef7d8f24d45e1771101e269c0aacf8d3ed7ebe12b65521712bba768ef53e1e84fff3afbee360acea0d1f461c013557f71d426ac17a293c5eebf06e468253e00
CurrRawTx: 0100000001bb664ff716b9dfc831bcc666c1767f362ad467fcfbaf4961de92e45547daab8701000000fd190100493046022100d73f633f114e0e0b324d87d38d34f22966a03b072803afa99c9408201f6d6dc6022100900e85be52ad2278d24e7edbb7269367f5f2d6f1bd338d017ca460008776614401473044022071fef8ac0aa6318817dbd242bf51fb5b75be312aa31ecb44a0afe7b49fcf840302204c223179a383bb6fcb80312ac66e473345065f7d9136f9662d867acf96c12a42015241048c006ff0d2cfde86455086af5a25b88c2b81858aab67f6a3132c885a2cb9ec38e700576fd46c7d72d7d22555eee3a14e2876c643cd70b1b0a77fbf46e62331ac4104b68ef7d8f24d45e1771101e269c0aacf8d3ed7ebe12b65521712bba768ef53e1e84fff3afbee360acea0d1f461c013557f71d426ac17a293c5eebf06e468253e00ffffffff0280969800000000001976a9140817482d2e97e4be877efe59f4bae108564549f188ac7015a7000000000062537a7652a269537a829178a91480677c5392220db736455533477d0bc2fba65502879b69537a829178a91402d7aa2e76d9066fb2b3c41ff8839a5c81bdca19879b69537a829178a91410039ce4fdb5d4ee56148fe3935b9bfbbe4ecc89879b6953ae00000000
Pretty TxIn Script:
OP_0
[PUSHDATA -- 73 BYTES:]
3046022100d73f633f114e0e0b324d87d38d34f22966a03b072803afa99c9408201f6d6dc6022100900e85be52ad2278d24e7edbb7269367f5f2d6f1bd338d017ca460008776614401
[PUSHDATA -- 71 BYTES:]
3044022071fef8ac0aa6318817dbd242bf51fb5b75be312aa31ecb44a0afe7b49fcf840302204c223179a383bb6fcb80312ac66e473345065f7d9136f9662d867acf96c12a4201
2
[PUSHDATA -- 65 BYTES:]
048c006ff0d2cfde86455086af5a25b88c2b81858aab67f6a3132c885a2cb9ec38e700576fd46c7d72d7d22555eee3a14e2876c643cd70b1b0a77fbf46e62331ac
[PUSHDATA -- 65 BYTES:]
04b68ef7d8f24d45e1771101e269c0aacf8d3ed7ebe12b65521712bba768ef53e1e84fff3afbee360acea0d1f461c013557f71d426ac17a293c5eebf06e468253e
OP_0
Pretty TxOut Script:
3
OP_ROLL
OP_DUP
2
OP_GREATERTHANOREQUAL
OP_VERIFY
3
OP_ROLL
OP_SIZE
OP_NOT
OP_OVER
OP_HASH160
[PUSHDATA -- 20 BYTES:]
80677c5392220db736455533477d0bc2fba65502
OP_EQUAL
OP_BOOLOR
OP_VERIFY
3
OP_ROLL
OP_SIZE
OP_NOT
OP_OVER
OP_HASH160
[PUSHDATA -- 20 BYTES:]
02d7aa2e76d9066fb2b3c41ff8839a5c81bdca19
OP_EQUAL
OP_BOOLOR
OP_VERIFY
3
OP_ROLL
OP_SIZE
OP_NOT
OP_OVER
OP_HASH160
[PUSHDATA -- 20 BYTES:]
10039ce4fdb5d4ee56148fe3935b9bfbbe4ecc89
OP_EQUAL
OP_BOOLOR
OP_VERIFY
3
OP_CHECKMULTISIG
Note that all of these scripts are non-standard. They are actually designed to allow for 20-byte public keys hashes to be used as input instead of 65-byte public keys. As such, they are very complicated because the script has to verify that the public keys match 2 of the hashes in the TxOut script. Also, be careful with you Hash160 calls. As I learned from testing my own scripting engine, OP_0 is interpretted as [] (empty string), which means it can be hashed and has zero length. Those are both important for passing those script tests. |
|
|
|
robkohr, I am one week away from releasing an alpha version of Armory which does exactly what you are requesting. The only thing remaining is the dialogs that allows the user to easily sign transactions using the offline wallets. Armory will be the best program for offline transactions, miles ahead of all other attempts! You won't even need to keep the blockchain on the offline computer! Here's a screenshot of the "Paper Backup" dialog:  You only need to print it once, when the wallet is first created, and it will serve as a permanent backup for the deterministic wallets. Also, you can create such a wallet on the offline computer, then "Make a watching-only" wallet which can be copied to the online computer and can be used to generate addresses and verify payments, but does not have access to the private keys. If you want to get in on early testing, let me know -Eto |
|
|
|
25,000 is the minimum. The client tests the speed of your system and determines how much computation can be done in ... 0.1s? If it's 40,000 SHA512 hashes, it uses that. If it's 10,000, it uses 25,000. i.e. max(computeSysSpeed(), 25,000) So that value must be stored in the wallet file somewhere, I just don't know where... mcorlett... if you figure this out, I think I have all the other pieces it would take me a couple hours to put together a script that would take nDeriveIter and the passphrase, and spit out a list of pub/priv keypairs... maybe we could negotiate a splitting of the bounty for this? |
|
|
|
So I think I will help everyone with this wallet-extraction thing. I was the one that found unencrypted keys in the 0.4.0 encrypted wallet, so I'm pretty sure I can find the encrypted keys And Armory uses a very similar technique for encryption, so I'm basically already set up for this. A few things I hope someone will be able to answer for me. (1) I need to find nDeriveIterations. Is there an easy way to find it for a hex-diver like me, or do I actually have to open the DB file with a BDB library to get to it? (2) I wish I'd thought of using the public key as the IV... that's pretty smart. I assume it is the 65-byte private key that you double-sha256, correct? Then, is it the first 16 bytes that are used for the IV? AES256 IVs are only 16 bytes... (3) Is there any modification to the passphrase before applying X sha512 operations to it? Is there any PBKDF2 calls somewhere? (if there is, I'm not as well-prepared as I thought) If anyone wants to simply use the work I've already done and split any appropriate bounties, I would be up for that I have a python script which currently goes through the wallet.dat file pulls out every single public key, and then grabs any plaintext private keys nearby. Of course, they private keys are not plaintext in this situation, but I can spit out the data where I expect the keys to be. Then using CLI input params, I can actually apply the X sha512 operations and AES256-CBC decryption, provided with X and the passphrase. I wouldn't mind doing this anyway, because I had planned on creating a wallet-conversion/import tool for Armory, but figured it was too much of a hassle. Maybe now is a good time to deal with it |
|
|
|
I might take a shot at this, since I have a very similar encryption scheme in the client I'm about to release. It's a pretty healthy bounty, too The only thing I don't know for sure, is where to find the nDeriveIterations value. I'm sure it's stored in the wallet file somewhere... |
|
|
|
Hmm, are those dumps from the multi-sig complete, or abbreviated? Since you seem to be calling checksig on "30460221 047cf315", which would make one of them a public key. Aren't those supposed to be longer?
Sorry, they are abbreviated to make it readable, and they are unique so there is no ambiguity. The debugging states were only intended to be examined by eye, to make sure that the script processor was doing the right thing. If you want to run those tests yourself, you can grab the TxHash from the top of the debugging output, and search for it in the full list of Testnet scripts. In each of the testnet scripts, I included the raw script (in hex) and the full raw tx (in hex). From that, you should have just about everything you could possibly need to run those scripts through your scripting engine. |
|
|
|
|
Show Posts
