tried to find the answer but couldn't. Is there a way to verify a message signed in armory with the bitcoinqt and vice versa?
Sorry BRules, There is not available, yet. I implemented message signing about the same time Bitcoin-Qt, and I was pretty much done by the time they identified how they were doing it. I didn't have the crypto functions immediately available, yet, and I designed my message signing interface around "Signature blocks" which the Bitcoin-Qt devs didn't seem all that interested in. When I upgrade to new wallets, I will grudgingly convert to their version, though I hope I can convince them to do something like signature blocks, since their mechanism seems really clunky and error-prone... Ok, not to continue hijacking the threat, but I stayed up all night coding again and I vastly improved the serial communication.
Now, Armory tries to listen on the serial device as soon as it's started (rather than only in the offline tx dialog), and it encapsulates its messages to and from the server with protocol buffers. This allowed me to expand the types of messages available (as well as add more robust handling). Currently, you can import a watching only copy of a wallet directly from the offline device. I plan on extending the "Create new wallet" dialog to allow something similar - initiate the creation of a new wallet on the offline device, and send the watching only copy back. Also needed is to make the connection off by default, and enabled in the advanced or expert options, as well as setting the serial device and baud rate.
Cool! Just don't get too crazy with it... we still want the interface to minimal in terms of complexity and functionality -- less room for security holes. But, you are doing something I've wanted to do for some time. I look forward to playing with this myself (especially because I already have serial-usb cables and a null-modem connector. The diff now has quite a few more changes, but it's still surprising to me how little code it took. I'm really liking python, and etotheipi, your code base is a pleasure to work with! I will never get tired of hearing that  All this stuff you've been coding, it sounds like you're ready to become an Armory apprentice! You're already debugging my next upgrade challenge (the 0.8 blockchain stuff)... |
|
|
|
My point was that for insertion/deletion, only the trie node being attached to/removed from requires an insertion/deletion in the leaves of its Merkle tree. All of this node's parents simply have to update the value of one of the leaves in the Merkle trees, i.e. no insertions/deletions, and this requires only updating a single branch in each parent's Merkle tree. The node being attached to/removed from does require an insertion/deletion in its Merkle tree, but this would usually happen lower down the trie, where nodes branch less, and Merkle tree rebalancing is faster.
Ahh, excellent point. On that note, isn't it actually 15 hashes per full merkle tree of 256 nodes? Because you need not only the straight branch from root to leaf, but also the brothers of each of those nodes so you can confirm. Though, it's still dramatically less than sending all 256, and makes the bandwidth requirements of this structure much more pleasant. Edit: You should name this beautiful thing, cause "hybrid PATRICIA/de la Brandais trie with authenticating Merkle trees" doesn't exactly roll off the tongue How about the "Reiner Tree"?  It's funny you asked that, because the other day my dad was asking me if I have any part of Bitcoin named after me, yet... |
|
|
|
I was thinking that to reduce the number of hashes a lightweight client would need to download when proving inclusion, you could replace the concatenation of the children's values in the formula for the value of branch node B with their Merkle root. Then a lightweight client would only need log2(256) = 8 hashes per node to prove inclusion in the worst case scenario, instead of 256.
The downside is having to store more hashes (twice as many, worst case), but it actually appears to make updates faster, I guess due to fewer hashes needing to be accessed from memory. This is because all node values updated during insertion/deletion/leaf update, except the one being attached to or removed from, have only a single leaf in the Merkle tree updated => no unbalancing issues, and only a single Merkle branch needs to be updated.
That's a very good idea, as I've been concerned about how to reduce the number of hashes that need to be transferred for a lite-node to get its balance. I had spent some time looking for "associative" hashing functions. If they existed, the transfers would be tiny: if a node is known to have Hash(A|B|C|D|E|F|G|H|I|J), and you want to prove inclusion of G, you simply supply {Hash(A|B|C|D|E|F), G, Hash(H|I|J)}. So you would need to transfer at most 3 hashes per level. Unfortunately, the only associative hash function I found was based on matrix multiplications, and was most definitely not cryptographically secure  So, I welcome the idea of per-node merkle trees. I wonder if the trees really need to be stored, though. Hashing is so fast that recomputing the merkle tree on-demand may be fine, especially for the sparse, lower-level nodes. Of course, the top couple levels could/should be cached since they'll get hit all the time and are pretty dense. However, I'm not sure if I agree/understand the point about updating only Merkle branches. Because the linked-lists at each node in the tree are sorted, the deletion/insertion of a node is likely to occur in the middle of the list and reverse the parity/pairings -- i.e. you started with {A,C, D,H, J,M, Q,Y} -- the bottom level pairs (A,C), (D,H), (J,M) and (Q,Y). Now, you insert E and the list now looks like: {A,C D,E, H,J, M,Q, Y,Y} which means that all branches to the right of the insertion or deletion need to be recalculated. On the other hand, you may be recomputing sparse nodes all the time, anyway (meaning this recomputation will happen regardless), and the dense higher-level nodes could be batch-updated -- you know that a given block is going to modify 77 of your 256 branches at the top level, so you don't need to recompute the tree until you have all 77 children are complete. That's an interesting paper, though I have trouble envisioning how they could be made deterministic for the purposes of authenticated structures. Maybe I just need to read the paper a little closer. Unfortunately, it's late so I will have to come back to this, later. |
|
|
|
In this thread Peter posted a link to some experimental pre-0.8 builds on his server. That's what I'm running. Block data files are now ~128MB, numbered blk000X.dat, and in the .bitcoin/blocks folder. Other than that, I'm not sure what changed. Yeah, I know what they said it was changing to, that's where this function came from: findLatestBlkFiles(). It should default to looking for blocks/blk0000X.dat, and if those aren't there, switch to blk000X.dat. It's really annoying that the old version is 4 digits and 1-indexed, the new version is 5 digits and zero-indexed (accommodating both versions is ugly, oh well.) Thanks for the link. I'll dig in when I get some time after RAM reduction (which is going mediocre at the moment, but I may have something worth testing in the next week or two). |
|
|
|
SOB! I even moved my blk files around to test this before committing the upgrade to beta. If this truly is broken, I need to fix that, because I was under the assumption that this should coast users through the 0.8 upgrade.
And given those errors you report, looks like it may be more than renaming block files. Perhaps they changed the way data is written, too...? Gah! I guess I need to just download 0.8 and test it myself...
Sorry, I might not have been clear. It reads the files, but when it gets to the "end" of one, it throws this error a bunch (random amount?), before it starts reading the next. However, it does seem like maybe once it catches up, Armory doesn't update when new blocks come in when connected to a 0.8 node. Is there a compiled version of 0.8, or do I have to build it myself? All my updates for 0.8 were based on the assumption that nothing is changing except for the locations and names of the block files. At least, that's all the core developers told me about |
|
|
|
edit... I found a bug (or two). If you're running the LevelDB version of Bitcoin, Armory won't go online if the blk00*.dat files don't exist, even if the blocks/blk000*.dat files do. Also, I saw a lot of this ***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data... at what I am assuming is the end of a block data file, before the next one begins scanning. It can last for quite a few seconds sometimes, churning those out 10 per seconds or so. SOB! I even moved my blk files around to test this before committing the upgrade to beta. If this truly is broken, I need to fix that, because I was under the assumption that this should coast users through the 0.8 upgrade. And given those errors you report, looks like it may be more than renaming block files. Perhaps they changed the way data is written, too...? Gah! I guess I need to just download 0.8 and test it myself... |
|
|
|
I'm really excited!
After considering the criticism of my Armory Pi setup, I spent the day learning serial ports, (more) python, and Armory. I'll release the codes tomorrow, but my solution is pretty sweet. I disabled the serial terminal and replaced it with a program that listens for unsigned transactions. When it sees one, it unlocks the wallet with the passphrase entered on the Pi's own keyboard, signs the transaction, and sends it back over the serial port. The other modification is to Armory, specifically the first offline transaction screen. Along with "Save as file" and "Copy to clipboard" options, there is now a "Transmit over serial" button, which does just what it seems. When it receives the signed transaction back, it automatically advances to and fills the text box on the transaction broadcast screen.
All this required surprisingly little code, but I need some sleep right now!
Yes! I agree this is an excellent solution -- one that I very much wanted to implement myself, but decided could not be promoted as a general solution -- due to the risk of users not disabling terminal logins via serial (thus, actually decreasing security for a number of impatient/inattentive users). But, I always wanted such a solution that could be documented on the website as "Use at your own risk, but it's a pretty sweet solution if you do it right...". I would personally use this, I just never got around to implementing a serial protocol. I suppose, alternatively, I could find a way to make an Armory offline bundle DVD -- with OS and everything preconfigured correctly for this purpose. Then the serial solution would be perfect Until then, I will graciously accept the modifications to Armory as a side-branch, or maybe a diff file or something that can be downloaded/distributed separately. Put instructions on the website with appropriate warnings. |
|
|
|
Oh, a timelock! I like that idea! :-)
"Dear heir. It seems like I was hit by a bus. Sorry. Please search long enough to find the right five-letter password for a little surprise."
I actually had thought about that for the Android phone encryption -- the phone will be slow, and I don't want to drain the battery by using some crazy long key stretching. But even a "weak" key stretching will give you enough time to move the coins before someone could reasonably brute force it (24H, if they're good) Maybe that's a good compromise. It would also go along with the idea of having an encrypted test phrase with the wallet, so you outsource the brute-forcing without give them access to the wallet directly (you give them test-encrypted data, they can prove when they've found the encrypted passphrase by giving you the decrypted data/string, but they can't take your coins until you work out an arrangement with them to exchange passphrase for BTC) |
|
|
|
I also googled the error and came to a conclusion I was missing MSVC++ but I downloaded the 2010 redistributable. I got the 2008 and it works, thanks!
Wow, I can't believe that worked! I only suggested 2008 because I compile with MS Visual Studio 2008, so it seemed like a natural fit. But... (1) I don't know why 2010 wouldn't work (2) I don't know why that fixed it, since most users don't have the redistributable installed yet Armory still works on their system...!?! Bizarre. But I'm glad it works! I'll add that to my list of things to recommend for Windows users with problems running Armory! I just got an error. I have one adress with two tx inside (= I sent 1 and 2 bitcoins there). Trying to send the whole sum of one of the input transactions (2 bitcoins), Armory wants to send fees. I accept sending fees, and tell Armory to send the remaining back to the same adress. Result: SelectCoins returned a list of size zero. This is problematic and probably not your fault. There are a dozen ways to avoid this, as a user. But since you asked for testers and feedback, I will post everything here, until you ask me to use bitcoin-qt again ;-) edit: tx went through when the fee and bitcoins to be sent were smaller than one input. Gah! I thought coin-selection was really stable by now. If this happens again, and you're willing to send me your watching-only wallet, please let know. I really want to catch that error in the debugger. I've had a couple reports of this in the past year, and each time I've implemented something that fixed it for that user. I guess there's still strange conditions that can cause it... Btw, yes: this is exactly the stuff I want out of testers. There are so many conditions, and so many things that can break from just trivial-looking one-line code changes. It freaks me out even reorganize code or delete comments before a release, for fear of accidentally changing code flow and breaking seemingly-unrelated things... |
|
|
|
etotheipie, would it be possible to add the root key + chain code to the "backup individual keys" option, so it can be easily saved to a file? I would like to encrypt it with a password me/my family knows and print it out. This way if a burglar found it it wouldn't be so easy to sweep the funds. Or even better yet, have the option making an encrypted paper backup, but that would be probably much more time consuming to implement.
I've been meaning to add the root key+chaincode to the "backup individual keys" window. But I didn't have any plans to make the backups encrypted. Once you have an encrypted wallet and an encrypted backup, you effectively have a brainwallet (requiring either brain+paperdata or brain+HDDdata). And I've ranted before about this, so I'll not go on a rant this time. But the gist is this: you don't anticipate using your paper backup, potentially for 5 years. If you encrypt it, you will forget that password within 5 years, and then your backup is useless. Even if you don't forget it, you're very likely to take it to the grave with you when you get hit by a bus, and I'm sure your family would be thrilled to find evidence of $20k worth of BTC in your safety-deposit box, but no way to recover it. Yes, yes. I'm protecting users from themselves. That's what I hate about the "war on drugs" -- the difference is, I'm not going to arrest you if you encrypt it yourself I just don't want to encourage it, because then everyone will do it by default, and lots of people will lose BTC. For most Bitcoin users, 99% of the risk is virtual, not someone gaining physical access to your paper backup. Okay, so I guess I ranted about it, anyway I will add the data to the individual keys dialog. I should've put it on there from the start, anyway. If you want to encrypt it, you can save it to a file and encrypt it however your little heart desires EDIT: I just realized there could be a MINOR benefit to the encryption: "Please print out this sheet of paper and then write this code on it in permanent ink!". It would print out an encrypted copy, which would protect against malicious printers. And then the user writes the code on it so that it's not a brain-required backup, but the printer doesn't have access to it. Hmm... |
|
|
|
I just found a bug, induced by one of the last upgrades I made before beta.
Confirmed and fixed in master! Yes, it was that easy (less than 3 minutes)! If you're compiling from source, you can just do a git pull. Otherwise, it'll make it into the next release (0.87). |
|
|
|
I'm having an issue with creating/using a new address (version 0.86/Linux). I have a wallet with two addresses (neither imported). When I add a third address using Receive Bitcoins, everything seems to go fine and then I copy the address and close the wallet. I sent some BTC to that address but didn't see any acknowledgement on the main screen. I open the wallet again, and the address is gone! It was definitely there on the third line when I closed the wallet. So then I create a new address and it gives me the same address again! Whew, I thought I lost those coins. I then add the new address and see all three in the wallet again. Just to be safe, I printed out all the individual keys.
Then I close the app and restart it. The third key is gone again! I tried to import the key from the backup, and it says the key is already in the wallet. I click the Receive Bitcoins button and the same address reappears. I close the wallet and reopen it, and the address is gone again. Then, just as I am typing this, I see a transaction appear with that address on the main (Transactions) screen with one confirmation. I look in the wallet and the address is there, hopefully for good. This is the first time I have seen this sort of behavior.
This only happens when armory is reading the blockchain and you try and add an address.
Actually... I think Cryptoman is right. I just found a bug, induced by one of the last upgrades I made before beta. An extra method I added to make sure the wallet looks out far enough on newly-imported wallets happens to reduce the key list like that when Armory is restarted, IF the key does not have any tx in the blockchain yet. It definitely marks the key as "used" for this session, which causes it to show up in the address list AND prevent it from showing again when you select "Receive Bitcoins." Except that's erased on startup if the address appears to be unused. That's actually a fairly significant bug, since it may cause address re-use and is [obviously] confusing for the user (and may be confusing to have multiple payors pay the same address). Luckily this bug can be fixed in one line... For reference: the wallet-address list only shows you keys up to the latest one used, but behind the scenes it pre-calculates the next 100 for you, and watches the blockchain for those, in case another app using the wallet distributes more addresses. So that's why it tells you it's already part of your wallet -- you can't see it, but it is address #3 of 102. |
|
|
|
Redownloaded windows-all and 64 bit for good measure. Uninstalled and removed Armory as you said and reinstalled - same issue. The 64-bit obviously gave a 'not valid win32 app' error.
This is frustrating - really want to get an offline wallet going. Maybe I should man up and just use ubuntu.
While I do generally approve of Ubuntu/Linux, in general, that doesn't change the fact that the App should work on Windows XP. I'm not sure what could be causing it... Maybe try installing MSVC++ Redistributable 2008. Perhaps that will put a usable msvcp90.dll file into your system32 dir. (you can copy it into the Armory directory to be sure). I really going out on a limb, though... |
|
|
|
Installed 0.86-beta_windows_all on fresh win xp pro sp3 installation. Tried to run but get
C:\Program Files\Armory\Armory Bitcoin Client\Armory.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
Reinstalled, repaired, rebooted multiple times to no avail. Am I missing some dependencies?
Hmmm... I haven't seen that before. I might expect that if you had downloaded the 64-bit version and tried to run it on 32-bit Windows. Are you maybe running 64-bit WinXP? I wouldn't expect it to matter for "windows_all", but if so, the 64-bit version would be your friend... All "dependencies" of Armory are already included in the installer. So that shouldn't be the problem. I just downloaded the "windows_all" installer from the website on my WinXP virtual machine, and it installs and runs no problem. But mine isn't a fresh install of XP, not even close. Try manually removing the "C:\Program Files\Armory Bitcoin Client" directory. Make sure there is absolutely nothing left of it, then redownload from the website and do a fresh install. Then run it by doubleclicking on Armory.exe in that Program Files directory, directly. Just want to be extra sure you're installing and clicking the right stuff (and maybe somehow your .msi was corrupted?). If that doesn't work, I'm not sure what else I could do... EDIT: A search of the error suggests that somehow the VC++ runtime files are not present. That would be msvcp90.dll (or related). It should be copied into the application directory by the installer, but if it's not, that's the source of it the problem. |
|
|
|
STATICPYTHON += "$(DEPSDIR)/lib/libpython$(PYVER).a" ... Anyone want to help with that? I can take a look ... Looks like I already had such a function, in a previous (dumber) version of the Armory makefile. I think it would looks like this: ifneq (exists, $(shell [ -d "$(DEPSDIR)/lib/libpython$(PYVER).a" ] && echo exists ))
STATICPYTHON += "$(DEPSDIR)/lib/libpython$(PYVER).so"
else
STATICPYTHON += "$(DEPSDIR)/lib/libpython$(PYVER).a"
endif
Can someone who has the .so problem, do a fresh checkout and confirm they have the problem, then replace the (non-Darwin) STATICPYTHON line with the code above, and tell me if it works? So far, it seems that it should... I just don't have such a system where it fails to test it. If it does work, or you figure out how it needs to be modified, then I will commit to the master branch and every compiling user's life will become a tad easier... |
|
|
|
Is there an easy way to move a single private key from one wallet to another? I know I can do a backup from one wallet and then an import to another wallet, but there are a number of steps and warnings to get past, and then you have to make sure you delete the key from the source wallet. Seems like a natural fit for a wallet menu item, or maybe right click on an address and have the choice to move it to another wallet.
This would only work for imported addresses. There is no way to "remove" a deterministic address from a wallet: it's intrinsically part of the wallet. If you deal with a lot of imported addresses, this does make sense. And Armory is prepared... you may have noticed if you remove an address an re-add it, Armory will say it doesn't need to rescan, because the tx history for that addr is available already. I guess it would just be a matter of writing a single function that does both importing and deleting... |
|
|
|
I got a user overlay set up on overlays.gentoo.org, so you can use the following installation instructions to install Armory on Gentoo: Ebuilds for Armory are available in the jranvier user overlay. 1. Install the overlay using Layman: 2. Add Armory to package.keywords: echo net-p2p/armory >> /etc/portage/package.keywords 3. Install Armory: Just a question, because I don't know much about Gentoo. As might be expected, I'm uncomfortable promoting opaque installation instructions based on any particular user's efforts. I've been very hesitant even with RedEmerald's OSX solution, simply because I can't vouch for the authenticity of what is in the build scripts. In his case, I should be able to check one particular snapshot of his solution and sign it. I don't like it, but there's not any other good options Don't get me wrong, I will post your instructions, with a statement clarifying its origin. And users can take that information into account whlie deciding how to access Armory. But I bring it up, because your previous method was actually quite transparent: the .ebuild was cleartext, obviously referenced the github project, and gentoo users are going to find it trivial to copy that text into an .ebuild file and run it. This one is a lot more opaque. Is there at least a way for the user to check the .ebuild they got? |
|
|
|
So I'm finally quite happy with my offline wallet setup, and I wanted to share it with others. I have been using a Rapsberry Pi to run the offline instance of Armory. It was hooked up to my monitor through HDMI, and I had an extra keyboard around. When I wanted to perform an offline transaction, I would create it on my main computer, put it on a USB drive, plug the keyboard and USB drive into the Pi, run Armory, sign the transaction, transfer it back to the main computer, and broadcast it. Last week, I purchased a USB to TTL, and that whole process changed for the better. The cable provides power to the Pi and allows for a terminal login to the device, so I no longer need an HDMI cable, power cable, or keyboard. I merely keep it unplugged, and plug it in when I want to perform a transaction. I log in using screen (screen /dev/ttyUSB0 115200), then run this script which does the following... Opens a new file called armory.unsigned.tx in Nano, allowing me to paste in the ascii-serialized transaction Runs this script against the unsigned file If the file was signed, then display it using Less (at which point I copy it and paste into the broadcast transaction form) Shutdown the Pi I'm pretty sure that the TTY device only allows for a single login at a time, so I don't think it would be possible, and certainly not feasible, for an attacker to steal bitcoins from the Pi during the short time that it's connected to my computer. Any thoughts? Of course, I can't endorse it as a general solution, but it seems like an okay compromise for users that are knowledgeable and crave convenience. It sounds like the risks are: (1) Remembering to disconnect the cable when you're done (2) Making sure that your offline system username & password is not the same as online computer or any of the saved logins in your browser. (3) Keyloggers Keyloggers should be bolded there, because that seems like a big risk. Once a keylogger gets your username and password, it would only take a couple seconds to login and fetch the wallet file. I guess, if you kept the wallet file in some non-standard location, such automated attacks wouldn't be so clean. Although, if your wallet encryption password is further different than online, offline, and all your browser-saved passwords, then this is considerably safer than an encrypted online wallet. If the encryption password is unique, then the encryption would really shine, as there's no real way to get that password from the host system (I assume you still have to explicitly type your password on the offline computer, not through the terminal... and assuming they didn't get a keylogger onto the offline machine, synchronized with the data transfer). Their only choice would be to brute force it, and that would take a very long time with the default key-stretching parameters. But depending on how much BTC you hold and/or how paranoid you are, this could be a reasonable solution. |
|
|
|
No problem, I understand. Is there something you can do about the sorting though? I have a transaction I need to find, but I have no way to find it without sorting the columns unless I go through each transaction in each wallet individually. Maybe have the ability to turn off pagination and use the old method until such time as there is a viable solution? I guess I could just revert to an earlier version if need be.
For now, I would just use an earlier version (for when you need to do this). Since this qualifies as an "incomplete" feature (since I started the upgrade, but didn't finish it), I'll make it a priority to fix it in the near future. |
|
|
|
- Store the visual transaction records in an array for each page when the page is up, and sort by columns from the visual record, instead of taking the record directly from the Armory DB. So you would pull the records for that page into memory and just manipulate it as if it were all text.
By the way, if you change address comments, I want the ledger to update all the address-relevant transactions appropriately. That's why I prefer it be dynamic. On a related note, how do I make transaction specific comments? That would be really handy, I didn't know that was a feature. Anytime I edit a comment, it seems to be tied to the address not the transaction.
If you double-click on the comment field in the ledger, it will set the comment just for that tx. Same with the address list in the wallet properties. If you double click any other field, it will show you the transaction details (or address properties). Maybe I should add a button to the tx details dialog to let you change the comment right there, for those that didn't notice the comment updating directly. I have had a few requests for a search function. It makes a lot of sense, so I will consider that for the next round of updates (it shouldn't be hard). I've had instances where I want to edit all comments associated with an address and instances where I just want to modify one transactions comments. Maybe make a button that "Apply to all" or "Apply here" or something... then if they click Apply to All, update the DB ledger for all entries... I'm not sure I see the advantage of having a dynamic ledger when you are viewing it in a page by page scenario... can't you still update the ledger entrie(s) if it's not on the current page? You get a very similar behavior by just setting address comments, and then they will be displayed with all transactions on the ledger. If you manually specify a comment for one of those transactions, that will be displayed instead of the address comments. If I understand you correctly, that's 90% of what you were looking for (besides sorting). However, there is currently no way to force all tx for a given address to a given string, such that it would overwrite any explicit tx comments. Right now, if you set a tx comment manually, it will always show that comment until you explicitly change it (but if you make it an empty string, it will be shown with the address comment) If I spent some time with it, I'm sure I could come up with a better way to make this work the way you would expect it to. I just put it on my TODO list |
|
|
|
|
Show Posts
