Check BitcoinArmory/extras/createTxFromAddrList.py. Also sample_armory_code.py in that same directory has a lot of useful stuff. Admittedly, some of the examples, including createTxFromAddrList.py, uses an old version of the blockchain utiltiies -- for instance, BDM_LoadBlockchainFile() no longer works/exists. If you see this: BDM_LoadBlockchainFile()
walletObj.setBlockchainSyncFlag(BLOCKCHAIN_READONLY)
walletObj.syncWithBlockchain()
Replace it with this: TheBDM.setBlocking(True)
TheBDM.setOnlineMode(True)
TheBDM.scanBlockchainForTx(wlt.cppWallet)
Other than that, I think everything is the same, so you have an almost-full solution there! Also check extras/cli_sign_txdp.py which can be used on the offline computer to load your wallet, load an unsigned transaction, unlock your wallet, get your confirmation, and then sign it for you. Try it out! I made both of these to help scripters like you  |
|
|
|
That's an amateurish problem that only happens with custom implementations of ECDSA. You have to use a random number when calculating the signature, and every basic implementation of ECDSA guarantees this (at least to the extent of the randomness it can pull from your system). The problem there was people hand-rolling their own and not realizing that reusing "random" numbers when signing different messages with the same key reveals the private key. This was the same reason that Sony's PS3 signing key was compromised: https://groups.google.com/forum/#!topic/sci.crypt/3isJl28Slrw Each key (for each different type of loader) seems to have an
associated random number ‘m’ — the numbers follow no pattern, but they
are consistent between different signatures on different versions of the
same loader — almost as if they treated ‘m’ as one of the parameters of
the key.
If I understand correctly this means Sony decided they were smart enough
to reimplement their own version of ECDSA from scratch.
Famous last word. Armory is unaffected. And for reference, you don't even need good random numbers for it. You just need anything that changes between signatures and looks random. |
|
|
|
2013-08-10 01:23 (ERROR) -- Traceback (most recent call last):
File "qtdialogs.pyc", line 281, in acceptPassphrase
File "armoryengine.pyc", line 9083, in unlock
File "armoryengine.pyc", line 2660, in unlock
File "armoryengine.pyc", line 2691, in unlock
KeyDataError: Stored public key does not match priv key!
This suggests actual corruption? Anyway, your suggestion would be to restore from paper backup and make sure to only generate 500 at a time? It already "knows" that there are 10k public keys. Oh yeah, that's real wallet corruption! I have code in there to attempt to avoid that (it updates two files sequentially, writing flags in between so it can determine where it failed writing and restore the good copy. But I guess it's not 100% reliable). I've only ever had a couple reports of corrupted wallets, so it can't be that bad, but I don't know if it helps... Personally, to avoid a lengthy extended scan, I would delete the wallet, restart in offline mode, restore from paper backup, then generate 1000 addresses at a time. Try viewing the paper backup after each batch of 1000 to unlock. If 1000 takes too long, scale it down to 500. Yeah, it's annoying. There's only two other ways: (1) Temporarily remove wallet encryption before you generate the addresses. It will write the unencrypted keys to disk, though. Then re-encrypt when you're done. (2) If you want to mess with the code, you could change the wallet-lock timeout from 10 seconds to something much much longer. Then when you unlock the wallet, it should stay unlocked and generating the keys will be as if it's unencrypted. No guarantees, but that might just work. If you want to try it, change the "wlt.defaultKeyLifetime" for all wallets in armoryengine.py:6855. Change it from 10 to something like 20*MINUTE. You'll know it was effective if you unlock your wallet to view your paper backup, and then try again 5 minutes later and it doesn't ask you for your passphrase. If you try #2, let me know if it works. I think it will, but I've never tried it. |
|
|
|
|
There is a wild inefficiency with unlocking the wallet when the addresses were originally generated encrypted. That was going to be fixed with the new wallets, but I haven't gotten there yet.
I know you don't want to let your keys hit the hard-drive unencrypted. But if you can tolerate it, I recommend you remove encryption from your wallet, generate 10,000 keys, then encrypt it again. I would've had a bunch of wallet code restructuring to get around this, and so far, only one other person in the last 18 months has reported trying this.
The issue comes down to this: when you generate new addresses and the wallet is encrypted, it simply extends the public keys and marks that the private keys need to be generated on the next unlock. But for reasons I can't remember, it does it all out of order, regenerating the same path of private keys (and checking the public keys) on for each address, and so it executes in O(N2) time instead of O(N). N is the number of private keys to be computed.
For that reason, if you generate, say, 500 addresses at a time without removing encryption (unlocking between each batch), you can probably get around it. The concept to fix it in code is simple, but implementing that in the code was a PITA, so I skipped it. And it will be resolved when I finish the new wallet format (in 10 years, after I finish all my other priorities).
|
|
|
|
Got a problem with send transaction. I tried sending some BTC from Armory while the laptop was connected to a cafe wifi. Armory considers the transaction sent, but the BTC network never got it. Presumably the port needed was blocked. Any ideas are very welcome on how to get rid of the unsent transaction so the wallet shows the correct balance...
Not sure what OS you're in, but there's a file in your Armory home dir called mempool.bin. Delete it. Then restart Armory: C:\Users\username\AppData\Roaming\Armory\mempool.bin /home/username/.armory/mempool.bin <don't remember what it is for OSX> |
|
|
|
Is there a way to clear a wallet and load it with different addresses? I have:
cppWallet=Cpp.BtcWallet()
for address in addressFile:
cppWallet.addAddress_1_(addrStr_to_hash160(address))
TheBDM.registerWallet(cppWallet)
TheBDM.scanBlockchainForTx(cppWallet)
print coin2str(cppWallet.getSpendableBalance())
Then I'd like to:
destroy cppWallet (or clear it)
and load another address watching file & rescan for a balance
You can register multiple wallets with the BDM and get each balance independently. In fact, by doing this, you can do all the wallets in a single blockchain scan. I think I added a way to unregister addresses after you don't need them, but I wouldn't bother with it, unless you're doing tens of thousands of addresses and you need to free up resources (and I don't think I made a way to do this... if you really need it your way, you could wrap all this into an executable, and just call the executable in a fresh environment for each batch of addresses). |
|
|
|
It looks like Armory addresses use uncompressed keys when generating addresses.
Wouldn't it be better to use compressed ones?
It should definitely detect money sent to both (for example, if "someone" was generating the key sequences manually :p).
When I finally get around to updating the wallet format, I will support compressed public keys. Despite its simplicity, Armory's wallet file format and code has been extremely well-tested and I didn't want to risk breaking something to make that update. I consider it one of the reasons there's never been a money-destroying bug in Armory. At the time that I started writing the wallet code, I didn't even know compressed public keys existed. It was especially frustrating, because I went through the effort to implement a Satoshi-wallet-migration process into Armory, and then it became useless since Armory couldn't handle the private key format. Oh well. |
|
|
|
This has been a pain in the ass, etheopi, could you please post your GPG public key so I can send you my root and chain codes so you can recover what's in the wallet? It's only 0.014
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x11DEE9BEFB596985( please use that GPG key and not the "Offline Signing Key" that everyone finds first when they look up my GPG key by email... it's a pain in the @$$ if you use that other key) |
|
|
|
Using armoryengine:
After it loads the blockchain with TheBDM.setOnlineMode(True) does it continually monitor for new blocks from bitcoind? Or do I need to reload the whole blockchain to see new transactions?
You don't need to rescan, but there is a monitoring loop that needs to be run. I don't remember how exactly to set that up... but obviously Armory (application) does it, so you can look there for hints. It might be as simple as "readBlkFileUpdate()", which checks where the end of the last block was in the blkfiles and determines if anything new has been added. If your wallets are registered with TheBDM, they should update automatically. That's 95% of what you need to do, but you should check where that function is called in Armory to determine if it needs more. ( EDIT: check armoryd.py -- it implements this monitoring loop with a much more minimal context. It might be easier to figure it out from there. And is there a way to just load the last few months worth of blocks to speed up the loading of the blockchain? Say I have an address I just generated, I know there won't be any transactions to it from before today, I don't really need to load March 2013 transactions, right? I can assume bitcoind validated everything when it downloaded them.
Theoretically, yes, but it's not setup that way. If the blockchain is already loaded, you can add the new address/wallet with a "born-on" block, and it will determine that it only needs to rescan those blocks. But I also seem to remember having the thought that it was kind of complicated to do a partial rescan and for addresses/wallets older than a couple days, I just wipe and rescan everything. If I can ever finish this "persistent blockchain" update, the very first implementation will actually have a full-address-index lookup, so you won't ever have to rescan anything, except when you completely rebuild the DB (if say, it was corrupted). You should be able to import addresses and wallets nearly instantly. Of course, it comes with a huge HDD hit, but it's far preferable compared to high RAM usage, and makes it much easier to run advanced processing of blockchain information. Stay tuned for that one ... I'm battling a lot more changes than I thought I would need to, but it looks feasible. |
|
|
|
Alternatively, rather than rebooting the system into a live session, you could download VirtualBox and install an Ubuntu 10.04 VM (you can just add a "CD" device and point it to the downloaded *.iso). Then you can use it to access Armory the way I described.
In fact, you wouldn't even have to deal with the offline bundle, because you'd be connected to the internet and the regular .deb file would install fine.
What about ram though? You don't need online mode to get your private keys out of your wallet. If you are in offline mode, RAM usage is nil. |
|
|
|
|
Alternatively, rather than rebooting the system into a live session, you could download VirtualBox and install an Ubuntu 10.04 VM (you can just add a "CD" device and point it to the downloaded *.iso). Then you can use it to access Armory the way I described.
In fact, you wouldn't even have to deal with the offline bundle, because you'd be connected to the internet and the regular .deb file would install fine.
|
|
|
|
Please help  PM me if you can help me turn my paper wallet into private keys. Mooshire... the only way I can help you is if you can get Ubuntu working somewhere and use it to access your wallet. The easiest thing to do would probably be to download an Ubuntu 10.04 Live CD and the Armory Offline Bundle for Ubuntu 10.04. Boot into the live session, download that offline bundle desktop, unpack it, click the install script, then run Armory and Import your paper backup. Once it's imported, you can open the wallet and go to "backup individual keys". Click on "Show Unused Keys", and you'll have access to all of them. I don't know any other (secure) way to access your private keys. You have to be able to run Armory in offline mode somewhere. And then you will have access to them. |
|
|
|
I'm trying to use armoryengine to find the balance of some addresses. I tried following the example from import500kaddresses, but get an error. from armoryengine import *
wlt = Cpp.BtcWallet()
wlt.addAddress_1_( hex_to_binary('9c633b56899c633b56899c633b56899c633b5689') ) # hash160
TheBDM.registerWallet(wlt)
start = RightNow()
TheBDM.setBlocking(True)
TheBDM.setOnlineMode(True)
print 'Loading blockchain took %d seconds' % int(RightNow()-start)
wlt.setBlockchainSyncFlag(BLOCKCHAIN_READONLY)
wlt.syncWithBlockchain()
print 'Full sync at %d seconds' % int(RightNow()-start)
print 'Wallet balance is: %s' % coin2str(wlt.getBalance('Spendable')) Loading blockchain took 916 seconds Traceback (most recent call last): File "/home/user/BitcoinArmory/balance.py", line 16, in <module> wlt.setBlockchainSyncFlag(BLOCKCHAIN_READONLY) File "/home/user/BitcoinArmory/CppBlockUtils.py", line 1087, in <lambda> __getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name) File "/home/user/BitcoinArmory/CppBlockUtils.py", line 51, in _swig_getattr raise AttributeError(name) AttributeError: setBlockchainSyncFlag Any ideas? It looks like the permissions are fine and I deleted all the lock files I could find. Ugh. I need to update all that old example code. That particular file is ancient and uses functions that don't exist anymore. I'm pretty sure most of the examples in extras/sample_armory_code.py is good though. At least, the methods for loading and accessing the blockchain. |
|
|
|
Interesting. Can you do me a favor and make a copy of the Armory shortcut on your desktop, then right click on the copy and add the following string to the "Target:" --offline --skip-version-check --skip-online-check Make sure there's a space between the end of the existing "Target" and that extra text. Then try running it again. Also, it looks like you're using Windows Server 2008, which theoretically should work but not everyone has had success. I never figured out what was different about it... |
|
|
|
Armory has stopped working, how can I take my encrypted wallet and get the first like 10 private keys from it?
Open Armory in offline mode (there's a shortcut installed on both Windows an Linux when you use the installer), then use "Backup Individual Keys" to get access to all the keys in the wallet. I try, but armory just goes so incredibly slow and freezes, which is my problem. It goes that slow in offline mode? There's very little it should be doing in offline mode. Anything unusual about your system? Can you send me a log file? How to send log file? Also, I have a paper backup for the wallet in question If you can get into Armory, it's under "File"-->"Export Log File". If not, you can just go straight to your home directory: C:\Users\<yourusername>\AppData\Roaming\Armory\Armory.exe.log (the .log file name may be slightly different). It's great you have a paper backup.... using that will be our last resort (basically, you need a working version of Armory in order to use it). |
|
|
|
Armory has stopped working, how can I take my encrypted wallet and get the first like 10 private keys from it?
Open Armory in offline mode (there's a shortcut installed on both Windows an Linux when you use the installer), then use "Backup Individual Keys" to get access to all the keys in the wallet. I try, but armory just goes so incredibly slow and freezes, which is my problem. It goes that slow in offline mode? There's very little it should be doing in offline mode. Anything unusual about your system? Can you send me a log file? |
|
|
|
|
Are you on a 32-bit OS and/or have less than 6 GB of RAM? Armory is just not going to work on those systems anymore until the next update. I keep claiming it will be fixed soon, but so far it's taking [much] longer than expected, so... "soon" is all I can give you.
|
|
|
|
Armory has stopped working, how can I take my encrypted wallet and get the first like 10 private keys from it?
Open Armory in offline mode (there's a shortcut installed on both Windows an Linux when you use the installer), then use "Backup Individual Keys" to get access to all the keys in the wallet. |
|
|
|
Can you make it so that you can broadcast signed transactions immediately when loading armory, instead of waiting for it to scan the transaction history?
Or is it possible to broadcast it from bitcoin-qt? I tried sendrawtransaction and pasting in my signed transaction, but it complains about it not being a serialized hex string.
I should find a way to make that easier for sure. But hopefully it won't matter so much after the need upgrade. For now : -switch to expert user mode -click on offline transactions -broadcast signed transaction -load the transaction from file or clipboard -click "Copy Raw TX (hex)" Now the clipboard should contain the properly-formatted tx to be copied into bitcoin-qt or blockchain.info pushtx (I forget the exact URL, and I'm on my phone right now making it hard to look up) |
|
|
|
I just had a random scary thought.
Is there anyway that editing the makefile like I've done in order to get it to compile could possibly jeopardize the coins in my wallets? Like, for example, being able to send bitcoins to my armory wallets but not being being able to spend them, because the wallets are invalid because of some tweaking made to the makefile?
Only if you tweaked the makefile to point to a library that identical code/functions/interfaces, but produced different (incorrect) answers. This is basically impossible without something malicious going on, or if the version of your library has a bug so extraordinary that it produces incorrect public keys for a given private key -- which would be caught immediately with any respectable crypto library before an official release. |
|
|
|
|
Show Posts
