So... is version 0.92 bug-free or are people not testing anymore? I'll take this as a good sign for the upcoming release! Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11. doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it. I will assume no news is good news  Windows 7: Armory pops up in front despite having the option to start minimized to tray checked. And it's quite very annoying. The issue persists with version 0.91.99.11. I cannot replicate this. I have tested in both Linux and Windows, and the option works for me. Please try renaming your ArmorySettings.txt file (in C:\Users\<user>\AppData\Roaming\Armory), and then start Armory again -- it will be like new, asking you to agree to the EULA, etc. Try setting the option again in the menu and then restart. Tell me if it works. |
|
|
|
So... is version 0.92 bug-free or are people not testing anymore? I'll take this as a good sign for the upcoming release! Also, any Mac users please chime in -- we're anxious to find out if Mac stability improved with .9 and .11. doug_armory found some patches that supposedly improved stability noticeably, but no one has yet commented on it. I will assume no news is good news |
|
|
|
Sorry I was talking about my watch-only wallet, the cold wallet is on a perma offline computer. Ahh, I see. Very good. So you think keeping the OS up to date is better then? I was worried maybe I could pick up some sort of vulnerability by updating lots of things. I would (and do) keep my OS updated. Some of the updates fix vulnerabilities. We've tried to make it so that if the online computer is totally under the control of an attacker, there's still minimal risk to the offline computer. You obviously want the online computer to be free of malware, and so you should take preventative measures, but it's still the offline computer that matters. And the attack surface is pretty slim. People have asked if the offline computer should be updated with OS updates, etc. My attitude on this is: if you are going to keep the offline computer updated, you are introducing far more risk than you are reducing: you will be regularly transferring data from your potentially-compromised online system, and executing it with root privileges on your offline computer (to install the updates). This seems to introduce a recurring (weekly?) channel for remote, root execution by the online computer to the offline computer. Even without a fancy USB virus, this could be exploited with someone pushing a coin-stealing chunk of code into a system library/service update silently. It doesn't have to persist for long to compromise a lot of people who are diligent about updating their offline computer. Personally, I'd feel safer using a version of Linux/Ubuntu that has been around for a while (perhaps before Bitcoin was worth $billions), and has a well-known verifiable CD/DVD hash. I believe the attack vector of such an OS--even if there are known vulnerabilities--is far smaller than having users regularly execute code transferred from their online computer with root privileges. Also, updates can also introduce vulnerabilities. It might be the case that vulnerabilities are reduced on average, but if you are updating software with all sorts of new features, you might actually be adding more vulnerabilities than you are fixing. |
|
|
|
FYI, this feature slid quite nicely into the new wallet format I'm working on. One thing I wanted to mention for completeness, is the necessity to make sure that you cannot verify passwords individually. I am storing key-stretching info with each fragment, so that Armory knows how to decrypt it, but all it decrypts is an opaque 32-byte chunk of data, with no clear indication of whether the result is valid. The only way to know is if a quorum of passwords is present to restore the master encryption key, which then can be checked for accuracy. This is important, because it means that you are exponentially increasing the effective entropy of the master key encryption, not linear. For instance, let's say you have a 3-of-5 password and each of the 5 participants chooses a password with 40 bits of entropy. If you can verify each password independently then the effective brute-force time is: 3 * bruteForceTime(40bits) Instead, I'm making sure that only the final reconstucted key can be verified, which means brute-force time is: bruteForceTime(3 * 40bits) Quite literally, the first one is brute-forceable while the second one is not. The downside is that if one person types their password incorrectly, there's no way to know without everyone re-typing their passwords. I think the CONOPS can be extended so that when the passwords are initially set, each participant ALSO inserts a USB key and gets a 3-of-5 fragment of the wallet backup (unencrypted) copied to it. They can then protect that however they see fit, such that you need either: (A) Encrypted wallet file + 3-of-5 passwords (B) 3-of-5 fragments to restore a lost wallet file However, if three people lose the USB drive and three people forget their password, the wallet would not be recoverable despite having 4 "pieces" (2 passwords + 2 fragments). Perhaps the unencrypted password fragment should be copied along with the unencrypted backup shard. Either way, this seems to have all the right properties for multi-user protection of a wallet or a piece of a multi-sig wallet. You could also print out this data onto paper, but there would probably be some OPSEC issues having 5 people in a room all being exposed/flashed to fragments getting printed. |
|
|
|
|
It's called "Do not ask again" or "Do not show this message again". That's been there for a while but only when you click the "Offline Transactions" button on the main window. On the .11 testing release, it is now also displayed when you try to create any unsigned transaction.
If you click the "Do not show again" box, it will disable it in both places.
|
|
|
|
Hi, noob question: I would like to create a 2of3 multisign address. But I would like two addresses be created using https://play.google.com/store/apps/details?id=com.bitpay.copay and one address from Armory. Is this possible? Can I import the public key from Armory on Copay? Can I import the public keys created on Copay on Armory? Some day there will be a standardized way to do Multi-Sig. Until then, you can not mix and match. You can import the addresses into Armory, and i assume into Bitpay as well, but you have to do Multi-Sig on one or the other. IMHOP, the way to use both is to split up your Bitcoins and just use each separately. More specifically, I'm sure you can create the multi-sig with mixed keys, since public keys have a standard encoding, but you won't be able to easily spend the money because Armory doesn't know how to communicate with BitPay/Copay, etc. As CircusPeanut said, standardization will need to be developed but everyones' multi-sig implementations are too young to have gotten to that point yet. |
|
|
|
I'm guessing because the inputs must be pre scanned to make sure they're still valid
That shouldn't be a good reason. Validating the inputs is done by every node as it's transmitted across the network. This is why Bitcoin Core has a UTXO database and the gettxout command: so you can check if it's possible to spend a txout for any address - including those you aren't particularly following. FYI, I think .11 has a fix that allows you to load, review, and broadcast any Armory transaction regardless of its relationship to your wallets. Use the offline transactions if it's an Armory sigcollect block, or Tools->Broadcast Raw Tx if it's a regular hex transaction. |
|
|
|
Looks like one of my testnet wallets is producing invalid transactions with the latest version (0.91.99.11-beta). Every time I try to send bitcoind disconnects then reconnects and gives the log message "2014-07-20 00:36:46 ERROR: AcceptToMemoryPool : inputs already spent". I was doing some rapid spending/receiving before I did the upgrade, but everything was already confirmed before I shutdown armory to do the upgrade. I'm guessing that doing a "Rescan Database" will clear it up, but I'll hold off doing that in case you guys need some other log/trace data.
Strange... if you can still replicate the error can you go back to .9 and test if it's oding the same thing? I don't think anything changed between .9 and .11 that would've induced that kind of error. |
|
|
|
|
There appears to be a misunderstanding here. Armory is not part of any repo. Updating/upgrading your system will not do anything. Even if synaptic was used to install it, it has no idea how/where to look for updates. You cannot update Armory in this way.
You have to download the new version from the website, or if you're now 0.91+ already, you can use the built-in secure downloader to grab the latest version for your OS and Armory will verify the package signatures for you. It won't automatically install it for you, but it will put it in a folder where you can go double-click to install (or not put it in the folder if the signature isn't valid).
|
|
|
|
|
I guess we really need a way to make this clearer.
Download the new version from the website (it's an Ubuntu .deb package). Double click to install. It will overwrite the previous version but will keep all your wallets and settings intact. It's that simple.
If you simply want to remove without installing over it, it was most likely installed with your package manager such as Synaptic. You can open the package manager, search for it in installed packages and mark it for removal. Or I believe you can simply run "sudo dpkg -r armory" from the command line
|
|
|
|
That's an old branch I haven't synced in a month and really haven't developed on since May. Any issues there that aren't in the "devel" branch should be ignored. (In fact, the entire branch should be ignored!) On that note, after this release we're going to go through and clean up all the random side branches. I'd like to reduce to just "master", "testing", "dev", and a couple others that are works in progress. There's a lot of abandoned branches that were really for one bug or feature that took way longer than it should have. A little belated spring cleaning. |
|
|
|
Hello. Just curious, what would you all like to see in the next version of Armory (0.93, although the exact number could change)? We have a lot of things we're working on. We also have a little free time when we like to think of cool stuff that users might like.
A way to hide addresses that have been generated. I tend to play around with my Bitcoin stuff without actually using the addresses generated, which ends up making a lot of addresses that will always have 0 tx, unless I do something semi-manual with them. I see a way to generate more addresses, but not a way to "un"generate addresses (I know there's a cache of ~100 more than are shown, and I don't mind those being there...I just don't want irrelevant addresses to be shown, taking up space). "Un"generated addresses would be returned to the pool in their location, so the next time Armory needs to generate an address, it may pick one of these addresses. (sure it's minor, but it's something that would add to the friendliness of the app, IMO) Only downside I see is that it's a bit easier to reduce anonymity by reusing an address...but this only matters if anyone else is ever sending money to the address. There is a "hide unused" button when in the wallet properties window. That at least will hide them from view when browsing, though it doesn't actually change anything internally. Since there is no limit on the number of addresses you can generate deterministically, we have no reason to complicate the interface by trying to allow the user to specify certain addresses to "suppliable" again with the "Receive Bitcoins" button. No extra work for the user, and they are guaranteed a fresh address every time. If you want to use one of those old addresses, then next time you need it, go to one of those unused addresses and right-click-copy it to the payer. |
|
|
|
The databases, at least for now, are compatible. So you can keep a copy of 0.91.2 on your system, and use that for executing offline transactions.
Unfortunately, it was way too much work to support both formats simultaneously. We had to remove the old one. I recognize that's inconvenient, but we didn't have too many choices in the matter (the new 0.92+ signing system expects different information than was provided by BIP 10 which was used for the old offline tx format).
So the last compatible version is 0.91.2? That's correct. 0.91.2 is the last version that is compatible with.... every previous version of Armory ever made! yes, I believe it works even if your offline computer is running Armory 0.51 which was like 2.5 years ago. BIP 10 served us well, but it's time to move on. As I mentioned in other threads, the new format has been pretty thoroughly tested, and we've done 5-way simulfunding and 7-of-7 multisig with it, and it serves our needs. We don't expect to have to change it again, and if we do, we may be able to do so in a backwards-compatible way. |
|
|
|
|
The databases, at least for now, are compatible. So you can keep a copy of 0.91.2 on your system, and use that for executing offline transactions.
Unfortunately, it was way too much work to support both formats simultaneously. We had to remove the old one. I recognize that's inconvenient, but we didn't have too many choices in the matter (the new 0.92+ signing system expects different information than was provided by BIP 10 which was used for the old offline tx format).
|
|
|
|
I wouldn't expect this qualifies for the 0.03 bounty, but I noticed a little something. At the end of the first paragraph is the text "Untitled".
...
A brief overview of how I got here, in case it matters:
I created two promissory notes (0.1 BTC each) to pay an address in my own wallet, created the TXSIGCOLLECT from that, and then imported that into the Review & Sign window (these are still unsigned transactions).
Whoops, that's a pretty obvious error. You definitely deserve a bounty for that ... or at least we deserve to lose a bounty for not noticing it ourselves This was already pointed out here: https://bitcointalk.org/index.php?topic=607046.msg7606266#msg7606266...and he still gets the bounty because it should've been fixed but still exists in the new testing version. I think we got so distracted by helgabutters' bugs, we forgot to go back through some of the other reports. Whoops. [EDIT: scratch that... it was fixed, but TimS's report was made against an earlier testing version] Enhancement request.
If you send from 1 wallet to another (both controlled by the same armory instance) the outgoing transaction doesn't always show up before the incoming transaction.
...
You know, that has always bugged me, but just not enough to be motivated to go find and update the sorting code. Thanks for encouraging me to do it, finally! Perhaps .9 won't be the last testing release, but I also won't make a big deal about doing a couple tiny intermediate releases. My release scripts are mature enough that it's not a huge burden anymore. And as simple as these changes are, it always makes me uncomfortable right before a release (but none of them are the kind that would lead to money loss if we botched something). |
|
|
|
|
@helgabutters
#3 and #4 are actually the same bug. And I recognize the issue... it's a rare condition that's leading to the data being saved in the settings file being read later, incorrectly. Can you tell me what data is in the "DefaultLinkText" line of the ArmorySettings.txt file? Either way, you can close Armory, remove that line, and then restart Armory and it will be fixed. I'll figure out how to avoid that condition.
|
|
|
|
I wouldn't expect this qualifies for the 0.03 bounty, but I noticed a little something. At the end of the first paragraph is the text "Untitled".
...
A brief overview of how I got here, in case it matters:
I created two promissory notes (0.1 BTC each) to pay an address in my own wallet, created the TXSIGCOLLECT from that, and then imported that into the Review & Sign window (these are still unsigned transactions).
Whoops, that's a pretty obvious error. You definitely deserve a bounty for that ... or at least we deserve to lose a bounty for not noticing it ourselves |
|
|
|
Since this is the last release before 0.92 is there any specific date you are aiming to have it out by?
It's funny you ask that. The guys that work with me would probably complain that I like to declare schedules and then not stick to them. Which is true -- I try to set schedules to give us a target to work for, but the true end date is "when it's ready" Especially with a piece of software as sensitive as this, we never rush anything which might lead to dangerous bugs. So to answer your question more directly: we'd like to officially release this next week. Saturday is a good target for the end of the testing phase. But depending on how testing goes, it may be further delayed. So far, things are looking good, an these bounties have been tremendously useful for speeding up this process so you guys can expect these to continue for further releases! |
|
|
|
I've since realised that the answer to my original question is a yes, as Coinjoin couldn't work if it wasn't possible to sign one tx with multiple private keys. So it can be done, I just don't think Armory now lets you as a part of it's transaction building GUI. A complete dust-be-gone feature would be nice though, and it'd be especially efficient if it allowed many wallets to one transaction  Strictly speaking, the answer to your subject line is: yes. The new simulfunding features do allow you to simulfund one transaction from multiple input wallets. However, talking about dust: due to the complexity of allowing it, we do not have coin-control available for simulfunding transactions, so your wallet would have to be empty except the dust, in order to guarantee that the dust is used in the simulfunding tx. If you have 5 wallets with only dust, you could create 5 prom notes for the full amount of each wallet -- which can be done by going to "Merge promissory notes" and then add 5 notes in the interface, one from each wallet. But if the wallets aren't otherwise empty, it's likely not to behave how you expect. Though you could just empty all of the wallet entirely back into one of your own wallets, which will destroy the dust and merge all the wallets into a single address/UTXO. |
|
|
|
|
Show Posts
