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

Foxpup,

(1) I can see why that line should trigger an error, but I can't seem to trigger it myself.  Bizarre.  Either way I committed and pushed a fix.  Let me know if there's still a problem.
(2) I just added (and tested) a new command-line argument:  "--nettimeout=X" where X is the number of seconds.  I pushed that with the above fix.  Yes, that's one's for you, Foxpup
(3) I already mentioned the package: it's pyqt4-dev-tools.  More-specifically (for other distros) you need to have pyrcc4 in your path.  The "directions" I was referring to in my previous post were for installing pyqt4-dev-tools on an offline computer... i.e. your offline computer doesn't have internet, how do you install it?  (it's pretty easy in Ubuntu, actually, if you know what buttons to press).

A little more elaboration on why #3 was necessary: I previously used pyrcc4 to create a Qt resource file, but that file was 10 MB and ended up in the git repo.  But every time I add a new icon or image, that file is going to change and add 10 MB more to the repo (kind of like the blockchain... it's never going to get smaller).   So instead, I have committed all the individual images, and execute the pyrcc4 call in the Makefile.  Otherwise, the repo might start looking like the blockchain...

It seems to work fine except for crashing in flames if it can't detect my crappy Internet connection:


So, uh, what's the package I need for it to work offline?

Initial Testing Release of Armory (0.72-beta)-alpha  (Linux/OSX only)

Bulk Importing, Address Books, and ton of bug fixes!  Checkout the "bulkimport" branch to try it out.  "git checkout bulkimport".
Both these new features are a very rough around the edges.  As far as I've tested, they work.  But they need improvement, both in explanation and layout/interface.  I'll get there.  But there's a lot of use cases and corner cases to catch, and I want people to start vetting them immediately.


NOTE: In order to use qrc-resource files responsibly with git, I had to add a step to the Makefile which requires an extra package.  It requires installing the pyqt4-dev-tools package, which is available natively in the Ubuntu repos.  I have updated the webpage with the updated install list (so if you start over from scratch from here, it should work).

This also requires installing a new package if you want it to work on the offline computers, too.  I'll post directions for that on the official release.  I fixed a bunch of offline-tx bugs, but I would wait until this version becomes stable before going through the trouble.

Armory wallets should always be thought of a "deterministic wallets", and imported keys basically being a bonus feature.  If you spend money from any one of your keys (imported or not), its change gets sent to the next unused address of your deterministic wallet. 

I don't know what you mean by "run out" and "generate more".  The wallet is deterministic meaning that your paper backup provides the seed that allows you to generate an infinite number of keys, and that whole process is transparent to you (and repeatable).  You never "run out", and "generating keys" simply means retrieving the next key in the sequence based on the information on your paper backup. 

i have a question for you.

if i import one private key with 100 BTC into a fresh, new Armory wallet that has no deterministic addresses/keys generated yet and then immediately spend 1 BTC to a vendor, where do the remaining 99 BTC go?  i think you said there were some keys pre-generated?  if so how many and when would they run out before i have to generate more?

i actually think i remember you discussing this a way back.

No offense taken.  I would like others to look at it and sanity check things.  I've done quite a bit of it during unit testing, but I wouldn't mind having some others vouch for it, too.

I have documented my wallet files which should make it easy to spawn a watching-only copy of one of your wallets and examine the binary of the *.wallet file.  The 32 bytes where each private key is stored should be all zeros. 

In a PyBtcAddress serialization, the private key starts 108 bytes into the 237-byte field.  In your wallet file, the root key starts 846 bytes from the beginning of the file, meaning bytes 954 to 954+32 should be zeros in your watching-only wallet. 

i just have to ask this even tho i trust Alan implicitly otherwise i wouldn't have given him so much money.

has any other coder looked to verify that private keys are in fact not being transferred to the online watching wallet by mistake or something?

i only bring this up b/c i did my first offline tx last nite and it worked perfectly but then realized i really am trusting that the watching wallet is in fact just that; a watching wallet.

don't take offense Alan.  this is just part of my paranoia and due diligence since i can't do it myself.

Developer mode only maybe?

Or maybe a third wallet type.  Something that lets you just watch any number of arbitrary bitcoin addresses.  These funds would not show in your spendable balance, but would make it easy to track funds and label transactions for your own bookkeeping.

I want an easy way to watch my blockchain.info address and an old paper wallet from one place.  Right now I just lookup my addresses on blockchain.info and then keep the totals in a spreadsheet. 

This is definitely low priority.

Red Emerald,

I had some reservations about enabling this.  While it's possible under the hood, there's risk of users adding watching-only addresses to the wallet, in a variety of ways.  The most important is that someone sneaks their own address into your wallet then sends you money to it making you believe that it's yours.  This is normally prevented due to requiring an encryption password to inject keys into your regular full wallets.

Also, mixing regular wallets with foreign keys can create lots of confusion the same way:  users add addresses on their own for a variety of reason, and then forget or don't realize what they're doing, and trick themselves into believing they have more money than they do.  it can be a mess, later, to figure out what keys are "legit" and which aren't (without comparing the WO wallet with the full wallet addr list).

This way, the only way to add an address to a wallet is by the person that has the private key for that address.  It's quite inconvenient (as you determined), but adds a certain robustness for users that are less knowledgeable.

I'll spend some time thinking about how to enable this responsibly.  Perhaps only in Dev mode...?   (though it doesn't solve the problem of someone sneaking a key into your wallet)

My web wallet is blockchain.info. They allow you to send change back to any address so this is not a problem.

That only works if change gets sent back to your original address instead of a new address, otherwise the public key will show less money than is actually in the wallet. And there's no surer way of scaring people than telling them they have less money than they thought they did:
"Okay, so I'll send 0.5BTC and... wait, why'd my balance just go down by 20BTC? I only sent 0.5BTC!! Didn't I? FFFFUUUUUU!!!"

Is there any way to add public keys to a watching-only wallet?

I want to monitor some addresses on a web wallet from inside Armory.  For now, I imported the private key, turned the wallet into a watching-only wallet, and then flagged it as owned by someone else.  This works fine for now, but is a bit too many steps and a pain to do again if I add more keys.

Thanks, that fixes it. I am curious why you thought a timeout of only 1 second would work in all cases; not everyone has cable or even DSL for that matter (at least not everyone in Australia ) This really needs to made configurable. And I take it that you'll be testing Internet connectivity by connecting to the actual Bitcoin network, rather than Google, once you've got the actual networking side done?

Foxpup, thanks for the feedback.

Certain things like color schemes and layouts, and certain robustness features, were overlooked in the first [major] release of Armory, I didn't even know if I'd ever finish the damned thing -- so I didn't spend much time polishing things.  This is definitely something that will be addressed after beta...

Not to mention that the color scheme stuff is not actually that hard.  I don't think I have a need to deviate much from the user's palette, which is available pretty easily within PyQt.  I just have to study up on what all the palette colors are and try to match (and probably slightly modify per your suggestion) to my application design. 

Similarly, the two-Armories-open-at-once thing can be fixed, but it's something I didn't even think about until now.  It is definitely high priority... it's actually already done in my dev code, and it will make it into the next minor release.

I'll see what I can do about changing the behavior for offline mode:  for now you can test it yourself:  https://github.com/etotheipi/BitcoinArmory/blob/master/ArmoryQt.py#L535 .  Look for "timeout" and change it to 5 or 10, or whatever seems appropriate. 

I've built Armory (0.70-beta)-alpha on MEPIS 11 (a distro based on Debian 6) and I'm having a major problem and few minor problems.

The major problem is that most of the time it'll flat-out refuse to start in online mode complaining that it doesn't have an Internet connection. My Internet connection has a highly variable latency (sometimes it's around 50ms, sometimes it's 5 seconds or even more) due to wireless reception issues, could that be the problem? If so, a higher (preferably configurable) timeout and/or a "Retry" button on the message box would be in order.

The minor problems are that the windows are just not wide enough to see everything without scrolling, and I have to make them a few pixels wider (or else maximise the window). But the program doesn't remember its window sizes when I quit (nor does it remember if it was maximised), so I have to do this every single time, which is most annoying.

Also, the advanced encryption options only appear when creating a new wallet. When encrypting a wallet after it's been created, the advanced encryption options don't appear. Is there no way to change the advanced encryption options for an existing wallet?

One more thing which isn't really a problem as such, but may be a possible source of confusion for new users, is that the "Receive Bitcoins" button creates a new address (without even asking for confirmation), while the same button on the Satoshi client displays a list of existing addresses, with an option to create new ones. I think it would be better to have a dialog asking the user whether they want to select an existing address (assuming the wallet has at least one address already), or create a new one (yes, you can put a "Don't ask me again" checkbox to avoid annoying those who actually like the present behaviour).

Also, I have a dark colour scheme too, and I have the same problem that dooglus has. Half the text is either light grey on white or dark red/green on dark grey. Argh, my eyes! One option (which shouldn't be too difficult) is to algorithmically generate colours based on the system colours, eg (pseudocode): GreenText = (SystemText * RGB(0.0, 1.0, 0.0)) + RGB(0.0, 0.25, 0.0); to get a dark green on systems with black text and a bright green on systems with white text, etc.

Oh, and the issue with running multiple instances of Armory should definitely be a high priority. Merely telling people not to do that is not a satisfactory solution, given the consequences.

If you just don't set the background colour, it defaults to something quite readable.  I set WltMine and WltOther to be None in and it made things look a lot better.  I got a couple of error messages though.

Yes.  Maybe just "select wallet" if you want it to be the same in both cases.  But showing "send from wallet" when I'm picking a wallet to receive the funds is just misleading.

I knew this was going to bite me some day.  My PyQt book spends a lot of time setting colors based on the user's palette, but it's a lot of extra work!  

Once I get Beta out, I'll switch to development on a 1280x768 screen with a dark user-theme.  That will force me to fix colors and layout.


Per cypherdoc's suggestion (via PM) I will merge these both into a single backup interface and have a single print option, so that you can print both root/chain data, and imported keys.  It definitely makes sense to put it in one place, and reduce user confusion about what they are actually accomplishing.

Ugh, so much to do!


P.S. -   amincd:  I don't even have a twitter account!  I like the btctip idea, but I'm just not one of those people.  Please use the donation address in my sig.  Thanks!

You have to tell it what wallet you want to receive the funds into.

EDIT: Oh. I misread that the first time.  Are you trying to say that the dialog should read "receive to wallet..." or something like that?

When I click "receive bitcoins" a dialog pops up asking "send from wallet...".

I'm trying to receive, not send.