Topic: Armory - Discussion Thread - page 109. (Read 521829 times)

I have a question regarding scripting with armory.

say for instance I was wanting to set up a custom script utilizing bitcoin's sendmany RPC command.  Normally, if I were not using the armory cold storage (or armory at all), this would be a fairly simple matter being able to just call the command.

Since I want to do this via armory's cold storage, I would need to create the offline transaction but I am having a hard time trying to find info regarding how to do this in a script as opposed to using the GUI and manually choosing every single address I want to send to.

I am envisioning a script where I can pull in a list of addresses and payment amounts, check that there are no duplicates, if there are, combine the payout amounts and send the addresses and their payments into sendmany, create the offline transaction and have it save the output to a file that I can then go to my offline wallet to sign (this I would do manually as it doesn't take much time).

Then I would just continue normally without the script from there (go back to online and broadcast it).  This would save me a ton of time manually entering addresses into armory.

I used to do this with the bitcoin client, but I moved to armory a long time ago and it's been bugging me recently.

Any insights?  Is it possible that I'm just missing an important piece to the puzzle?  Since Armory uses the bitcoin client on the backend, I wonder if the scripting would be the same, but the bitcoin client wouldn't have the offline data (ie private keys) this is what is throwing me currently.

Thank you very much for that information! I really trust your wallet and I love it that you are really caring about a good implementation and testing etc of your wallet!

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


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. 

https://bitcointalksearch.org/topic/bad-signatures-leading-to-5582152538-btc-theft-so-far-271486

Is armory effected?

Thanks etotheipi for the fast response. All solved now. (dc81, good info, might be useful another time).

Comment about OSX. I know little about macs as I have always used other OSs. I am just recently using a mac for Armory.  I conclude that finder and spotlight are pieces of junk. No wonder there are loads of threads on the web about these two apps failing to find files (even after selecting invisible and system files and all similar obscurities). Tempelmann's findanyfile is fantastic and did the trick!

if you can copy the raw transaction in hex, paste it here - https://blockchain.info/pushtx

this is off-topic with respect to armory specifically, but if it keeps crashing because of memory shortages, you might want to check this stupid file in your windows task list:

aaHMSvc.exe

it's an Asus service that has memory leak issues, and for me, was taking up a full GB of memory, causing armory to crash on load every time.

killing that process solved my armory dilemma.

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

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...

Oh I didn't realize I could register multiple wallets simultaneously!
Thanks again!

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).

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

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)

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

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.


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.  

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?

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.

It just takes a few minutes to install a linux virtualbox.  At worst, if you trust someone on the website you could encrypt your recovery key with their public key and they could send you the funds to another address.

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.

What about ram though?

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.