http://bitcoinarmory.com/ seems to be down.
I'm still getting the error of "SelectCoins returned a list of size zero. This is problematic and probably not your fault." but only if I set the transaction fee to 0.00 and let Armory tell me that a transaction fee is required and correct it for me. If I set the transaction fee to 0.0005 before trying to send the error doesn't happen.
Thanks.
Topic: Armory - Discussion Thread - page 177. (Read 521749 times)
i have the following problem with armory:
i have a wallet with 3 keys and a small amount (0.078872) of bitcoins. i want to send them, i chose an amount 0.078372 which should empty the wallet minus fees. this fails, armory tells me this exceeds my balance (which in itself is not true) then the tx fee is increased to 0.001.
i adjust the amount to 0.077872 then i get the "confirm transaction" but the button "continue" does not actually send anything or even close the window "send bitcoins"
also sending other smaller amounts out of this wallet fails.
i have a wallet with 3 keys and a small amount (0.078872) of bitcoins. i want to send them, i chose an amount 0.078372 which should empty the wallet minus fees. this fails, armory tells me this exceeds my balance (which in itself is not true) then the tx fee is increased to 0.001.
i adjust the amount to 0.077872 then i get the "confirm transaction" but the button "continue" does not actually send anything or even close the window "send bitcoins"
also sending other smaller amounts out of this wallet fails.
Hi,
Today I tried to send a payment but am getting the error "SelectCoins returned a list of size zero. This is problematic and probably not your fault.".
I've tried restarting Armory and the Satoshi client several times but the error persists.
Today I tried to send a payment but am getting the error "SelectCoins returned a list of size zero. This is problematic and probably not your fault.".
I've tried restarting Armory and the Satoshi client several times but the error persists.
FYI, I found the bug causing this. It was pretty obvious once the debugger got there. It only triggers when you try to create a transaction using inputs that are smaller than the transaction fee (and a few other conditions).
I just fixed it, and also put in dooglus' fix for the blockchain loading (which I now understand to be re-opening the file after scanning... I misread it the first time). I have a little bit of testing to do, then will re-release it as 0.82.2. Since the changes are really trivial and amount to only a couple lines of code (since the last testing release), I'll only request testing for a day, and then make an "official" release tomorrow barring anything stupid.
Given that I've been out of town and thinking about other things, is there anything I've forgotten? There's still some periodic crashes after running for a while. But beyond that, I'm not aware of anything critical I need to address in the near future (besides another SelectCoins bug that is even more rare). Please let me know if I missed your concern!
I figured, maybe the system remembers what files you access frequently and pre-caches them on load. I guess not...
It can, if you use something like preload (but it is not the Linux kernel itself that does that).
(2) At least in Linux, the caching seems to hold between boots -- not perfectly, but I just tested it on my laptop and it scanned in 30s after a reboot. The only way I can get it up to two minutes is to do an explicit cache dump (gmaxwell pointed out that "echo 3 > /proc/sys/vm/drop_caches" does exactly that).
Caching does not hold between boots at all. But by dropping the caches using drop_caches, you are also probably dropping a lot of pages belonging to the libc and other shared libraries, which puts you into a worse situation than when running armory for the first time after boot if other applications have been started before it: those applications have probably already loaded some of the shared libraries pages you will need.
Okay. Then at worst, it runs at the same speed as the current Armory utilities in Linux, and twice as fast once it's been cached. I'll have to do the same tests on a native Windows system.
I figured, maybe the system remembers what files you access frequently and pre-caches them on load. I guess not...
(2) At least in Linux, the caching seems to hold between boots -- not perfectly, but I just tested it on my laptop and it scanned in 30s after a reboot. The only way I can get it up to two minutes is to do an explicit cache dump (gmaxwell pointed out that "echo 3 > /proc/sys/vm/drop_caches" does exactly that).
Caching does not hold between boots at all. But by dropping the caches using drop_caches, you are also probably dropping a lot of pages belonging to the libc and other shared libraries, which puts you into a worse situation than when running armory for the first time after boot if other applications have been started before it: those applications have probably already loaded some of the shared libraries pages you will need.
Hey, just a suggestion, it would be nice to create an armory wallet watcher for Android.
Yes! This is in my plans. I was hoping to implement multi-sig and then create an android app that lets you use your phone as a two-factor authentication device. However, a lot of other priorities have come up, and the wallet file needs to be upgraded, so I haven't been able to pursue this just yet. But I will! It was intended to be one of the core Armory features!
You're welcome.
Actually the change as you describe it is not what I intended. I meant to reopen each file after it was scanned, not before. Isn't that what my change does?
All I'm aiming to do is to have the fileSizes_ array contain the sizes as they were actually read, not the sizes as they happened to be when the files were originally opened. Because when the stored filesizes value is smaller than the amount that was actually read, that's when the crash happens.
Actually the change as you describe it is not what I intended. I meant to reopen each file after it was scanned, not before. Isn't that what my change does?
All I'm aiming to do is to have the fileSizes_ array contain the sizes as they were actually read, not the sizes as they happened to be when the files were originally opened. Because when the stored filesizes value is smaller than the amount that was actually read, that's when the crash happens.
Oh I must've misread the patch you posted. And I must've misunderstood how the file reading/opening works. I thought that even if the file changed size, that once it's open for reading it would be limited to that size until you explicitly reload it. And because I wasn't sure about that, I stored/used the file sizes when it opened to try to avoid exactly what you said it's doing. But clearly I botched something...
I just got back from vacation, and I need to get my life back into order. But I'll be digging in hard, soon!
OneEyed, thanks for the feedback on this. Admittedly, I hadn't considered all the other perspectives on the changes I proposed. I know what I want out of Armory, but that is frequently at odds with others (who use it in different ways than me).
That's a hell of a "can't you?" statement. It could take me months to implement the networking protocol, and in the end, Armory would end up worse off (with a buggy, security-untested networking engine). However, this is one steps towards that Armory-full-node goal, which may include cannabilizing another networking engine (maybe directly from bitcoind) to integrate into Armory (which is still a hardcore modification of the software). So, there is a transient period where both processes would need it. On the other hand:
There's two things you missed here:
(1) Users would no longer be reading the entire blockchain on start. They'd be reading a tiny database that would load instantly. This scan time would only be relevant on first load (ever) and re-scans when importing addresses/wallets.
(2) At least in Linux, the caching seems to hold between boots -- not perfectly, but I just tested it on my laptop and it scanned in 30s after a reboot. The only way I can get it up to two minutes is to do an explicit cache dump (gmaxwell pointed out that "echo 3 > /proc/sys/vm/drop_caches" does exactly that).
If you are going to store the blockchain data, can't you replace bitcoind by incorporating the networking code directly into Armory? Once you handle the blockchain in armory, it makes little sense to keep a copy of the blockchain in bitcoind, since it will have no use.
That's a hell of a "can't you?" statement. It could take me months to implement the networking protocol, and in the end, Armory would end up worse off (with a buggy, security-untested networking engine). However, this is one steps towards that Armory-full-node goal, which may include cannabilizing another networking engine (maybe directly from bitcoind) to integrate into Armory (which is still a hardcore modification of the software). So, there is a transient period where both processes would need it. On the other hand:
- RAM usage is going to become nil. Relying entirely on a disk-based DB engine means that it will work well on systems with lot of RAM that can do lots of caching, but it won't need it.
- You will be able to connect to any (trusted) full node, just not localhost and not just bitcoind/-qt. That means you could have one bitcoind on your network, and all your systems can connect to it.
- This paves the way for making a lite-version of Armory which doesn't need the full blockchain at all. i.e. you can run your full bitcoind/-qt and Armory will only get the wallet-relevant information it needs. It wouldn't actually copy the entire blockchain. This isn't ready yet, but it's most definitely on my path to verison 1.0. The end result would be a lot more stability and flexibility, with pretty much the same disk usage as right now.
- Although I don't really like the idea much, it would be possible for people to start services supplying the trusted full node for you.
- This paves the way for pruned-full-node and/or pruned-lite-node Armory, and implementing my own version of Ultimate Blockchain compression. If this eventually gets me to a system like that, then everyone wins.
The benchmark with cached data has no meaning. People don't stop and start armory all the time, the empty-cache case is the interesting one.
...
Well, right now, one of the strong points in Armory is that it takes only 700k extra data in my home directory. If it now takes 3.1G (as bitcoind does), that's bad. And I'd be interested in looking at the cold cache startup time, as this is the one that will appear in benchmarks.
...
Well, right now, one of the strong points in Armory is that it takes only 700k extra data in my home directory. If it now takes 3.1G (as bitcoind does), that's bad. And I'd be interested in looking at the cold cache startup time, as this is the one that will appear in benchmarks.
There's two things you missed here:
(1) Users would no longer be reading the entire blockchain on start. They'd be reading a tiny database that would load instantly. This scan time would only be relevant on first load (ever) and re-scans when importing addresses/wallets.
(2) At least in Linux, the caching seems to hold between boots -- not perfectly, but I just tested it on my laptop and it scanned in 30s after a reboot. The only way I can get it up to two minutes is to do an explicit cache dump (gmaxwell pointed out that "echo 3 > /proc/sys/vm/drop_caches" does exactly that).
FYI -- while I had downtime on vacation, I started playing around with LevelDB. I think I decided that changing the engine to maintain its own blockchain using leveldb is not only going to be extremely useful, but not terribly difficult either (the last round of blockchain engine updates properly modularized the blockchain management from the rest of the program).
--First and foremost, all these crashing issues can go away: I'm pretty sure they're related to "hacking" my way through the blk000X.dat files which are being maintained by another process out of my control (that's not to say I did it right or that it can't work, but it seems like an unnecessary situation).
--This also will allow users to connected to any full node, as long as it is 100% trusted -- it doesn't have to be localhost. The downside is, if it is localhost, you'll be maintaining two copies of the blockchain.
--First and foremost, all these crashing issues can go away: I'm pretty sure they're related to "hacking" my way through the blk000X.dat files which are being maintained by another process out of my control (that's not to say I did it right or that it can't work, but it seems like an unnecessary situation).
--This also will allow users to connected to any full node, as long as it is 100% trusted -- it doesn't have to be localhost. The downside is, if it is localhost, you'll be maintaining two copies of the blockchain.
That seems like an important downside to me. If you are going to store the blockchain data, can't you replace bitcoind by incorporating the networking code directly into Armory? Once you handle the blockchain in armory, it makes little sense to keep a copy of the blockchain in bitcoind, since it will have no use.
--Faster! The benchmarks I ran showed that a full scan can be done in like 15s even on a non-SSD. Granted, that's when much of the file is cached by the OS already -- but it's still faster than what I've got right now which also should benefit from OS caching.
The benchmark with cached data has no meaning. People don't stop and start armory all the time, the empty-cache case is the interesting one.
I know I keep pushing back beta -- but it's for a good reason: I think Beta is going to get a lot of attention, and I don't want 5 minute load-times and 700 MB RAM usage to be the focal point of the discussions/reviews. I think I can get all this implemented in a couple weeks, then a couple more weeks of testing. Then a few of Armory's achilles heels will be gone!
Well, right now, one of the strong points in Armory is that it takes only 700k extra data in my home directory. If it now takes 3.1G (as bitcoind does), that's bad. And I'd be interested in looking at the cold cache startup time, as this is the one that will appear in benchmarks.
The Armory GUI isn't completely visible on my 7-inch eeepc (for offline wallet). I can work around it sorta but it might be nice to have a scrollbar or something.
You can't resize the window? Are there windows that can't be made small enough? For a while, this was an issue and I thought I had fixed it. But I guess not.
Let me know what windows are problematic, I'll be sure to make the resizing & layouts more flexible.
I've also found the "Transaction Info" window can't be resized, makes it very difficult to see all the outputs for a transaction. Having this window resizeable would be great.
Alright, I'll spend some time playing with Armory in a VM with 1024x600 resolution. I'm sure the issues will pop out.
I just got home from my vacation, and though my work-work is still going to be kind of intense, I will finally have some time to do real development again! The first thing will be to dig into the SelectCoins problem with the watching-only wallet I have. I will also inject Dooglus' blockchain utilities fix. I don't think it's going to fix the periodic crashes (once Armory is running), but it should make sure the scan works. Then I will release 0.82.2.
FYI -- while I had downtime on vacation, I started playing around with LevelDB. I think I decided that changing the engine to maintain its own blockchain using leveldb is not only going to be extremely useful, but not terribly difficult either (the last round of blockchain engine updates properly modularized the blockchain management from the rest of the program).
--First and foremost, all these crashing issues can go away: I'm pretty sure they're related to "hacking" my way through the blk000X.dat files which are being maintained by another process out of my control (that's not to say I did it right or that it can't work, but it seems like an unnecessary situation).
--This also will allow users to connected to any full node, as long as it is 100% trusted -- it doesn't have to be localhost. The downside is, if it is localhost, you'll be maintaining two copies of the blockchain.
--Start times will be near instantaneous -- as long as I'm storing blockchain data, I can easily store between-load information
--The new utilities will be designed with blockchain pruning in mind (my pruning method in particular, but any method that cares about separating out unspent TxOuts and possibly removing everything else). I don't plan to implement pruning yet, but I've already figured out how I can organize the data such that it will be minimal engine modifications to implement lightweight nodes and pruned nodes.
--Faster! The benchmarks I ran showed that a full scan can be done in like 15s even on a non-SSD. Granted, that's when much of the file is cached by the OS already -- but it's still faster than what I've got right now which also should benefit from OS caching.
I know I keep pushing back beta -- but it's for a good reason: I think Beta is going to get a lot of attention, and I don't want 5 minute load-times and 700 MB RAM usage to be the focal point of the discussions/reviews. I think I can get all this implemented in a couple weeks, then a couple more weeks of testing. Then a few of Armory's achilles heels will be gone!
The Armory GUI isn't completely visible on my 7-inch eeepc (for offline wallet). I can work around it sorta but it might be nice to have a scrollbar or something.
You can't resize the window? Are there windows that can't be made small enough? For a while, this was an issue and I thought I had fixed it. But I guess not.
Let me know what windows are problematic, I'll be sure to make the resizing & layouts more flexible.
I've also found the "Transaction Info" window can't be resized, makes it very difficult to see all the outputs for a transaction. Having this window resizeable would be great.
Hi,
Today I tried to send a payment but am getting the error "SelectCoins returned a list of size zero. This is problematic and probably not your fault.".
I've tried restarting Armory and the Satoshi client several times but the error persists.
Any ideas?
Thanks
Today I tried to send a payment but am getting the error "SelectCoins returned a list of size zero. This is problematic and probably not your fault.".
I've tried restarting Armory and the Satoshi client several times but the error persists.
Any ideas?
Thanks
You are the second person to report this problem. It's strange that the SelectCoins code has been in use for 8 months and there's never been a hint of a problem with it, but suddenly multiple people run into this!
The other person who reported this sent me their wallet so I can debug it. I will dig into it tonight, and hopefully have a fix for 0.82.2, which will be an official release this week.
The other user was using a wallet that had tons of inputs, and attempting to move the entire balance in one tx, which would require a large tx fee. As such, I recommend you compute your total balance minus the requested tx fee, and put that in directly and change the fee directly to the recommended fee. There may be an issue with the fee calculation when there's dozens of inputs, but if you give it the correct answer to start it may not have an issue.
Let me know. This seems like a serious issue and I will be attending to it right away!
I've just tried again to send the payment and it worked no problem.
For the record I was trying to send BTC0.1 with a BTC0.0005 transaction fee from a wallet with BTC13.
Thanks
You are the second person to report this problem. It's strange that the SelectCoins code has been in use for 8 months and there's never been a hint of a problem with it, but suddenly multiple people run into this!
Make me the third one. I sometimes see this problem after I accept to add a fee to a transaction, but had no chance to properly report it.
Hi,
Today I tried to send a payment but am getting the error "SelectCoins returned a list of size zero. This is problematic and probably not your fault.".
I've tried restarting Armory and the Satoshi client several times but the error persists.
Any ideas?
Thanks
Today I tried to send a payment but am getting the error "SelectCoins returned a list of size zero. This is problematic and probably not your fault.".
I've tried restarting Armory and the Satoshi client several times but the error persists.
Any ideas?
Thanks
You are the second person to report this problem. It's strange that the SelectCoins code has been in use for 8 months and there's never been a hint of a problem with it, but suddenly multiple people run into this!
The other person who reported this sent me their wallet so I can debug it. I will dig into it tonight, and hopefully have a fix for 0.82.2, which will be an official release this week.
The other user was using a wallet that had tons of inputs, and attempting to move the entire balance in one tx, which would require a large tx fee. As such, I recommend you compute your total balance minus the requested tx fee, and put that in directly and change the fee directly to the recommended fee. There may be an issue with the fee calculation when there's dozens of inputs, but if you give it the correct answer to start it may not have an issue.
Let me know. This seems like a serious issue and I will be attending to it right away!
Dooglus,
You are very resourceful, thanks for helping debug the code while I'm on vacation! I still don't fully understand the issue (and why that line of code fixed it), but it's not a bad thing to reopen the file just before scanning. As it was before, blk0002.dat was being opened before blk0001.dat was scanned. Your line reopens the file just before it is scanned (and I could see why that's a good thing). The first thing I do when I get back is I'll put that fix into 0.82.1 and commit it. And then I'll release 0.82.1 because it's about time...
Seriously, thanks for helping me with this! I've been stressed that issues like this are cropping up and I've had no time to deal with it!
You are very resourceful, thanks for helping debug the code while I'm on vacation! I still don't fully understand the issue (and why that line of code fixed it), but it's not a bad thing to reopen the file just before scanning. As it was before, blk0002.dat was being opened before blk0001.dat was scanned. Your line reopens the file just before it is scanned (and I could see why that's a good thing). The first thing I do when I get back is I'll put that fix into 0.82.1 and commit it. And then I'll release 0.82.1 because it's about time...
Seriously, thanks for helping me with this! I've been stressed that issues like this are cropping up and I've had no time to deal with it!
You're welcome.
Actually the change as you describe it is not what I intended. I meant to reopen each file after it was scanned, not before. Isn't that what my change does?
All I'm aiming to do is to have the fileSizes_ array contain the sizes as they were actually read, not the sizes as they happened to be when the files were originally opened. Because when the stored filesizes value is smaller than the amount that was actually read, that's when the crash happens.
Hi,
Today I tried to send a payment but am getting the error "SelectCoins returned a list of size zero. This is problematic and probably not your fault.".
I've tried restarting Armory and the Satoshi client several times but the error persists.
Any ideas?
Thanks
Today I tried to send a payment but am getting the error "SelectCoins returned a list of size zero. This is problematic and probably not your fault.".
I've tried restarting Armory and the Satoshi client several times but the error persists.
Any ideas?
Thanks
Hey, just a suggestion, it would be nice to create an armory wallet watcher for Android.
The Armory GUI isn't completely visible on my 7-inch eeepc (for offline wallet). I can work around it sorta but it might be nice to have a scrollbar or something.
You can't resize the window? Are there windows that can't be made small enough? For a while, this was an issue and I thought I had fixed it. But I guess not.
Let me know what windows are problematic, I'll be sure to make the resizing & layouts more flexible.
The Armory GUI isn't completely visible on my 7-inch eeepc (for offline wallet). I can work around it sorta but it might be nice to have a scrollbar or something.
I think the following might fix the crash:
Code:
diff --git a/cppForSwig/BlockUtils.cpp b/cppForSwig/BlockUtils.cpp
index 2b08f5e..bf270bf 100644
--- a/cppForSwig/BlockUtils.cpp
+++ b/cppForSwig/BlockUtils.cpp
@@ -2535,6 +2535,7 @@ uint32_t BlockDataManager_FileRefs::parseEntireBlockchain( string blkdir,
bsb.reader().advance(nextBlkSize);
}
}
+ globalCache.openFile(fnum-1, blkfile);
TIMER_STOP("ScanBlockchain");
}
Since adding that line to the code I've had no further crashes. I'm pretty sure that fixes the bug. There's probably a more efficient way to get the same result than re-opening all the blockchain files, but at least I've found the problem now.
Dooglus,
You are very resourceful, thanks for helping debug the code while I'm on vacation! I still don't fully understand the issue (and why that line of code fixed it), but it's not a bad thing to reopen the file just before scanning. As it was before, blk0002.dat was being opened before blk0001.dat was scanned. Your line reopens the file just before it is scanned (and I could see why that's a good thing). The first thing I do when I get back is I'll put that fix into 0.82.1 and commit it. And then I'll release 0.82.1 because it's about time...
Seriously, thanks for helping me with this! I've been stressed that issues like this are cropping up and I've had no time to deal with it!
Jump to: