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

Sure, give me a few mintues just starting the client.

Really nice program though, apart from those issues it's a fantastic program. Only "feature" I'm missing is being able to delete non-imported addresses: just to be able to organise a wallet more effectively.

Something is awry if the data is in the blockchain and a restart doesn't show the coins.  It means that Armory is having difficulty accessing the blk000X.dat files maintained by Bitcoin-Qt.  Transactions disappearing is concerning, too. 

Could you do me a favor before going back to Bitcoin-Qt and export the log file for me?  It should have record of any errors triggered in the last couple times you opened the client.  There is no private key data in there (you can empty the wallets first, if it makes you feel better).  I just want to see what kinds of errors were showing up when you were having this difficulty...  (File->Export Log File)

I'm having a few issues:
I've had 8 transactions comes through since I started using Armory yesterday, on each occasion the transaction was instantly displayed within the ledger window, but after a few minutes it just disappeared, and "unconfirmed balance" went back to zero; at this point blockchain.info reported them as having between 2-5 confirmations, and they did come back after a good number of hours and some restarts of the client, but even as unconfirmed they should still be displayed.

Think I may switch back to bitcoin-qt at this point, as it's taking hours to even see if someone has sent me anything, and I'm having to rely upon looking everything up manually.

Odd... can you create a new shortcut for it and run it with the " --debug" flag?  That might reveal a little more information.  Unfortunately, it sounds like a seg-fault...

I installed https://github.com/downloads/etotheipi/BitcoinArmory/armory_0.82.4-alpha_win32_and_win64.msi which runs for a few seconds and then silently dies without logging anything. Same immediately after a reboot with bitcoin-qt running and up to date on blockchain. Any troubleshooting I should do?


Connections are default (125), though with NAT I have none incoming and just my default 8 outgoing. So I should be able to accept another 117 connections locally.

Thanks to you both for the help.

Back from Armory vacation!

The last month has been devoted to lots of random things, the biggest of which is wedding planning.  I also got distracted by some random side projects and even a couple games.  However, it was a much needed break after an epic battle to make Armory multi-threaded -- I hit a frustrating combination of threads losing synchronization causing difficult-to-debug seg faults, etc.  I spent days debugging, and I was desperate to be distracted by something else... so I found other things...

However, I jumped back in recently feeling refreshed, and without any other distractions (plus, a few days off of work due to Hurricane Sandy gives me some time to dig in).  After a rough re-entry battle, I found a single bug that seemed to clear up almost everything.  There's still some features remaining to be implemented for the GUI to play nice with asynchronous BlockDataManager.  But most of it is working.  I even had it running for two days without any issue -- I didn't actually send any coins in that time, but at least there are no memory leaks or issues with reorgs, etc.

Additionally (and importantly), I optimized some of the blockchain scanning code, so now mega wallets (with 1000+ addresses) should operate much more fluidly.  The fix seemed too easy, and I seem to remember there was a reason I didn't do this 4 months ago... but so far I can't see anything wrong with it.  Testing will be key.

So, I don't have an official testing release yet, but maybe ambitious folks like Red Emerald would be inspired to check out the "threading" branch and try it  It'll throw a few errors for some operations (like shutting down), but it won't lose you any money -- the worst that can happen is the GUI loses communication with the BlockDataManager and then you can't view balances, etc (but I haven't seen that happen recently).  If you do test it:  please open the latest stable version first (0.82.4) and write down your wallet balances, to compare to the balances reported by the new version.  I want to make sure wallet scanning is still reliable.  

When multi-threaded Armory is stable, that will be beta!  0.82.4 has been working very reliably, and this new version (0.84) will be tremendously more usable, now that it opens immediately and tells you what's going on (scanning, offline, disconnected, why it can't go online, what you can do in each mode, etc).  Hopefully, it will be no more than a couple weeks!


EDIT:  As I should've expected... I broke a lot more things than I thought I did.  It seems that all import/sweep operations only update the wallet balances after a restart  (probably related to the scanning code I updated).   So I still have plenty of work to do here...

Red Emerald:  I called you out specifically, because I think you had tried this version before, and found it unusable -- I discovered the exact same thing when someone sent me a wallet with 1000 addresses with 1000+ transactions.  The scan operation was running in O(N²logN) instead of O(N logN), causing the GUI to timeout while waiting for updates from the BDM.  This was only noticeable when you have tons of addresses (which is why I didn't see it at first, but then ran into it after someone sent me a huge wallet)

inglian, are your network connections limited on bitcoin.conf? If so, take out the limit.
I faced similar problems when I had the number of connections limited to 25, so Armory would only connect to the bitcoin client when one of the regular network clients dropped it's connection.

This problem has come up quite a few times in the past, but it was so long ago I honestly don't remember if it was ever resolved.  However, there have been some networking-related bug fixes since then.  Please download 0.82.4 and try again:  https://github.com/etotheipi/BitcoinArmory/downloads

My first attempt at broadcasting an offline transaction with Armory kept silently failing. Logs show "ConnectionError: Connection to localhost DNE" despite Armory showing "Connected" status on the main screen and current block number.

I finally had to use command line bitcoind sendrawtransaction on the full tx hexcode in the log. Would be nice if the "Copy Raw Tx" button included the signature.

Thanks for creating Armory; small tip included in tx 4e347493f888f21d2f4163171c5ec20bc7c965df0aba83934e7880e9e5c829c2

Using Armory 0.82.2 on Win7-64 with Bitcoin-qt 0.7.1.

First private key + chaincode = compromise of all private keys (security fail)
First public key + chaincode = reveal all public keys/address (privacy fail)

The chaincode by itself is not useful.  Even if someone gets the chaincode, they still need your first public key in order to derive the rest of your public keys (your first Bitcoin address is not enough).

And even if someone got your first one million public keys, they wouldn't be able to deduce the chaincode.  The same goes for private keys:  if someone has the first N public or private keys, they won't be able to compute public or private key N+1 without the chaincode.

People should not be sharing private keys from their Armory wallets.  Or really, any wallet, except under bizarre/experimental circumstances.  They're called "private" for a reason.

According to this topic https://bitcointalksearch.org/topic/deterministic-wallets-and-sharing-private-keys-114701 the sharing of private key from deterministic wallet is bad. As I understand the attacker need to know both private key AND the chaincode to calculate and steal all other possible keys, right? The chaincode is kept on computer and as long as the computer security is not compromised the chaincode remains secret.

The EC math used to generate the keys is pretty much the same as the EC math used to perform the digital signatures in transactions.  As in, if you can run the key sequence backwards and find the root key, you probably don't need to.

Hidden by default with checkbox to show/hide could be nice!If generated address is not dependent on previously generated address in any way than it might be OK. Many so called "attacks" against crypto algorithms require related keys. Not a math expert myself I don't know if this is applicable to Armory generated address. But the blockchain transactions might be somewhat compromised if the addresses can be linked using this method. Basically then You cannot then just say "sorry officer, I sold all those Bitcoins I purchased from my MtGox account to someone else I don't personally know. I did not know he will be ordering drugs from you straight away!"

The solution might be a non-deterministic wallet possibility. It might be available under "Advanced" options where currently crypto options are located with appropriate warnings that paper backup is not possible with such type of wallets. The deterministic type must be the default type of wallet because users who use Armory over other clients and front-ends are probably because they need the deterministic property and paper backup functionality.

And Thank You for creating Armory! It is a great job, it functions well enough and offline wallets and offline signing are easy to use and probably only way to not lose precious Bitcoins to hacking.

Armory uses the Crypto++ library, which handles all the entropy operations.  I remember once seeing a list of entropy sources used by Crypto++ but I can't find it now.  All that matters is that it "is suitable for cryptographic purposes"  (it is a standard crypto library, though it's kind of slow).


Addresses cannot be linked unless you know the chaincode, which is stored in both full wallets and watching-only wallets.  Without access to at least the watching-only wallet,  there is no way for anyone to associate two addresses or public keys.  The strength of this non-linkage is as strong as the inability for someone to derive your private key from your public key. 



I don't know exactly what you mean... but Armory will generate a new address for you every time you click "Receive Bitcoins", and also when it needs to send change to itself.  I recently started flagging addresses in the wallet properties that were created solely for change.  Some people had asked about how to tell the difference, and there really wasn't a way.  Now all change addresses are marked with "[[Change Received]]", and you can sort by comment field to look through change addresses or non-change addresses (it's not the most useful thing to do, but you can do it).



Armory implements a very minimal part of the networking protocol.  As long as the Bitcoin-Qt client version has the Feb15 protocol upgrade, it will work (which I believe was added in version 0.3.XX.

1. What source of entropy Armory uses for initial wallet seeding? - I can answer myself looking at code but for someone who knows answering this will take only seconds.

2. Does keys generated by deterministic wallet that Armory can be linked to each other using known or potential crypto?

3. Original Satoshi client generated new address when receiving new transaction before QT fucked it all up. In paper it is stated that it is recommended that each address is used only once to prevent person linking and use of statistical analysis. Can Armory generate new receiving address when new transaction is received with current address selected?

4. Is there any minimum requirements for underlying Bitcoin client? Can current version run with Bitcoin 0.3.xx version?

Hello etotheipi

I'm one of the developers of Open Transactions;  I am primarily an C++ Windows developer.

I have been looking at your siwg interface and native code, and I think that I will try and clean it up a bit for windows at-least.

You may want to see how we have managed our Open Transactions swig interface:

https://github.com/da2ce7/Open-Transactions/tree/master/swig

I'm thinking about doing something similar for Armory... hmm.

I think I installed it using sudo apt-get -f install for the dependencies.

Download from the 64-bit version from the downloads page:  https://github.com/downloads/etotheipi/BitcoinArmory/armory_0.82.4-1_amd64.deb
 
The package should replace itself correctly, but let's assume it didn't.  Go to the command-line and type the following.  First line removes any existing Armory installation, second one tries to reinstall it:


If that gives errors about unmet dependencies, then you need to install them.  Luckily, Ubuntu remembers what you were missing when you last tried to install such a package, so I believe you only need to type the following:



Finally, if that still doesn't work, then explicitly install all the packages you need and try again (found on the Building Armory from Source page):


If that still doesn't work... well I'll reset my Ubuntu 12.04 VM and see if can walk through it from fresh install and try to replicate any issues.  Until then, I think this should work.

Yes, 64bit.

64 bit?