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

I'm using the standard 0.6 Shatoshi client. I'm not sure if Shatoshi client has broadcast my sub-standard fee tx (I didn't get any error message). How could I know if it has broadcast or not?

Please help test the new version:  Armory 0.76-alpha-RC1:  Layout Fixes&Memory, Table sorting, Fedora Compiling, --datadir


Armory now looks remarkably different yet actually the same, all at once!  In addition to some slight layout improvements, I've added memory to the major windows and tables so that windows open to the last position&size, and table columns will remember the widths manually set by the user.

• Dialog and Table Geometry Memory --  Dialog sizes and column widths are saved between loads.
• Smart Stretch factors -- Major layouts are more efficient and stretch more intelligently.
• Table sorting now works! --  You can now sort ledgers and address lists by any column. (not all tables have been upgraded)
• Added "--datadir" option -- Use "--datadir" to choose a different home-directory for Armory (i.e. keep wallets on a USB key).
• Fixed wallet corruption bug! -- A "wallet description" of more than 256 chars could overflow into and overwrite the encryption settings.  Fixed now.
• Fixed Fedora compiling -- I became aware that the latest version of crypto++ was [accidentally] dependent on a bug in gcc that was fixed in gcc version 4.7.  The latest version of Fedora uses gcc 4.7 and thus compiling fails.  I upgraded the included Crypto++ code with the official fix, so it should work, now.

I've provided the most popular downloads below.

Windows 64-bit
Ubuntu/Debian 64-bit, 9.04-10.10
Ubuntu/Debian 64-bit, 11.04+
Ubuntu/Debian 32-bit, 9.04-10.10


Layouts are more efficient and table sorting lets you find stuff easier!

New wallet format is on hold:  I started a complete overhaul of Armory wallets and probably spent a week getting about 30% done.  Not only is it hugely complicated (but worth it!), the new determinism algorithm has not been finalized by the Satoshi developers yet (it's not even an official BIP yet, and I don't want to release it until I know that they're supporting it).  Given that the 0.7X code is pretty darned stable, anyway, I think this will be the basis for Armory Beta!


So instead of a new wallet format, my final hurdle to beta will be completely eliminating all system requirements.  Mmap did not succeed on Windows 32-bit at all, and is still pretty heavy on Windows 64-bit.  I think it will be better to get Armory working on any hardware, and will give me a headstart on some networking stuff.


P.S. -- For anyone interested, Sipa has really locked down a great algorithm for the new wallets.  It allows you to deterministically generate new addresses and new wallets.  In fact, you can very quickly compute addresses of arbitrary dimension and index:  i.e.  you can get Address(12),  or Address(3)(9), or Address(98)(4)(182)(5)(48372221).  Of course, this can get wildly out of hand, which is why the new wallets will have a "convention" for what addresses are used and associated with each other.   Here's a diagram I made of how it will work (assuming it survives the BIP process).

This means that you can create a single wallet seed when you install Armory, and all future wallets you create can be regenerated from that seed.  Of course, you can choose to create new seeds to keep wallets truly separate.  But at least you have the option! 

Oh.  I didn't think that option actually worked!  Very interesting that it does! 

I would think any sub-standard fee broadcast by Armory would be DOA at the Satoshi node and never make it to the rest of the network.  Unless your Satoshi node is a special version designed to allow low-fee tx through...

It is fixed, thanks!

I override the mandatory tx fee function in the armory conf file. So this is my problem, not a bug.

Ahh, this is very annoying!  The best thing to do is to delete the memory pool file:


I know it's super-annoying, but luckily this should happen only very rarely (after all, this is the first report of this happening...).  I will add an option to let the user clear the memory pool, but I don't know yet where to put that option and how to explain it.  Perhaps under "Advanced" options.  Though, I would need an options menu, first...

Question:  Was the transaction stuck due to Armory sending the transaction with a low fee?  I ask because I tried to force transaction fees on the user that would guarantee this exact thing doesn't happen.  If it failed (i.e. Armory allowed you to send a tx with a fee too small), I'd really like to see that transaction to figure out why.  If it was Armory's fault, can you give me the Tx ID?  PM is fine if you don't want to put it up publicly. 

I tried to send a big-size transaction with very low transaction fee, and it kept as 0 confirmation after 24 hours. Since I'm unable to spend the coins again with Armory, I imported the account private key to Satoshi client and send the stuck coins to another account (with recommended tx fee). Eventually, the tx sent by Satoshi client was confirmed. In Armory, however, the 0-confirmation tx is still there, with the related "change" record (also 0 confirmation). I tried to delete the wallet and recovered it with paper backup and these records are still there. What can I do? Thanks!

There's no crash.  But one of the things that gives Armory its robustness (in some aspects) is that Armory is so fast at scanning the blockchain, that I can keep track of all transactions and addresses simply by rescanning and recollecting the data on every load.  This removes the necessity to create special files for storing the data which could become corrupted, or somehow become un-sync'd, etc.  But that means that I can't add arbitrary data to it, either.  At the moment, you have to get your address linked to the other address by sending it some money...

However, it will be fairly easy to just add address data to the wallet format.  I'll be sure to make it part of the upcoming wallet updates...

If you suspect something is crashing, you can run Armory from the CLI:  "python /usr/share/armory/ArmoryQt.py".  This will show you all the command-line output and any errors.  It almost always has an error and useful information if you click a button and it doesn't do anything. 

I wish I had started Armory with a proper logging system in place.  It's on my to-do list to go through and implement it, but so far there have been a very few bug-reports, so it hasn't been high priority  

You're welcome.

I'm on linux. Do you have an command-line option to debug armory? I think it could help you if there's a crash or something.

Ahh,  yes I misunderstood.   There is currently no way to do this,  but I hope to add it in the next major release.   At the moment, no address book is ever stored on your system directly.   It's all rederived from blockchain information every load.   It's slightly inconvenient,  but it's dramatically simpler in code.

I'll add it to my list for the next release (and it won't be too hard). Thanks for the feedback!

Sorry, I was talking about sending adresses (adresses of other wallets). So "create adresse" was not the right word, rather registering existing public adresses to send bitcoins to.

If I send btc to a new adress this new address will be kept in the adress book ?

Hi Raphy,

I'm not sure I completely understand.  When you press the "Receive Bitcoins" button, it should pop up a new address.  Technically, you don't have to use that address, and certainly not right away.  Even if you cancel out, you're going to get another new address when you hit the "Receive Bitcoins" button again.  Rinse and repeat.

Hello,

I'm currently testing your app. I have to say, I'm impressed. I love it already (and I'll love it more when it will be standalone ).

I have a question though: how do I create new adresses in the adress book without having to send funds?

Thanks
Raphy

Just found a bug that that makes clicking on URLs not work when you have only one wallet.  D'OH!  I have half a dozen wallets, so I never test Armory with only one wallet...

I will be fixing that soon.  But for now, if you want "bitcoin:" links to work and you have only one wallet, just create a second dummy wallet.   You can delete the second wallet once I have it fixed, but I suspect it may be a little bit before I get the time to recompile and re-release everything...

Armory Version 0.75-alpha on Windows!  (Testing Release)

I just posted a .msi file for installing Armory version 0.75.  This has a ton of new stuff in it, mostly stuff that makes it feel like a real program! 

Please try it, test it and give me feedback.

This has been stated before, but here's the official aggregation of features between 0.74 and 0.75:

• Full installers on both Windows (.msi) and Debian/Ubuntu (.deb).  Creates menu entries for Armory/Testnet/Offline
• System-tray icon and notifications.  Be notified immediately when coins are received.
• URI-handling!  In Windows and Ubuntu <11.04, it will automatically check on load whether Armory is registered for handling "bitcoin:" links and either register it if nothing is registered, or it will ask you to switch if something else is there.   On Ubuntu 11.04+, it will do it on installation only, due to a bug in the Unity desktop.  (P.S. - this was a lot of work!  Geezuz)

As usual, I've done what feels like a lot of testing, but users inevitably find all sorts of stupid issues I didn't.  Please help test and I can make 0.75 final.

Just be aware the blockchain is getting bigger, and the loading time is getting longer on Windows.  I hope kr105 comes through, claiming he knows how to fix the windows MMAP code, but I'll be doing some fixes on it, too...eventually.

Sorry BitAvenue.  Unfortunately, my efforts have failed at getting Armory to work on Windows 32-bit.  It does work in Linux 32-bit, though.

It might be another month before I can even start thinking about fixing this.  It will be fixed, but it might not be until I get native networking (and thus have to rework my blockchain code, anyway).

P.S. -- my screenname is "Eto"... it's actually:  e-to-the-i-pi



I was just discussing this with someone else.  I usually recommend using Linux, setting up the system online and disconnect before you create your first wallet.  But, with my recent release of .deb files, I found it's a lot easier now to setup everything from entirely offline... it's only 30 MB of downloads!

I'm waiting for some more testing/feedback before I completely release it.  But if you are experienced with Linux and have a spare online linux system, this can be super easy:

(1) Load the offline OS (preferably Ubuntu 10.04 / 32-bit, since I'll eventually be distributing offline packages for that).
(2) Go to Synaptic package manager and search-for-and-mark-for-installation:  "python-qt4" and "python-twisted"
(3) File-->Generate Download Script
(4) It will create a bash script of wget commands for all dependencies:  about 30 of them.
(5) Take to online linux system, double-click, Run In Terminal.
(6) Take back to offline system and "Add Downloaded Packages" from Synaptic (below the "Generate Download Script")

That will install all the dependencies, and then you only have to run the .deb file I posted.  I will eventually be releasing a single .tar.gz that includes all these debs, along with Armory itself, so you only need to move one file and everything will work!

Ok, thanks for your replies, for me it was important to get to the bottom of the physical handling of the keys.

One final line of questions, your tutorial recommends  "Load Armory on the offline computer"
http://bitcoinarmory.com/index.php/using-offline-wallets-in-armory

Do you have a recommended method for this? Is it the same method for Armory s/ware updates and dependency updates, etc? Should the offline computer have OS installed from a DVD/CD and OS s/ware updates done via USB? I mean how rigorous is the "offline" status of this machine? Like "absolutely never been connected" ... or something less so maybe?

Question for Etho, will the full version of Armory be coming out on 32 bit soon?

Thanks!

Well, of course!  But that's two orders of magnitude less likely than virtual threats, which can sweep across thousands of computers from the safety of Tor and grab all the low-hanging fruit (users with shitty security).  I believe that 99.9%+ percent of Bitcoin thefts will be due to virtual security, not physical security.  For someone to physically steal your offline system from your house they have to:

(1) Be targeting you because they know you have money, or
(2) Be a low-life burglar that wouldn't have a clue how to do a low-level scan for residue private keys from your hard-drive (if they even know what Bitcoin is).

And I believe that if someone is targeting you and gets physical access to the system, it's because you have lots of money and would've been using encryption from the start.  There's just not many situations I can think of where it would make a tremendous difference whether the secure-delete option was implemented (if it were possible).  On top of that, no matter what security procedures I implement, you'll almost always be compromised if the attacker is targeting you and has physical access.  There's too many things they can do between planting keyloggers, viruses, trojans, etc.

The more-important part is the GPU-resistent key-stretching used for Armory wallets.  That's gives you the best chance of protection from virtual threats and physical threats (mainly physical, though).  As I conceded, it doesn't hurt for me try to overwrite the wallets in-place when deleting.  It may provide no benefit whatsoever, but it's the best I can do.

Not true, I was considering every possibility. One particular offline example, thief comes in and physically takes your "offline" drive (and contents of house safe). If people are going to feel comfortable about storing life-savings on offline (or online) drives at home the stakes go up. You must have considered physical loss surely?

Whoops!   Just replaced the download with the correct one.