- I have drastically reduced the tracking and handling of zero-conf transactions. This solves 80% of the speed issues using Armory with wallets with 10k+ addresses. I now run with 30k addresses and it runs fine, although it freezes for about 1-3 sec after every new block. Better than 10-15 sec, though (which was causing inter-thread timeouts). I will be working on the per-block scanning ops to reduce it even further (Armory code base should be able to handle 1mil+ addresses, I just haven't optimized the operations to do it)
- Updated "Send Bitcoins" dialog, with wallet selection directly in the dialog. Coin control still works, though the interface updates for that broke. Fixing that soon.
- Added paranoid-extension of address chains and logging of multipliers. All address chain extensions are now performed twice and answers are compared to make sure it's consistent. Additionally, the final multiplier/exponent applied is logged.
- There are still situations where an unclean shutdown will induce a rescan. I have further reduced those situations, though it's not perfect. I will see if the operations are efficient enough to make more reliable.
- armoryd.py updates -- a bunch of functions that broke in the update to 0.90 have been fixed. Most importantly, "listtransactions" and "getledger" now work. CircusPeanut is working on building a better test environment for it to improve the reliability.
- Updated leveldb block size to 32kb. This seems to improve scan speed on Linux/Mac, without breaking build speed on Windows. Be sure to --rebuild if you want the benefits of the new block size.
Topic: Armory - Discussion Thread - page 77. (Read 521829 times)
Updates to 0.91-dev branch: (just pushed)
OK
After running for a couple of hours armory has failed to import my bitcoin wallet created with a bitcoin prior to 0.8.6 and later taken over by bitcoin 0.8.6. Now armory fails to import this wallet. Should I create a new wallet or try something else to import my wallet located in ~/.bitcoin?
I don't think armory is compatible with bitcoin-qt wallets. You should just create an armory wallet and send all your coins over to it.
After running for a couple of hours armory has failed to import my bitcoin wallet created with a bitcoin prior to 0.8.6 and later taken over by bitcoin 0.8.6. Now armory fails to import this wallet. Should I create a new wallet or try something else to import my wallet located in ~/.bitcoin?
Thank you gweedo
btw: Is it normal that I get different IPs for ping bitcoinarmory.com on two different internet connections? (maybe because of cloud hosting !?) Okay i just did "dig bitcoinarmory.com" and indeed these are the two ips I am getting.
cf-ssl27047-protected.bitcoinarmory.com. 133 IN A 108.162.200.154
cf-ssl27047-protected.bitcoinarmory.com. 133 IN A 141.101.127.153
btw: Is it normal that I get different IPs for ping bitcoinarmory.com on two different internet connections? (maybe because of cloud hosting !?) Okay i just did "dig bitcoinarmory.com" and indeed these are the two ips I am getting.
cf-ssl27047-protected.bitcoinarmory.com. 133 IN A 108.162.200.154
cf-ssl27047-protected.bitcoinarmory.com. 133 IN A 141.101.127.153
They use cloudflare to protect from ddos, just double check the SSL, and the GPG signed builds of armory and you will be fine.
Thank you gweedo
btw: Is it normal that I get different IPs for ping bitcoinarmory.com on two different internet connections? (maybe because of cloud hosting !?)
btw: Is it normal that I get different IPs for ping bitcoinarmory.com on two different internet connections? (maybe because of cloud hosting !?)
Could be cloudflare
Thank you gweedo
btw: Is it normal that I get different IPs for ping bitcoinarmory.com on two different internet connections? (maybe because of cloud hosting !?) Okay i just did "dig bitcoinarmory.com" and indeed these are the two ips I am getting.
cf-ssl27047-protected.bitcoinarmory.com. 133 IN A 108.162.200.154
cf-ssl27047-protected.bitcoinarmory.com. 133 IN A 141.101.127.153
btw: Is it normal that I get different IPs for ping bitcoinarmory.com on two different internet connections? (maybe because of cloud hosting !?) Okay i just did "dig bitcoinarmory.com" and indeed these are the two ips I am getting.
cf-ssl27047-protected.bitcoinarmory.com. 133 IN A 108.162.200.154
cf-ssl27047-protected.bitcoinarmory.com. 133 IN A 141.101.127.153
I thought armorys wallet is deterministic and you only need to backup it once - no matter how many new addresses you generate afterwards. Isn't it like that?
Correct it is deterministic, but a keypool is pre-generated addresses that can be used. It saves time, and has nothing to do with backup unless you change that number, then you may miss addresses when you restore, but changing that value will return those addresses.
If you used more and restore, it won't think to generate them YET. It CAN, you just tell it to.
Okay. For example: I create a new wallet with the default setting of e.g. 100 pre generated addresses. After this I am doing a backup. Now I am changing the pre generate number to 200 and get 100 new addresses. When I am reimporting my backup I will only have 100 addresses in my wallet but now I can change this number again and will have all my 200 addresses back in my wallet. Is this correct?
Correct.
I thought armorys wallet is deterministic and you only need to backup it once - no matter how many new addresses you generate afterwards. Isn't it like that?
Correct it is deterministic, but a keypool is pre-generated addresses that can be used. It saves time, and has nothing to do with backup unless you change that number, then you may miss addresses when you restore, but changing that value will return those addresses.
If you used more and restore, it won't think to generate them YET. It CAN, you just tell it to.
Okay. For example: I create a new wallet with the default setting of e.g. 100 pre generated addresses. After this I am doing a backup. Now I am changing the pre generate number to 200 and get 100 new addresses. When I am reimporting my backup I will only have 100 addresses in my wallet but now I can change this number again and will have all my 200 addresses back in my wallet. Is this correct?
I thought armorys wallet is deterministic and you only need to backup it once - no matter how many new addresses you generate afterwards. Isn't it like that?
Correct it is deterministic, but a keypool is pre-generated addresses that can be used. It saves time, and has nothing to do with backup unless you change that number, then you may miss addresses when you restore, but changing that value will return those addresses.
If you used more and restore, it won't think to generate them YET. It CAN, you just tell it to.
I thought armorys wallet is deterministic and you only need to backup it once - no matter how many new addresses you generate afterwards. Isn't it like that?
Correct it is deterministic, but a keypool is pre-generated addresses that can be used. It saves time, and has nothing to do with backup unless you change that number, then you may miss addresses when you restore, but changing that value will return those addresses.
Is it possible to somehow get a list of 1,000 pre-generated addresses of an Armory wallet?
I know I can use the "Backup Individual Keys" function and then click "Include Unused" but this will give only about 100 pre-generated addresses.
Is there a way to extend this to a 1,000 addresses?
I know I can use the "Backup Individual Keys" function and then click "Include Unused" but this will give only about 100 pre-generated addresses.
Is there a way to extend this to a 1,000 addresses?
I believe you can pass the --keypool=## option to Armory, but I've not tested if that will increase the amount when you print a backup.
I thought armorys wallet is deterministic and you only need to backup it once - no matter how many new addresses you generate afterwards. Isn't it like that?
Is the new backup center of 0.9 already safe to use?
@etotheipi, can you please put the download url, signed hashes in the opening post of this thread to let us not only rely on the website?
i've not run into that. what is secure printing?
If you print on a modern printer with a hard drive, it will save a copy of everything you print that can later be stolen when the printer is sold. So secure print gives you a code to hand write on the page you print out -- both are needed to unlock the wallet.
In Armory, a given wallet can create different paper backups (I mean, each paper backup has different set of 16 characters x two rows of character codes.) This is right ?
I ask this because after creating a first paper wallet, a few days later I wanted another copy but when creating another paper wallet for the same wallet, different codes came out.
I ask this because after creating a first paper wallet, a few days later I wanted another copy but when creating another paper wallet for the same wallet, different codes came out.
No it should be the same afaik
The seed shouldn't change
Tks for the reply.
Yikes, I would swear that i did a test and a different paper backup came up. I will re-test and report here, thanks.
Thanks for all the replies.
I re-tested again and the reason I am getting to different paper backups for the same wallet is that in the first one I checked the thing for secure printing and the second not, which explains why I am getting different codes for each of the two paper backups. All OK I presume, thanks.
i've not run into that. what is secure printing?
At least you test your backups before hand, everyone should.
In Armory, a given wallet can create different paper backups (I mean, each paper backup has different set of 16 characters x two rows of character codes.) This is right ?
I ask this because after creating a first paper wallet, a few days later I wanted another copy but when creating another paper wallet for the same wallet, different codes came out.
I ask this because after creating a first paper wallet, a few days later I wanted another copy but when creating another paper wallet for the same wallet, different codes came out.
No it should be the same afaik
The seed shouldn't change
Tks for the reply.
Yikes, I would swear that i did a test and a different paper backup came up. I will re-test and report here, thanks.
Thanks for all the replies.
I re-tested again and the reason I am getting to different paper backups for the same wallet is that in the first one I checked the thing for secure printing and the second not, which explains why I am getting different codes for each of the two paper backups. All OK I presume, thanks.
In any case, the 0.91 database changes look good.
Although the initial sync subjectively seemed a lot slower than the 0.90 version, it meant I could close the program in the middle and it would pick up again in the same spot without losing progress.
So far Armory recovers perfectly from an unclean shutdown (via kill -9).
Although the initial sync subjectively seemed a lot slower than the 0.90 version, it meant I could close the program in the middle and it would pick up again in the same spot without losing progress.
So far Armory recovers perfectly from an unclean shutdown (via kill -9).
The "synchronizing with network" (bitcoin-qt/bitcoind), and "Building databases" really won't be any faster. It's the "Scanning Blockchain" step that should be faster. It's almost double speed on Ubuntu/Linux. However, we've been having some Windows SNAFUs, so I'm not sure yet what's going on with Windows...
In any case, the 0.91 database changes look good.
Although the initial sync subjectively seemed a lot slower than the 0.90 version, it meant I could close the program in the middle and it would pick up again in the same spot without losing progress.
So far Armory recovers perfectly from an unclean shutdown (via kill -9).
Although the initial sync subjectively seemed a lot slower than the 0.90 version, it meant I could close the program in the middle and it would pick up again in the same spot without losing progress.
So far Armory recovers perfectly from an unclean shutdown (via kill -9).
On a related note, changing the name of the development branch makes keeping our ebuilds up to date particularly difficult. This kind of branching and tagging model would help us, and is probably a good idea in general: http://nvie.com/posts/a-successful-git-branching-model/
Now that we have a team, we just agreed to start naming the dev branches after the version they will become. Hence "0.91-dev" will eventually be 0.91-beta, and then we'll start 0.92-dev, etc. I know we had been inconsistent before and that's why we just decided on this.
However, I really like that link you sent. As he says, there's nothing groundbreaking, it's just a nice, consistent way to get everyone to cooperate and work the same git styles. We'll definitely discuss adopting that or something very close to it.
The "--no-ff" flag is a good tip too. I was wondering how to t avoid that information loss.
In Armory, a given wallet can create different paper backups (I mean, each paper backup has different set of 32 characters x two rows of character codes.) This is right ?
I ask this because after creating a first paper wallet, a few days later I wanted another copy but when creating another paper wallet for the same wallet, different codes came out.
I ask this because after creating a first paper wallet, a few days later I wanted another copy but when creating another paper wallet for the same wallet, different codes came out.
Use the test backup feature to make sure it works.
Jump to: