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!
Ahh, this is very annoying! The best thing to do is to delete the memory pool file: Linux: /home/username/.armory/mempool.bin
Windows: C:\Users\username\AppData\Roaming\Armory\mempool.bin 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. |
|
|
|
It's because the wallet is sensitive stuff, and one of the benefits of a database engine is the ACID/atomic operations: it guarantees that data is written as intended or not written at all to the database. No matter what nanosecond the power goes out, it's supposed to be impervious to corruption. When you're talking about private keys protecting millions of dollars, it's a very good idea to have atomic operations... but it comes with the downside that the database is a kind of blackbox and you don't always know what it's doing (hence the 0.4.0 wallet-not-actually-encrypted bug).
The ability of a database engine to provide atomic operations is no stronger than the underlying OS's ability to reliably report that all writes to a certain point have been flushed to disk when asked - using operations that anybody can call from any application, not just a database engine. The magic that brings an atomic operation to a database is nothing more complicated than replacing "write a record" with the following flowchart: 1. Write a record somewhere that says you intend to make a particular write, including details of the substance of the write, so the write can be repeated if this is the only record of it. 2. Ensure that that record is committed to disk before continuing. 3. Make the write as intended. 4. Make sure the write done in step 3 is committed to disk before continuing. 5. Eliminate the record you created in step 1. 6. Ensure that the elimination done in step 5 has completed before allowing step 1 to occur on a future write. 7. When your program starts up, have it so that it looks for any unremoved records similar to the one created in step 1. Confirm that they were written completely. If so, simply perform the write operation that the record says you planned to make (which will have no effect if the prior write was successful). If such records were not written completely, discard them. This is simple enough for computer science students to implement in their homework. The only magic that a database engine brings to the table is the ability for these seven steps to run at a high level of performance with lots of concurrent operations, in an effort to mitigate the performance penalty of tripling the burden of doing writes. Since a Bitcoin wallet is only updated eternities apart (in terms of compute time, especially when it is limited only to data created or changed by the user), the perceived performance penalty of doing 3 writes instead of 1 ought to be so negligible as to make a full blown database engine completely unnecessary even when ACID properties are desirable. Well this is exactly what I do in my wallet, except with an extra step of repeating 1-5 on a backup immediately after the main file is updated. I do this so that if the file gets corrupted I have a guaranteed working backup, and the flag files tell me which one is the corrupted one... HOWEVER: one of the criticisms of this technique (which I would think equally applies to any app trying to do atomic operations) is that you don't have control over when data actually gets written to disk. And there's no guarantee that the writes happen in the same order that you issued them. |
|
|
|
So you have a solution which combines the safety and the simplicity of each option, yet it hasn't been implemented into the mainstream client? I might have to make armory my main wallet if something similar never hits the main client.
Bear in mind that my solution is not a perfect replacement for ACID operations. It's only a "good" solution (as far as I can tell). However, I think it's a lot less important with deterministic wallets. Would-be wallet corruption is so rare to begin with. Now take into account that 90% of that will be recoverable. Now take into account that your wallet is completely recoverable from your very first paper or digital backup*. And most users will make a first backup. The issue with the Satoshi client is that it requires a persistent backup solution, and end-users are very bad at that. There's some semi-frequent discussion on IRC about what the devs would like to do with the wallet, but I haven't heard any consensus. However, I do know that they will be implementing deterministic wallets soon, too. So regardless of disk corruption/failure protections, the Satoshi wallets may have the same only-one-time-backup-needed property. But of course, it will probably be a while before they get around to it... *Exception: this isn't true if you imported keys after making the first backup. |
|
|
|
I think the fact that it is a database in the first place is a silly design decision.
I couldn't agree more. Why can't we use a simple format? It's because the wallet is sensitive stuff, and one of the benefits of a database engine is the ACID/atomic operations: it guarantees that data is written as intended or not written at all to the database. No matter what nanosecond the power goes out, it's supposed to be impervious to corruption. When you're talking about private keys protecting millions of dollars, it's a very good idea to have atomic operations... but it comes with the downside that the database is a kind of blackbox and you don't always know what it's doing (hence the 0.4.0 wallet-not-actually-encrypted bug). In my wallet format, I created atomic operations using a backup file and some flag files that detect when corruption has happened and to be able to detect and restore an uncorrupted version automatically. It's probably only 90-95% as effective as a real ACID/atomic database, but I've tested the heck out of it and it does work. In the end, it's pretty rare that this logic would even be triggered because Armory doesn't keep the wallet file open. It only does open-modify-close operations occasionally. I shared this experience with the devs, and while some of them thought it was interesting, their attitude was "let's not reinvent the wheel -- this is a solved problem, let's use an existing solution." I understand that attitude. But to me, the simplicity of the file format with 100% control over the data is worth every ounce of effort I put into it. |
|
|
|
Solutions to make it easier to use Bitcoins securely when donating.
When you click a URI the client opens and you will probably need to write in your password to confirm the donation.
If you have a secure 2 part verification password this becomes tiresome.
You might even avoid donating because you do not care to unlock the client.
What if you instead could save the donation and sign it and several other donations later when you really need to login.
As you click a URI to donate you are presented with the choice.
"Store transaction and verify it later or login and verify it now."
This will make it easier to keep using a secure 2 step passwords process.
This could also be useful for Armory with Bitcoins kept in cold storage.
I like the idea. Not only does it save you some time for transactions that don't need to be sent right away, it saves some bytes in the blockchain by allowing you to combine them into a mulit-output transaction (which can save kilobytes depending on the transactions sizes and the make up of your wallet). I've thought about doing something similar in Armory, but it's been such low priority that I never really fleshed out the idea fully. The only thing is that it adds a bit of complexity to the interface, so I have to make sure it adds more value than it adds user-confusion. Probably need to have a list/table somewhere of "Queued" transactions and a button that says "Do it!" Then there would be a "Add to queue" button next to the "Send" button on the send-bitcoins dialog. And an occasional reminder pop-up that you have tx waiting. Definitely an advanced feature, though... I'm going to add it to my list, though it will remain low priority for a while. However, desired this functionality myself, so I have some personal motivation to do it  |
|
|
|
What do people think about other wallet formats?
For reference, I went as far in the opposite direction as I could, when creating the Armory wallet format. I hate the Satoshi wallet format as much as kokjo. Armory uses a simple binary format, easy to read, and only two operations on it are ever used: append, or overwrite-in-place-with-same-data-size. I documented it here: http://bitcoinarmory.com/index.php/armory-wallet-filesI had two goals in mind when I made the wallet format: - I want 100% control of what happens in the wallet file. Inspired by the wallet-not-actually-encrypted bug in 0.4.0
- I want it to be dead simple for other developers to be able to read (and maybe modify) the wallet files
There's quite a bit of extra wallet-management code to protect against corruption & errors, and enforce atomic operations, but that's in code -- it doesn't affect the simplicity for other developers to read the files. The most important feature is that when I encrypt my wallet, the encrypted key is guaranteed to overwrite the original unencrypted key, which prevents any leaks happening when I back it up to Dropbox, etc. Same with deleting data: it's overwritten with zeros in-place. I know the overwrite may not happen in-place on-disk, but there's nothing I can do about that -- at least when someone copies the wallet file from my HDD, the binary file will not have any surprises in it. [/list] |
|
|
|
if someone could point me in the right direction to remove them from my client, I haven't tried a rescan because I don't think it would remove them.
Hacking manually in the wallet.dat is totally acceptable. (I assume I'd need some sort of BDB CLI client) I found it nearly impossible to get some invalid transactions out of my wallet. Though, I didn't try pywallet... If the wallet was created with a version of the client before 0.6.0, you can import the entire Satoshi wallet into Armory (Wallets->Migrate Bitcoin Wallet). From there, you can sweep the relevant addresses or move the coins out from under those invalid Tx. Once the tx hits the blockchain, go back to the original client which will see those tx as actually invalid and will complaining (well, it should) |
|
|
|
OMG then sorry, seems like I did not read your posting thourogh enough :-/!
Don't sweat it. It's a looooooooong post. Edit: Actually I didn't clarify that point in the post. I'll add some context to clear that up. |
|
|
|
On Windows it's a simple open the file to add entries to registry.
For Win >= Vista the UAC will prompt for an admin-token on WinXP you need have admin-rights, yes.
Of course this assumes you know what you are doing as it replaces / overwrites existing entries for "bitcoin:".
For Windows users it's more handy than what you've written I think (as a Windows user). But yes, perhaps it should be a user setting and don't require admin-rights to add this to the registry.
I guess I'm confused. What I've written is python code that checks the registry keys every time Armory is open, and either sets the local-user's-registry keys to default to Armory, or ask the user if they want to switch if it's already set to something else. I'm not sure what "handy" means here, since this is all under the hood -- it behaves exactly like Firefox/IE/Chrome -- "Armory is not currently set as your default Bitcoin application. Would you like to switch the default to Armory?" However, for those not using python, the .reg file approach seems reasonable as something to run during application installation, but not each time the app is opened. Mainly because it overwrites the keys blindly, and requires keeping a .reg file around to keep executing. And the admin thing, but that goes away if you just switch to the HKEY_CURRENT_USER\Software\Classes\bitcoin\* keys instead. |
|
|
|
For Windows you can use this and save it into a BC_handler.reg: Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\bitcoin]
@="URL:bitcoin Protocol"
"FriendlyTypeName"="Bitcoin URI"
"URL Protocol"=""
[HKEY_CLASSES_ROOT\bitcoin\DefaultIcon]
@="E:\\Bitcoin\\Client\\bitcoin-qt.exe,0"
[HKEY_CLASSES_ROOT\bitcoin\shell]
[HKEY_CLASSES_ROOT\bitcoin\shell\open]
[HKEY_CLASSES_ROOT\bitcoin\shell\open\command]
@="\"E:\\Bitcoin\\Client\\bitcoin-qt.exe\" \"%1\"" You have to edit the path ("E:\\Bitcoin\\Client\\bitcoin-qt.exe") to match up your local setup. Diapolo, (1) What am I supposed to do with that file? I saw examples like it everywhere, but nothing told how to ... use it. Do I open the registry and import it? Is there a command for executing that file? And how do I invoke it on installation or on-load of my program. Also what about checking for existing apps behind those keys before overwriting them? (2) That modifies the HKEY_CLASSES_ROOT, which requires admin/root and changes it for all users. I believe it makes more sense to use the HKEY_CURRENT_USER\Software\Classes\<same tree> to do it just for the current user and no admin required. |
|
|
|
@ Weex Armory is choking on the URLs on CoinDL, because of the colon in the the label field: bitcoin:16xPh78TNANC6YB1XZksWyCGqhcMFnDXZ9?amount=1.959&label=CoinDL:AlcoI don't know if Armory should be able to handle it, but ':' is on the "reserved characters" list, So you should replace it with %3A. The only important feature of the percent-encoding scheme is that the following characters are reserved "%!*'();:@&=+$,/?#[] ", and should simply be replaced with their ASCII code in hex. |
|
|
|
@etotheipi
Re: label v message
At the moment MultiBit parses both the label and message but only puts the label on the display and in the address book. I could not quite see the distinction between the two so did not want to put two fields in the Send/ Request forms one label and the other message as it would be confusing.
I have not seen the message field being used yet.
So I have been putting the "label" next to the address i.e. "1ArmoryXcfqj3f9dsjfkslWjZej ( Armory Donation Address)" and the message in the transaction comment field i.e. "Donation to receive Encryption Seminar". But it sounds like I'm going to have to forego that in Armory... instead put the label into the tx-comment field, and append the message to it if there is one. Gah. I don't like it. But life could be worse |
|
|
|
On the issue of label vs label+message I think I'll stick with the label for now. It's a pretty minor aspect as far as ux goes but adjustments can be made later if users can benefit from some additional messaging.
I'll pester the devs on the mailing list about it. I think it definitely makes sense to have both, but I'm guessing they didn't do it that way. The label-only thing sounds good -- I would prefix the labels with "CoinDL%3A%20" ("CoinDL: ") and then put the purchase after it. It'll show up fine in Armory like that, just a slightly sub-optimal I guess I should also pester them about URL-registration, in general. |
|
|
|
etotheipi, From https://en.bitcoin.it/wiki/URI_SchemeQuery Keys
label: Label for that address (e.g. name of receiver)
address: bitcoin address
message: message that shown to the user after scanning the QR code
size: amount of base bitcoin units (see below)
send: used to send bitcoin, rather than to request them
(others): optional, for future extensions
I take this to mean the label: should be "CoinDL" and the message: should be something like "Purchase of Alco ( https://www.coindl.com/page/item/127)". Does this interpretation seem correct? Is there another more definitive standard document on this? -weex That's actually the wrong document (that's BIP 20), which was ultimately replaced by BIP 21. But BIP 21 doesn't say much else beyond that. The issue is that Bitcoin-Qt only uses labels. The above suggests that "Message" is only for showing when the user clicks/reads the URL, but that Bitcoin-Qt may not save that information anywhere in the wallet. It might be better just to put all of it into the label. This is frustrating, because it makes more sense (to me) to use it as I described it and implemented it in Armory, but it may not achieve the desired result with Bitcoin-Qt. How does Multibit and Electrum deal with "label=" and "message=" fields? |
|
|
|
I wanted to share all the information I accumulated on the topic of "bitcoin:" URL's so that developers and merchants don't have to be intimidated by them (I was, at first). I recently figured all this out in the past two weeks while integrating full support into Armory, which is now available in version 0.75.1 (latest). But I may not be doing everything efficiently, and I will need to figure it out on Mac/OSX, too. So I wanted to share what I've learned, and use the discussion to fill in the gaps and make this a one-stop place for handling bitcoin URI strings. Also, if you know the proper way to do this in Unity and KDE, please let me know!
Creating and parsing "bitcoin:" URI Strings: This is the easiest part, which is fully-documented in BIP 21: URI Scheme. Here a simple example of how you would include it (using my donation address, of course!) <a href="bitcoin:1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv?amount=1.0&label=Armory%20Donation%20Address&message=Donation%20to%20Armory">Donate 1.0 BTC to the Armory Project!</a> ...which looks like: Donate 1.0 BTC to the Armory Project!In order to encode URI-reserved characters such as spaces, various punctuation, etc, you need to the percent encoding scheme. It consists of taking the message you want to put into the URL, and replacing all spaces with "%20", all exclamation points with %21, etc. It's all on that link. I believe that the "label" field is to label the address and that the "message" field is for marking the transaction. i.e. if you click on a link that has label "Eto's Key" and mess "Donation to receive his Encryption Seminar", then the "Eto's Key" would show up in the address book, and the "Donation to receive..." would show up on the transaction ledger. For addresses that are only ever used once, I don't think it matters, but that's how I interpret the difference between the two. I think both these fields is where the real value of bitcoin URLs happens. Merchants are best equipped to create these field entries automatically, and can insert things like Order#, purchase information, etc. Maybe even contact information. Then, the user ends up with full purchase history and documentation in their wallet without any effort. UPDATE: For now it seems like a good idea to only use the "label=" field for any information that should be saved in the wallet. I believe Bitcoin-Qt will not save the "message=" data, which used to be described as "a message to display after the URI is clicked" (or something like that). I'll follow up with the devs about it.
Registering your application with the operating system: Windows: It was intimidating at first, but after some research I found out it's only a couple of registry key modifications. And of course, I use python so anything is easy ("import _winreg"). My python code for doing it is in ArmoryQt.py around line 500. The following process is executed every time Armory is opened: - Check "HKEY_CLASSES_ROOT\bitcoin\shell\open\command" if it exists and if it's set to anything (should not be modified)
- If not, check "HKEY_CURRENT_USER\Software\Classes\bitcoin\shell\open\command" if it exists and it's set to anything.
- If it is set to another application, pop up message box asking if they want to use this program as the default
- If it's not set or does not exist, or the user confirms they want to make it default, create and set all the following registry keys:
HKEY_CURRENT_USER\Software\Classes\bitcoin Name: "" Setting: "URL:bitcoin Protocol"
HKEY_CURRENT_USER\Software\Classes\bitcoin Name: "URL Protocol" Setting: ""
HKEY_CURRENT_USER\Software\Classes\bitcoin\shell
HKEY_CURRENT_USER\Software\Classes\bitcoin\shell\open
HKEY_CURRENT_USER\Software\Classes\bitcoin\shell\open\command Name: "" Setting: "C:\Path\To\Program.exe %1"
HKEY_CURRENT_USER\Software\Classes\bitcoin\DefaultIcon Name: "" Setting: "C:\Path\To\Program\appicon.ico"
Where I put Name=="" means set the default param for that key (every entry has a default). Python uses an empty string to reference it
Don't modify the HKEY_CLASSES_ROOT objects -- you can't do so without admin/root, anyway. But I think this really needs to go under the HKEY_CURRENT_USER which is local settings for this user, and they can be modified by a user-level program on application load. However, you could add an install option that modifies "HKEY_CLASSES_ROOT" to set it as the default for all users (which the user can then change for their own account using the HKEY_CURRENT_USER registry keys). Update: Diapolo mentioned a way to overwrite registry keys using a .reg file. This could be useful at installation time, though it will overwrite the keys regardless of what's there already. I'm sure there's an easy way to expand this, though.
Registering your application with the operating system: Linux: I got this working in Ubuntu, tested successfully on 9.04 up to 12.04. However, this solution probably only works for Gnome, and for 10.10+ (or maybe 11.04+) there appears to be a bug in Unity desktop that requires a root-fix. I didn't find a user-level solution for the Unity-based versions. Gnome-Based DesktopVery similar to the Windows registry solution, but using the gconf-editor instead. I didn't know how to modify it directly through python, so I just collected the correct command-line calls and execute them using subprocess.Popen(). Check for an existing [user-level] handler with the command: gconftool-2 --get /desktop/gnome/url-handlers/bitcoin/command which in my case returns: "python /usr/share/armory/ArmoryQt.py %s". I simply search for "ArmoryQt.py" in the output and use that to identify whether Armory is currently set as the default. Then to set it, I use the following calls: gconftool-2 -t string -s /desktop/gnome/url-handlers/bitcoin/command "python /usr/share/armory/ArmoryQt.py "%s"
gconftool-2 -s /desktop/gnome/url-handlers/bitcoin/needs_terminal false -t bool
gconftool-2 -t bool -s /desktop/gnome/url-handlers/bitcoin/enabled true You can see where I do this in ArmoryQt.py around line 465. If another app is set and this is the first time the user has loaded Armory, I skip the question window... the user has enough to worry about with this new program... Unity-Based Desktop (and maybe KDE...?)This works for Ubuntu 11.04+, and also shows one way to get your app into the user's Applications menu. Note that this solution is a root-level fix: you're not going to be able to do this for on-load unless the user is running your app with root/admin permission. Because the gconftool-2 stuff is borked in 11.04+. For installing your own app into the menu, you need to create a desktop file: My armory.desktop file looks like this: [Desktop Entry]
Type=Application
Name=Armory
GenericName=Bitcoin Client
Comment=Full-featured Bitcoin wallet management application
Categories=Qt;Network;
Exec=python /usr/share/armory/ArmoryQt.py %u
Icon=armoryicon
StartupNotify=false
Terminal=false
MimeType=x-scheme-handler/bitcoin
The text that is bolded is left out on Ubuntu 9.04-10.10. It is included for 11.04+ so that it permanently registers the app with Ubuntu during installation. I believe root is needed to change this. Of course, just having the desktop file made isn't enough, it needs to be installed: xdg-icon-resource install --novendor --context apps --size 64 /usr/share/armory/img/armory_icon_64x64.png armoryicon
xdg-desktop-menu install --novendor /usr/share/applications/armory.desktop (note that the .desktop file uses "Icon=armoryicon", so the first line registers a relationship between the string "armoryicon" and the actual location of the icon to use). At least this can be done and put in the Makefile, and you don't have to deal with extra startup operations... but it is kind of rude to other client developers. I'm happy to take recommendations for how this could be improved. And also support for non-Gnome-based desktop managers.
Registering your application with the operating system: Mac/OSX: I got nothing. I haven't even tried yet. Maybe someone can fill me in, in preparation of having to support it in Armory one day (I promise, Armory will support Mac...eventually). |
|
|
|
I've updated CoinDL QR codes and added a Buy Now button that points to the URI. Looking forward to seeing many more sites accepting these links!
Hey Weex, That's great. Just one recommendation. I believe that we should use the "Label" field to mark the address, and "Message" to mark the transaction. At least that's how I do it in Armory: The "label=" is what shows up when you're looking through your address book, but the "message=" is what shows up when looking at your transaction history. For the case that every tx uses a different address, I don't think it matters too much. But it's a distinction that might be worth mentioning (notice my original example where I use both), or at least someone can correct me if they think I have it wrong. Also, you can put spaces and other special chars in the URL using percent encoding. Use %20 for spaces, %28 and %29 for left and right parentheses, etc. I'll add that link to the original post. And add a link in the Technical forums for the Registry settings I mentioned above. |
|
|
|
Does Bitcoin-Qt support the URLs? I thought they did, but I haven't seen any evidence of it. I think we should encourage the devs to step up support for it because Bitcoin-Qt is still used by most users and it's really not hard. I recently figured out how to do it reliably and responsibly through non-admin-modifications of user-registry settings. Much the same way that Firefox/IE/Chrome check and modify on load for "http://" links. It seems that all they would have to do is check the registry settings for it on load and request to change it if some other app is currently set. Well, that's all I did in Armory, but of course everything is always easy in python ("import _winreg") |
|
|
|
OK, sure. I don't see the usability of installation as separate from the usability of software, but it can be argued both ways. I think if that gets fixed we can just drop the parts about it being for tech-savvy people entirely. Agree we can make it clear the reviews are independent. Amir? For what it's worth, there's a reason I'm so focused on the install. At Google we measure how many users make it from "see product web page" to "running the software". It's amazing to see how people drop off through this funnel. There are some interesting findings from these studies: - Users abandon installs a lot. Of people who see the web page, typically only a small percentage will actually end up running the software.
- Literally every additional click required kills a significant number of installs. Users really do give up at every possible point through an install. Google has put a ton of effort into reducing the number of clicks needed to install our software. If you have Google Update already active on the system, the number of clicks on Windows to go from the Chrome web page to it being open and running on your desktop is tiny - actually there are no confirmation prompts at all, IIRC.
- The longer an install takes, eg because of a large download, the lower your success rate will be.
- If anything is even slightly confusing, that will cause users to drop out too. For instance the way MacOS X handles software installation by default is consistent, GUI oriented and totally confusing (I'm talking about the DMG + drag/drop to apps folder). There's a reason virtually all consumer software has a link to the Applications folder with a giant arrow telling you what to do, and it's because huge numbers of users won't be able to correctly install the software if you don't do that, despite that it works exactly the same way for almost every MacOS app. Apple really dropped the ball on the design of this setup.
So when I see an install process that involves manual dependency resolution, what I see is not a minor picky issue but a massive drop in the success rate of users who click through that. Like probably >90% abandon rate. And if users click through to this client and are overwhelmed by the instructions, or fail to correctly follow them, they won't necessarily go back and try a new one. They'll just drop out entirely and we'll lose them for a while until one day they decide to try Bitcoin again (assuming that ever happens). This can largely be resolved with simple installers. The advantage of being open source is you don't require a long EULA either (this also drops the success rate). You can literally have a one click install'n'go experience. You can, if you want, beat most commercial software for ease of install. To follow up on that, I recognized how many of my own users were getting stuck at the installation process, so I finally dug into it a couple weekends ago and Got It Done, in Armory. I used Jgaa's "War Setup" for Windows. It is pretty fast and easy after you get past a few hangups (like how to add your license if it's not on their default list). I selected the "Minimal" install which literally just has an EULA and a "Install" button. Done. It's almost too easy -- the program is installed before you even realize that was the last button to press! For Linux, I made Debian packages to support Ubuntu/Debian, and that was actually a pain in the ass, but totally worth it once you figure it out. Worth it because it's easy to tie it into your build process so that building the .deb package is just an extra couple keystrokes on the command-line build process. I figured, anyone using a non-Ubuntu setup is likely familiar with the compile from source process, and Armory's isn't so bad. So I left that as is. If I ever get a Mac, I will make an installer for that too, but I don't know how difficult that is. I've gotten tremendously positive response to making installers. Hopefully what I wrote above can help others make them... |
|
|
|
one small issue i see is that having the full bitcoin address as clickable, will make it harder to copy+paste if that's what is needed.
better to have the address in plain text, and then a link next to it.
Agreed. It's not necessary to have it as one/only object. But there's plenty of space on these forms/windows/boxes to add a link for convenience for us users that do have supporting clients. |
|
|
|
Our QR code on every Bit-Pay invoice is the bitcoin: URI, and I can confirm it works with 3 mobile wallets. Blockchain (iPhone), Bitcoin Wallet (Android) and BitcoinSpinner (Android). I have paid a Bit-Pay invoice by scanning the QR code and it worked flawlessly.
We did have a clickable link as well, but none of the clients supported it, so we took it off. Now that Armory does, we will make sure this gets added back to the site with the next update.
Glad to see I have enough street-cred to encourage alone you to re-activate the feature But, I know that Multibit also has support for it, too (with the OS registration). I thought that Bitcoin-Qt did too, but I haven't seen it work yet... I didn't realize the QR code used it. Good to know! P.S. -- URL support was added only to the very latest version of Armory: version 0.75. Previous versions won't work. |
|
|
|
|
Show Posts
