etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 12:39:45 AM |
|
Seems to me Armory could supplant the orginal bitcoin client. I like how you run tests in addition to providing all of these features. I don't know how to compile but I will test this.
Honestly, Bitcoin is so complicated under-the-hood, that development becomes quickly overwhelming unless you have a good setup for isolating pieces and testing them individually. It's completely worth the time investment to make an exhaustive unit-testing suite to help figure out what new bugs you're always introducing (accidentally), and verify that things still work as expected. Even with the tests, it can be extraordinarily frustrating to find problems, which seem to be reflected in many places at once. Maybe this is one reason why so few people have succeeded at making such a client: there have been multiple times I wanted to give up... And now that I've been using all the features, myself, it's time to see how other people can break the software. I probably haven't accounted for all the different strange combinations of behaviors of the users... and I'd like to catch that pre-alpha before people inevitably start using it with real money (which I don't recommend yet, but I know it will happen)
|
|
|
|
Red Emerald
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 01:49:26 AM |
|
Unit testing is a PITA. I commend your work. Once I get it running, I'll send a donation ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 06:31:48 AM |
|
Build instructions have been posted! (see the bottom of the top/original post) I'm sure people will still have problems. But that's why this is the testing phase and not the release phase ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) I'll move everything into the master branch and create executables, when I do the first official release. Until then, everything is in the qtdev branch, and being a tester requires compiling. Zero-confirmation transactions are so badly botched, I've disabled them, but they can be re-enabled through the menu options. Just don't be surprised if you see wacky stuff... Anything with 1+ confirmations will be accurate. My first priority before release is to get rid of the terrible zero-conf hack, and replace it with the "correct" solution. That's my task for this weekend... As stated before: this is pre-alpha. Do not put any money into this program unless you expect to lose it! Therefore, Armory defaults to testnet. If you really want to try it with real money (because you don't feel like waiting for testnet to download), you can run it via "python ArmoryQt.py --mainnet" ... but I only say that because I know someone will insist on it despite all my warnings/pleadings not to do it!
|
|
|
|
ThomasV
Legendary
Offline
Activity: 1896
Merit: 1353
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 06:43:31 AM |
|
Someone suggested that deterministic wallets shoud try to use a standard key generation algorithm. https://bitcointalk.org/index.php?topic=58436.msg688099#msg688099Since you have not released the initial version, may I suggest to use the same key generation algorithm that is already used in Electrum? This would allow users to use the same seed in both clients. see http://ecdsa.org/electrumIt is much more difficult to change this after you have released your software.
|
Electrum: the convenience of a web wallet, without the risks
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 03:26:50 PM |
|
Someone suggested that deterministic wallets shoud try to use a standard key generation algorithm. https://bitcointalk.org/index.php?topic=58436.msg688099#msg688099Since you have not released the initial version, may I suggest to use the same key generation algorithm that is already used in Electrum? This would allow users to use the same seed in both clients. see http://ecdsa.org/electrumIt is much more difficult to change this after you have released your software. Luckily, I have made sure I have a separate version number just for wallets, so I can do exactly what you suggest. Obviously, if I upgraded, old wallets would not be convertable but would still work. Only new wallets would be transferable, which is fine... (users can upgrade if they want it). However, I'm not clear what your deterministic algorithm is...? Do you use the DHSS method that allows you to compute the deterministic addresses without the private keys? I have been looking at the Electrum website, but didn't see how it is done. So far I haven't seen anyone else implement the determinism this way, and thus I would have no choice but to use my own method. Armory is critically dependent on the ability of watching-only wallets to be able to generate the public key chain without needing private keys. For reference, the algorithm I use is not terribly complicated. The 32-byte "chaincode" is kept with the wallet (and actually stored with each key in the wallet). You chain addresses via: a = hash256(PubKey65(i)) XOR chaincode PrivKey(i+1) = a*PrivKey(i) The magic is in the ECC math, so you can continue the chain with public keys only: a = hash256(PubKey65(i)) XOR chaincode PubKey(i+1) = EC_Multiply(a, PubKey(i)) The chaincode is simply extra entropy added to the determinism (i.e. salt), but not entirely necessary. I might revert, in the future, to making the chiancode deterministically generated from the root private key, so that you only need 256 bits (root private key) to recover the wallet, not 512 bits. Btw, I really like your technique for converting entropy into dictionary words. That's pretty slick! I never considered the possibility that a user would try to memorize their keys, or even write it down by hand, but that certainly makes it possible! (because I will never generate a wallet with less than 256 bits of entropy, that's a lot of write/memorize).
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 03:41:46 PM |
|
SORRY if anyone tried to checkout and compile on Windows. I updated the MSVS 2005 projects, but forgot to commit-and-push the changes. D'oh! I just pushed them to the qtdev branch, so it should go a lot smoother now. Sorry about that!
|
|
|
|
ThomasV
Legendary
Offline
Activity: 1896
Merit: 1353
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 04:09:48 PM |
|
However, I'm not clear what your deterministic algorithm is...? Do you use the DHSS method that allows you to compute the deterministic addresses without the private keys? I have been looking at the Electrum website, but didn't see how it is done. So far I haven't seen anyone else implement the determinism this way, and thus I would have no choice but to use my own method. Armory is critically dependent on the ability of watching-only wallets to be able to generate the public key chain without needing private keys.
I use the method described by gmaxwell, that he called "type 2 wallet". This method allows to generate the public key sequence without the private keys, so I guess it the same as what you describe. Note that the same method is used in BCCAPI as well. I use two separate sequences: one for receiving addresses, one for change addresses. The wallet recovery procedure stops when it finds a sequence of N consecutive unused addresses (default is N=5); during normal operations, the software never allows the user to create gaps larger than N. By default, the software generates seeds that have 128 bits of entropy. However, this is not strictly enforced; users may use longer seeds. The master private key is derived from the seed using hash based key stretching. I do not use the password as salt because I want users to be able to modify their password.
|
Electrum: the convenience of a web wallet, without the risks
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 04:18:29 PM |
|
However, I'm not clear what your deterministic algorithm is...? Do you use the DHSS method that allows you to compute the deterministic addresses without the private keys? I have been looking at the Electrum website, but didn't see how it is done. So far I haven't seen anyone else implement the determinism this way, and thus I would have no choice but to use my own method. Armory is critically dependent on the ability of watching-only wallets to be able to generate the public key chain without needing private keys.
I use the method described by gmaxwell, that he called "type 2 wallet". This method allows to generate the public key sequence without the private keys, so I guess it the same as what you describe. Note that the same method is used in BCCAPI as well. I use two separate sequences: one for receiving addresses, one for change addresses. The wallet recovery procedure stops when it finds a sequence of N consecutive unused addresses (default is N=5) By default, the software generates seeds that have 128 bits of entropy. However, this is not strictly enforced; users may use longer seeds. The master private key is derived from the seed using hash based key stretching. I do not use the password as salt because I want users to be able to modify their password. Okay, we're doing the same thing, then, just with different algorithms. The only real difference is that, in Armory, the master key is randomly generated, and then the passphrase is passed through a scrypt-like KDF to get the encryption key. If the user changes their passphrase, then everything is unencrypted and reencrypted with the new KDF-derived encryption key. In Armory, I don't keep a separate chain for change addresses. I simply "get next unused address" for change. And while I had to battle the question of how far out to extend the chain beyond that last seen address, I believe 5 is way too small. I use 100 which may be too large, but I'd much rather err on the high end than vice versa. You only need the user to generate a couple addresses that end up not being used, before your wallet will get stuck. But you do have it as an adjustable parameter, so it's easy enough for you to change if you determine it's a problem. You can either post here, or send me a PM, the specifics of your deterministic algorithm. I will consider switching the wallet to that format, as long as there is enough "standardization" around the algorithm -- it sounds like there is, if electrum and BCCAPI are both using it. Any other clients with deterministic wallets? I haven't been following other clients too much, because I've been completely consumed getting mine into a releasable state...
|
|
|
|
|
N.Z.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 09:15:16 PM |
|
Looks just great. Do you plan to add proxy/socks feature? Or maybe I missed something and can`t find where to set this up.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 09:20:01 PM |
|
Looks just great. Do you plan to add proxy/socks feature? Or maybe I missed something and can`t find where to set this up.
That's a very good question. I'm not familiar with that aspect of networking (in general) to know how much effort that would take. Perhaps someone else on the forums can reply to the following naive answer: Right now, Armory does all of its communication to the Bitcoin network through the Satoshi client. Perhaps, if you set up the Satoshi client to go through a proxy, then you will get the benefit of having done that in Armory. This assumes that you can still execute a localhost connection to the Satoshi client while it is using the proxy.
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 11:04:25 PM |
|
Looks just great. Do you plan to add proxy/socks feature? Or maybe I missed something and can`t find where to set this up.
That's a very good question. I'm not familiar with that aspect of networking (in general) to know how much effort that would take. Perhaps someone else on the forums can reply to the following naive answer: Right now, Armory does all of its communication to the Bitcoin network through the Satoshi client. Perhaps, if you set up the Satoshi client to go through a proxy, then you will get the benefit of having done that in Armory. This assumes that you can still execute a localhost connection to the Satoshi client while it is using the proxy. # proxychains ./armory_executable
will probably work well on most Linux/BSD/UNIX-like systems. http://proxychains.sf.net/If it even works with SSH (checked myself), it should work with most of apps.
|
|
|
|
N.Z.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 11:24:17 PM |
|
Armory does all of its communication to the Bitcoin network through the Satoshi client Will that be changed in future releases? # proxychains ./armory_executable That could leak some info that doesn`t respect for some reason proxychains, such as DNS requests. Also, proxychains is outdated and unmaintained since 2006. I suggest using torsocks instead if you want Tor support without building proxy chains. Anyway, native proxy support is better than third-party soft, and, finally, as you mentioned, that will not work in Win and Mac.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 13, 2012, 11:36:23 PM |
|
Armory does all of its communication to the Bitcoin network through the Satoshi client Will that be changed in future releases? # proxychains ./armory_executable That could leak some info that doesn`t respect for some reason proxychains, such as DNS requests. Also, proxychains is outdated and unmaintained since 2006. I suggest using torsocks instead if you want Tor support without building proxy chains. Anyway, native proxy support is better than third-party soft, and, finally, as you mentioned, that will not work in Win and Mac. The two major upgrades between now and beta will be (1) Reverting to file-based blockchain operations (to bring memory req'ts from 1.5 GB to 100 MB) (2) Make Armory networking-independent For the first release, I decided to go through the Satoshi client, so that it will handle all the complicated networking protocols and full-validation of incoming transactions. By running Armory through Satoshi, I get all that for free! I will add proxies to my list of features to support in the future!
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 14, 2012, 12:05:52 AM |
|
Armory does all of its communication to the Bitcoin network through the Satoshi client Will that be changed in future releases? # proxychains ./armory_executable That could leak some info that doesn`t respect for some reason proxychains, such as DNS requests. Untrue. Proxychains actually proxies DNS through its chains ! It also works well with TOR (also tested myself). This fancy thing even works with advanced apps (GUI apps).
|
|
|
|
nikileshsa
Newbie
Offline
Activity: 7
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 15, 2012, 12:19:17 AM |
|
good work. I am willing to participate in alpha testing
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 15, 2012, 12:34:03 AM |
|
good work. I am willing to participate in alpha testing
Great! Build instructions are posted here. If you're in Windows, you'll need some patience. Let me know if the build instructions aren't clear enough, or need any corrections! -Eto
|
|
|
|
ctoon6
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2012, 03:50:42 AM |
|
will this client ever get arm support? i ask because i want to buy a raspberry pi, and that runs arm.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2012, 05:03:39 AM |
|
will this client ever get arm support? i ask because i want to buy a raspberry pi, and that runs arm.
Ctoon, It'll be a while before Armory will be lite-enough to work on such light-weight hardware. However, the beauty of the offline transactions technique (based on BIP 0010) would make it feasible to use very inexpensive hardware solely for signing offline transactions (because you don't need the blockchain, you only need to be able to run ECDSA code). But I don't think I'll be doing that... I just don't have the experience with alternative architectures. But again, my stuff is open source, BIP 0010 is public, and my wallet files are well-documented. I bet someone more-suited for the job could make it happen and I'd be happy to help them. I am excited about the possibility of the offline tx technique to enable super-light-weight, inexpensive, signing devices that could be used for two-factor-authentication-like scheme. But full Armory might be a stretch.
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2012, 10:34:58 AM |
|
|
|
|
|
|