I've got a question regarding the secure downloader. Exactly how secure is it?
Very. Does it download through encrypted connection? Does it verify signed or hashed files?
Yes and yes. announcefetch.py has hardcoded HTTPS URLs with an associated hardcoded public key (the private key to this is kept offline). This URL is a signed message and links to https://s3.amazonaws.com/bitcoinarmory-media/dllinks.txt (including a SHA256 hash), which is another signed message with links to other HTTPS addresses (including SHA256 hashes) that are the actual downloads. It stores this signed dllinks.txt file in %appdata%\Armory\atisignedannounce\downloads.file. It is, for all practical purposes (finding a SHA256 collision is not practical, for example), impossible for a man-in-the-middle without that private key to trick you into installing something incorrect/compromised. The HTTPS encryption is not even needed for this sort of setup to be secure (it does improve privacy, etc.), so it doesn't even really matter if you have some shady root certificates loaded. The easiest way to break it is probably this: A super-user/administrator on your local box could replace your ArmoryQt executable with their own file pointing to their own URLs and public keys. But if they can do that, the main purpose of their replacement ArmoryQt will probably be to simply send your private keys to the creators of the app as soon as you unlock your wallet for a tx. And if you can do that, compromising the Secure Downloader would have limited value. |
|
|
|
I'm getting a BDM error now:  Was using 0.93.0.70 supernode, Win 7 x64. After restarting computer and trying to start Armory as usual, Armory showed "missing txio" error message (above) and crashed. Tried to update to latest 0.93-bugfix branch (0.93.0.80, build 66702e78f5), and run from ArmoryQt.py, and had same error. This is preventing me from running Armory at all. Do I need to rebuild/rescan, wait for new version, or something else? Sent logs via https://support.bitcoinarmory.com/ site. |
|
|
|
0.92.99.7 supernode, Windows 7
I had two new transactions today, one sending and then one receiving. Both showed up when they had 0-conf, and then disappeared later, making Armory show an incorrect balance. I think each disappeared when it got a confirmation. Upgraded to 0.93, ran Help > Clear All Unconfirmed, and restarted Armory several times with no change.
Something that might have had an impact on this was that I also had a wallet loaded into Armory with ~131,000 imported private keys and many transactions on those addresses.
Wallet size will not impact supernode at all. This is some sort of scanning corner case. Can you see these transaction as part of the main chain in bc.info? I won't be going directly after this since I'm currently modifying a bunch of stuff in supernode for more stability and speed (this is for 0.93.1) Yes, the transactions appear in the main chain, and no orphaned/other blocks (that bc.info is aware of). I'm still having this issue in 0.93 and the current 0.93-bugfix branch (0.93-beta-a4561d1fa9 is what shows up in About): a perfectly ordinary transaction appears when it has 0-conf, then disappears when it gets 1 confirmation (until I rescan, which takes a long time). This appears in the log every time it encounters a new block: -ERROR - 1425181756: (..\StoredBlockObj.cpp:1863) We should've found an unpsent txio in the subSSH but didn't
-ERROR - 1425181756: (..\BlockUtils.cpp:1585) Error adding block data: missing txio! Also, maybe related, I have these lines repeated many times in my log files, from 2-20: 2015-02-20 18:17 (ERROR) -- Traceback (most recent call last):
File "armorymodels.pyc", line 1102, in data
File "CppBlockUtils.pyc", line 1729, in getScrAddrObjByKey
RuntimeError: no ScrAddr matches key
2015-02-20 18:17 (ERROR) -- Traceback (most recent call last):
File "armorymodels.pyc", line 1169, in data
File "CppBlockUtils.pyc", line 1729, in getScrAddrObjByKey
RuntimeError: no ScrAddr matches key
2015-02-20 18:17 (ERROR) -- Traceback (most recent call last):
File "armorymodels.pyc", line 1128, in data
File "CppBlockUtils.pyc", line 1729, in getScrAddrObjByKey
RuntimeError: no ScrAddr matches key
-ERROR - 1425164415: (..\BlockWriteBatcher.cpp:429) STXO needs to be re-added/marked-unspent but it
-ERROR - 1425164415: (..\BlockWriteBatcher.cpp:430) was already declared unspent in the DB
-WARN - 1425164415: (..\StoredBlockObj.cpp:1883) failed to erase txio in subshh: doesn't exist!
|
|
|
|
For example sake, let's say I have 10 bitcoins stored in a Coinbase.com wallet. From what I hear Coinbase.com controls the private key for all of the wallets they issue.
In short, if I use Armory's SWEEP feature I move both my 10 bitcoins and the Coinbase.com private keys to my Offline PC for cold storage.
However, if I use Armory's IMPORT feature I move only my 10 bitcoins and the Coinbase.com private keys remain behind with my Coinbase.com wallet.
Am I understanding it correctly?
You can only sweep or import bitcoins if you have access to the private key(s). Coinbase.com does not give you access to the private keys. This is what is meant by "Coinbase.com controls the private key". Your only option for your bitcoins that are currently at this particular site is to send the money to another address. For blockchain.info, you control the private key, meaning that you alone (not blockchain.info) have access to your private keys. For this one, you have the option to sweep, import, or send the money. |
|
|
|
You don't need to install Armory and Bitcoin Core on your external drive to have their data be stored there. Install Bitcoin Core and Armory on your SSD. Before starting them, follow the instructions at https://bitcoinarmory.com/troubleshooting/#q5 about setting --datadir and --satoshi-datadir to move both the Armory and Bitcoin Core directories to your external hard drive. Don't try to start Bitcoin Core or Armory without the hard drive plugged in, of course. |
|
|
|
Importing is most useful when you have a private key and you expect that you might receive payments there in the future. Imported private keys aren't covered by your paper backup (which you should have before you put any money in Armory!). Sweeping is most useful when you have a private key that is not in any online wallet and you wish to take the money from it and move it into your wallet. With blockchain.info, you own your private keys and can do either of the above. With coinbase.com, you do not and cannot do this. Neither of the above options really fits your situation, anyway. This is what I'd recommend: don't sweep or import. Just send the bitcoins from your existing web wallets to Armory addresses (in Armory choose "Receive Bitcoins"). That way, everything is covered by your one paper backup, address reuse is minimized, Armory doesn't have to do any extra rescanning for something that another wallet already has the ability to work with, etc. |
|
|
|
If you can hold off until 0.93.1, and aren't interested in running a supernode, you don't need to upgrade your hardware for quite a while, because Armory will no longer store its own copy of the blockchain, instead just having a ~120MB database: I'm intrigued by this. Are you saying that as of 0.93.1, the Armory database in a default installation will only take up 120MB of disk space?
Yes |
|
|
|
1) In a deterministic wallet can somebody guess all the private keys from the wallet if one of them is compromised (if the one compromized is not the seed key but lets say the 2nd one)?
No, however, if the MPK and one private key is compromised, then all of the private keys can be computed. The master key can only be compromized if somebody hacks into your wallet physically. However a random private key could be guessed if the signing process is flawed, so i wasnt concerned about the master key, but rather of the individual keys of addresses. A deterministic wallet is not necessarily a physical device, like a Trezor, so your first statement can't possibly be correct. If one of those "random private keys" is guessed/leaked, and the attacker also has your master public key (i.e. the thing to generate the list of addresses, but not spend from them), then he has something just as good as (if not equal to) your master key: the ability to know your private keys. What if none of my addresses in 1 wallet have cross-transaction between them, and they are all receiving payments from different sources, then is it posssible to reveal privacy & identity here or link together those addresses (they are all deterministic of course)?
No, privacy should be secure here (at least until you spend, and combine inputs): there's nothing obvious that links one address to another, just because they come from the same deterministic wallet. What is a HD wallet?
HD = Hierarchical Deterministic. https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki has details on it, but basically it means that you can have one master key create more deterministic wallets. Not all deterministic wallets are HD wallets, but I think the terms are sometimes used interchangeably anyway. |
|
|
|
0.92.99.7 supernode, Windows 7
I had two new transactions today, one sending and then one receiving. Both showed up when they had 0-conf, and then disappeared later, making Armory show an incorrect balance. I think each disappeared when it got a confirmation. Upgraded to 0.93, ran Help > Clear All Unconfirmed, and restarted Armory several times with no change.
Something that might have had an impact on this was that I also had a wallet loaded into Armory with ~131,000 imported private keys and many transactions on those addresses.
Wallet size will not impact supernode at all. This is some sort of scanning corner case. Can you see these transaction as part of the main chain in bc.info? I won't be going directly after this since I'm currently modifying a bunch of stuff in supernode for more stability and speed (this is for 0.93.1) Yes, the transactions appear in the main chain, and no orphaned/other blocks (that bc.info is aware of). |
|
|
|
0.92.99.7 supernode, Windows 7 I had two new transactions today, one sending and then one receiving. Both showed up when they had 0-conf, and then disappeared later, making Armory show an incorrect balance. I think each disappeared when it got a confirmation. Upgraded to 0.93, ran Help > Clear All Unconfirmed, and restarted Armory several times with no change. Something that might have had an impact on this was that I also had a wallet loaded into Armory with ~131,000 imported private keys and many transactions on those addresses. I've since removed the many-key wallet and triggered a Rescan, which is in progress. Please send me a PM if you think you are owed more bounties than you received.
The way I counted it, it's as high as 25. How do I know which reports did/didn't earn bounties and why? |
|
|
|
Question to the folks who've been testing 0.93 the most: what are your biggest remaining concerns with this release? If I told you I was going to release the software after fixing the tx export problem (which will be in a .6 release in the next 24 hours), what would you complain about the most? No version of Armory is perfect, and at some point we have to say "pencils down", as long as there's no security or major usability issues.
I thought of another minor concern: There's nothing (AFAIK) in the UI telling you whether you're running as a supernode or not. |
|
|
|
(0.92.99.6 fullnode, Ubuntu 14.04) http://imgur.com/B2dUZqP,XISEcY0,qRP1UkLWhen trying to delete private keys from wallet and I click the lower radio button (to delete just private keys), it doesn't deselect the top one (to delete the whole wallet). The dialog has the message as if it were going to delete the wallet, but it only deletes the private keys. |
|
|
|
(0.92.99.6 supernode, Windows 7) I'm trying to import a large number (131,070) of private keys into a wallet. When I import a large number of private keys at once (all new, no duplicates), it writes 2015-02-07 10:09 (ERROR) -- PyBtcWallet.pyc:2523 - The computed private key address is already in your wallet! to armorylog.txt a large number of times. For example, when importing 300 new private keys, it writes that 44,850 times. 44,850 just happens to be the 299th triangular number, strongly suggesting that key n is causing the error to be written n times (give or take). The keys are at http://pastebin.com/E7CjDhmA, in case it matters (they are of a very simple form, only the first or last two bytes are non-zero, so they're not really all that private). This causes the import process to slow down tremendously. Some of these imported addresses have an incorrect #Tx count. E.g. 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreakL7yRD, address 1NvxH7VHMwVdwHCpwLLVhecieHZy3oVPoZ, shows 1 Tx and a balance of 0. At one point, while opening Armory with a large (many imported keys) wallet (I mention that because I think it makes the Wallet Consistency Check take longer, unsurprisingly), the two messages here were overlaid:  and  I have yet to be able to reproduce it to show you a screenshot of the actual problem, and I'm not 100% sure that was the same "Blockchain..." message, but I do recall seeing it start with "Blockchain" (the green bar was on top, obscuring everything past the "B"). |
|
|
|
The Goto button is cut off a little. (Windows 7)  |
|
|
|
 The main header says that Armory is disconnected, the status bar says that it is connected. According to Bitcoin Core, the current block is 342339 (matching Armory) and Armory is not one of the peers connected to it (Bitcoin Core is at the max connections, so I get why Armory isn't connected currently). It appears that Armory is not connected, but is still keeping up to date somehow...by reading the blocks from disk, maybe? It's odd that the messages don't seem to match. Is this a bug? Edit: Since posting, Bitcoin Core has received block 342340, and now Armory says "Disconnected" in the status bar. Edit 2: Now at block 342348, and Armory shows up like my image above ("Armory is disconnected" and "Connected (342348 blocks)"). Also, the "br>" is still visible. |
|
|
|
(Windows 7, 0.92.99.5) When I try to import a lockbox from a file and select a file, the open file dialog quickly closes and reopens. If I select a file from this reopened dialog, it works correctly (puts the second file's content into the window so that I can import it).
That should be fixed in upcoming .6 Indeed it is, which made me find a new bug: On importing a lockbox, I get the following message:  I'm running a supernode, so it doesn't actually need to rescan anything. |
|
|
|
(Windows 7, 0.92.99.5) When I try to import a lockbox from a file and select a file, the open file dialog quickly closes and reopens. If I select a file from this reopened dialog, it works correctly (puts the second file's content into the window so that I can import it). Okay, a contest. Extra 2 bounties for the winner!
Wtf do we do with the paging control widget? Since writing the above message, we have spent even more time debating this. The problem stems from the fact that
- If it's placed on the tableview itself, it obstructs things (or at least, it annoys me), and the user may not want/need it
- If it's placed outside the tableview, then the dialog must have extra space to put it. Not a problem for the main window, but it will need to be placed for the wallet address ledger and the lockbox ledger. Both those dialogs are short on space.
Obviously we want it to be available for those that need it, and it shouldn't be a easter-egg... it should be easily accessible for users that want it (i.e. we don't want to have a feature then get emails asking for us to implement it because they don't realize it's there).
One option is to leave it where it is, but add a setting to allow the user to disable/hide it. That's probably the easiest to implement, and not a bad choice. I'll give an extra two bounties to whoever provides and idea that we like enough to implement. If you have a transaction history of 1,000,000 rows, spanning multiple years, how would you like to navigate that history? And if you switch the filter to a wallet that has only one page of history, what happens to that control? Should it be hidden, moved, or left where it is? Should it be totally user configurable.
Ideally, whatever it is can be non-intrusive enough to have visible all the time and not inconvenience users that have small transaction histories and/or don't need the fancy controls.
When the user has over 100 (or whatever) transactions in the given list, show a search button (e.g. magnifying glass or calendar icon, or just "Search" or "Filter") on the Date column header (or hovering where the "#" is now) of the transaction tableview. Clicking it opens up the dialog that currently opens when you click "Date:" in the hovering box. Maybe add a time option, too. I don't think that most users would need/want to search by Block # (especially since the Block is not shown on the transaction list!) or need a shortcut to jump to the Top (they have a scroll bar), like the dialog has now. And if you only have a few transactions in your list, there's no point in having anything more complicated than scrolling to search it. Putting the search icon in the Date column header means that you don't have to worry about making space for it, or having it cover data. Maybe the 100 figure should be configurable, including "always show" and "never show [the search button]" options, to help users discover it and adjust the behavior to their liking? I don't see any other configuration options being necessary. Question to the folks who've been testing 0.93 the most: what are your biggest remaining concerns with this release? If I told you I was going to release the software after fixing the tx export problem (which will be in a .6 release in the next 24 hours), what would you complain about the most? No version of Armory is perfect, and at some point we have to say "pencils down", as long as there's no security or major usability issues.
--supernode, --datadir, and --satoshi-datadir are, to the best of my knowledge, command-line-only options: you can't specify them in a config file (probably others, but those are the ones I've used and noticed it on). This is an annoyance, albeit minor: keeping track of proper shortcuts/startup links to Armory, making sure I don't accidentally let the installer run Armory after it finishes (because it won't specify my command-line options), etc. Using my supernode to its fullest extent (e.g. running a blockchain explorer) without great difficulty requires running armoryd.py on Linux. It would be nice if Armory (Qt) on Windows could be configured to respond to the same API commands. TBH, I probably wouldn't be complaining except that you asked for it. |
|
|
|
Last time I downloaded Xcode it was free. Pretty sure you can still develop for OS X without paying. [EDIT: And have you any idea how much an MSDN/Visual Studio subscription costs per year? But you can still develop with Visual Studio Express for free]
Even better now: http://www.visualstudio.com/en-us/products/visual-studio-community-vsBasically, VS Pro is free unless you're a big (>$1m/year) business. |
|
|
|
This transaction was included in a block that was then orphaned. Armory people, does this explain the strange behavior, and maybe let you fix the issue for future versions? |
|
|
|
Can an Armory data dir/DB be shared between Windows and Ubuntu, e.g. in a VM or dual-boot setup? I tried to have Bitcoin and Armory share (via Shared Folders, Ubuntu is the guest) with Oracle VM VirtualBox and had issues with both. This was in the log (note that the path there is correct): -ERROR - 1422668995: (BDM_mainthread.cpp:429) BDM thread failed: Failed to open db /media/sf_Armory/databases/blocks (Invalid argument) And then when I tried to open it in Windows later, it was corrupt:  Currently doing a rebuild/rescan like it suggested.  |
|
|
|
|
Show Posts
