Topic: Armory - Discussion Thread - page 184. (Read 521749 times)

I hadn't looked at the URI produced.  I just noticed the "forward compatability" section:
 - http://en.bitcoin.it/wiki/BIP_0021#Forward_compatibility

Specifically:
 "Variables which are prefixed with a req- are considered required.". 

So I suppose the URI could be fully compliant without doing anything special.
  "Some future version that has variables which are (currently) not understood but not required and thus valid:"

@Stephen

I think it is already covered in the BIP 21 paragraph starting:
"General rules for handling (Important!)"

Reading that suggests that when a payment request occurs that there is a confirmation dialog asking the user if they want to accept it.

Would this be something to post as a BIP/?
A successor to BIP 0021
 - https://en.bitcoin.it/wiki/BIP_0021

Armory 0.82-alpha Testing Release!

No joke: Tons of new features and polishing!  After having spent so much time on the new blockchain engine, it was time to do some serious feel-good upgrades.

• URI Creator:  Screenshot in the previous post -- right click on an address in your address book, or press "Create Clickable Link" when you get a new address (in the "Receive Coins" window).  This should give you everything you need to email payment requests to others, or post payment information on webpages.
• Minimize-to-system-tray:  The file menu now has a "Minimize" option, and you can now set it to minimize-by-default when you click the "x" on the top window bar.
• New "MAX" button:  One button for each recipient in the send-bitcoins dialog.  It takes your spendable balance, subtracts the amount filled out for other recipients and subtracts the specified tx fee, then puts that value in for the current recipient.  Useful for sweeping a wallet without typing in 8 decimal places, or a variety of other uses...  
• Specify change address:  (Expert Mode Only!)  This legitimately deserves to be in Expert mode and not Adv mode.  I have spent a ton of time polishing the interaction of these options and making sure that it has memory between tx and between loads.  I think it's pretty solid!
• Lots of polishing:  Nothing in particular, but I was testing lots of features, and spent some time figuring out better ways for some dialogs to interact with the user.  Hopefully it just feels better

Please help test!  Please PM or email your email address if you want to help test and haven't already (you can still test based on these posts, I just want to know who/how many people are actively helping)

Download:  (remember, these are just testing releases)

• v0.82 for Win64
• v0.82 for Win32
• v0.82 for Linux64
• v0.82 for Linux32

For those that are compiling from source, the testing version is on the "dev" branch.

It's not supposed to look "right", it's supposd to look usable. Having the check boxes on the right puts way too much space between the label and the check box itself, and since all check boxes look the same, the distance from the labels makes it harder to tell which check box is which. Look at how the Firefox preferences dialog does it: the buttons are on the right, the check boxes are on the left, and yet it still manages to look "right".

Yeah, I think all the other check boxes are correct.

I did it that way just because of the layout of the rest of the dialog which has descriptions on the left, interactive widgets on the right.  I could switch it, but I feel it wouldn't look right...

I think I generally used default layout for checkboxes elsewhere in the app (I let QCheckbox decide for me, probably based on locale).  If I didn't, please point it out to me.


Ack!  I forgot that the date displays differently depending on your time-zone.  On my system the datetime is 10:32pm so that when the user switches to 24hr clock it is apparent.  I selected the unixtime to use based on my clock, forgetting others would see a different time.  I guess I can manually set the datetime object, to guarantee that the example time shown is 10:32pm on the user's system.

As for default format, you're right.  I picked a default I like.  And that's why I made it an option.  I kind of wanted to use %c for the reason you mentioned, but then it would not be obvious to the user how to modify that field. 



I'll see if I can improve that.  I set my offline system to a dark theme so that I have a place to test those colors, but obviously it won't be displaying zero-conf tx...

Now you just need to make the cration of links to be possible with a little json-RPC magic and you have a winner lol

A watch only wallet, with armory running as a daemon on a server would solve a lot of the security problems webservices face with bitcoin

Some random feedback on 0.81-beta:

* In left-to-right languages such as English, check boxes (such as those in the Preference dialog) are supposed to be to the left of the label, not the right, and vice-versa for right-to-left languages.
* The default date format (%Y-%b-%d %I:%M%p) isn't my system default date format (ISO 8601), and isn't even a standard date format used anywhere in the world. Where'd this weird date format come from? Also, for the example date, it's generally recommended for the time to be after 12:59 PM, to make it easier to differentiate between 12- and 24-hour time.
* It looks like I didn't fully test the light-on-dark colour scheme handling earlier: unconfirmed transactions in the ledger are displayed in black on a dark background. I understand reducing the contrast for unconfirmed transactions, but I think you overdid it slightly.

BTW, I can do Russian as well.

I'm glad to see active development in this project. Congrats etotheipi! I use Armory for almost a month and I find it very well suited for the job. I wish I could do more than just a feedback... If you ever need a Greek translation of Armory, I would do it happily

Now, about the feeback part I was talking about...
1) Looks good
2) + 3) It would be useful to have the option of copying raw HTML. If you think that might be confusing for some, you could show this to the advanced users only.
4) I was considering the use of "pay" instead of "send bitcoins", but maybe it's too soon for this yet.

If it's not too much trouble in coding, it would be nice to have an option to display the rough equivalent in $ or other currencies of a payment (when users click on payment links).

Awesome! This would make requesting payments a lot easier for people that don't have a smartphone. I wish the Satoshi client would add URI handlers though, so more people would use bitcoin: links.

New feature almost complete!   Need feedback!

I want to make it easy for users/merchants to request payments from other users.  Now that Armory supports clicking on URIs, I wanted users to be able to create them.  What comes to mind is the woman at statelesssweets.com with whom I had to iterate a couple times to make sure we were in agreement about BTC price and quantity (btw, I highly recommend her sweets, they are delicious!).

So I want merchants to easily be able to create blocks of text to copy into websites or emails like this:


I have put together the following interface, but I'm not completely satisfied with it.  I need some feedback.

(1) You can either right-click on an address in your address book and select "Request payment to this address", or when you create a new address, there's now a "Make clickable link" button:



(2) You then fill out the fields as you would like the recipient to see them.  This is the part that is mildly difficult to communicate.  I am hoping it comes across as self-explanatory.  Btw, everything shown here is the default (except for Amount which starts blank), because I want users to see what kind of information they could be entering into the fields.  But it might be too over-the-top...


(3) I wanted to allow the user to copy raw HTML or URI (forum users will need to copy the raw URI for forum posts), but I also didn't want to confuse the majority of users who will just copy the block of text and might be confused by the extra buttons.  However, I haven't yet figured out how to programmatically copy HTML into the clipboard the same as selecting it and -c.  So I couldn't create a "Copy All Text" button.  But I wonder if that's really an issue.


(4) The recipient sees the block of text, and if they're using Armory, Multibit or Electrum, then they will see a popup like this after they click on it (I need to polish this dialog a bit):


(5) After selecting a wallet, they are 1 click away from sending (plus typing in passphrase...)


So far, I've already been using it for myself.  Mainly to setup donation links on my webpage.  I know that most users are still using Bitcoin-Qt which does not support URI-handlers, but I hope they will eventually.  Because this functionality (both creating and clicking links) is such a dramatic improvement for the community, and much of the community is not yet using alt clients...

Questions, comments, recommendations and donations welcome!

That's super interesting!  I just stumbled across that error message in the code the other day and was amused that it was still there.  And, until now, I've never seen or heard that error triggered.  Though, I also haven't tested sending transactions with hundreds of inputs...

One thing to try would be sending (FullBalance - 0.0195) and then set the fee to 0.0195.  I would guess there's an issue with the iterative process of trying  to find the right fee for such a large transaction.  If you tell it the correct fee to start, it might work better...

Can I purchase a watching-only version of that wallet for 0.20 BTC?  I would really like to step through Select coins in a debugger with that wallet, to figure out what's happening.  Even if you succeed in getting the coins spent, I can just stop the blockchain reading before they are spent so that Armory will try spending them, and then I can track it down...

Unfortunately, I live on the east coast (US) and my power has been out for 2 days, so I don't have access to my development machine(s).   I hope my power comes back soon, and then I'll dig into it...

I have more than a hundred of mBTC size inputs in an offline wallet and want to send to a single address. The total balance is about 0.16BTC and Armory requires me to pay 0.0195BTC as fee. However, it always returns "SelectCoins returned a list of size zero.  This is problematic and probably not your fault." What should I do?

So I just got a question about checking .deb signatures.  I spent an hour waiting for my crappy offline system to generate a 4096-bit GPG key, so that I could start signing packages manually.  And then I manually took the packages to that machine, and used a debsig package to apply my signature using the "builder" signer-type.   I got the message stating that it was signed, and then I moved that back to my online computer and posted.

However (this was stupid), I never actually checked the signatures were valid before uploading them to github.  However, now that I try to do it with the debsig-verify package, it tells me there's no signature!?  Maybe I uploaded the pre-signed packages...

Here's what I did to check the signature, which I believe is correct.  Once I get this process ironed out, will start including all of this with the offline-all-in-one package so that there will be considerably fewer steps.  Maybe I missed something.

For checking using an online computer (the key id is 98832223):

• 1. sudo apt-get install seahorse debsig-verify
• 2. gpg --keyserver pgp.mit.edu --recv-keys 98832223
• 3. debsig-verify armory_0.81-1_i386.deb

For offline computer, you need to download some stuff from online first, then take it to the offline computer:

• 1. (Online) gpg --keyserver pgp.mit.edu --recv-keys 98832223
• 2. (Online) cd /media/  (replace the path the one to your USB key)
• 3. (Online) gpg -a --export 98832223 > armory_sign_pub.asc
• 4. (Online) wget http://launchpadlibrarian.net/1235476/debsig-verify_0.7_i386.deb
• 5. (Online) wget http://launchpadlibrarian.net/11723161/libxmltok1_1.2-3_i386.deb
• 6. (OFFLINE) Insert USB key
• 7. (OFFLINE) cd /media/
• 8. (OFFLINE) gpg --import armory_sign_pub.asc
• 9. (OFFLINE) sudo dpkg -i *.deb
• 10. (OFFLINE) debsig-verify armory_0.81-1_i386.deb

There was a crazy storm last night that took out power to huge areas of my county.  So I'm at a coffee shop right now and don't have access to any of my development systems.  I'll check the signatures when the power comes back on.

You are absolutely right.  I am terrible with Makefiles.  I had modified the Makefile, at least temporarily, to statically link python so that there would no longer be python issues for users who use the *.deb packages, but I did so [apparently] at the expense of those compiling from source.  Your recommendation is very helpful, and I will adopt that or something similar.  I knew there was a better way to do it, but you are the first person that has mentioned it!

Thanks!

I've been following the master branch and Armory no longer runs out of the box for me:

The makefile now checks for the existence of the path for the highest available Python version from 2.7, 2.6 and 2.5. On Gentoo it's not uncommon to have multiple Python versions installed simultaneously, so this check fails on my system because I have 2.7 installed, but my default version is 2.6. I have very little knowledge of pythonisms, but I'd guess that asking the python executable itself would be a more robust way to determine the version number. This solved the issue for me:

For those that are compiling from source, version 0.81 is on the "dev" branch.

EDIT:  Disregard that.  I already merged into master a few hours ago and completely forgot!  Whoops!

You can subscribe to the announcement thread to receive updates when I make official releases:  https://bitcointalksearch.org/topic/ann-armory-0822-url-creator-minimize-to-tray-logging-75647

The main page still says 0.80 because I just discovered this problem yesterday and haven't had time to test 0.81 much yet.  However, I wanted to make it available for folks like you who are inconvienced by the broken feature -- hence why I post it here, and hope some people will use it and report bugs.

It was tough to tell after 4 sentences of hard criticisms whether your last line about a great client was sarcasm.  I understand that your first impression was hardly something to brag about, but that's why it's still alpha.  I also just completely revamped the blockchain utilities under-the-hood.  I expected there to be some issues, but nothing as silly as botched importing.  I guess this version isn't quite stable, yet.

Hopefully 0.81 has fixed it (and it has some extra features), perhaps you'll try it out and tell me if it meets your expectations. 

P.S. -- The 0.6.X wallet import is going to be a while.  I need a whole new wallet format in order to support compressed public keys, which is what's used by the Satoshi client.  And changing the wallet is no small deal...  I've already started a branch for it, but it's a huge change and going to require tons of testing since that is the most sensitive part of the application...

I had high hope for this client and apart from that I'm not disappointed.

I've been watching a while for 6.00 import,  What is the best place to watch for update ? I see that the download page still show 0.80