I guess what I'm trying to say, can the notification pop as it detects new transactions while it's syncing, and then let you quickly flip through the notifications.
No history is displayed during syncing. The code is built on the assumption that it won't be displaying anything to the user until the DB is ready. Changing that now would be painful, and doesn't justify the meager benefit. Is this common or something? Are you suggesting that I delete the Bitcoin Core blockchain and let the entire thing re-download?
Yes My questions:
1.) Would it be possible to import a supernode DB someone else built?
2.) If yes, would the ram requirements be signifficantly lower just to run and maintain the DB after?
3.) Are there any UI changes when running --supernode? Is there a simple way to e.g. check address balances? Or would I basically have to create a new watch only wallet, import the address and the advantage would be instant showing of balance without rescan?
1) Yes. It will need to be using the page size as your machine's native page size, so there may be some limitation from one OS to another. 2) Yes and no. The DB will access less data to update the last few blocks, but a lot of that data is spread randomly around the DB, so unless you have a SSD or tons of RAM, expect extreme updating times regardless. 3) No changes in UI yet. Any wallet or private key you import will render quasi instantly (time to compute the paged history). We had planned on adding a plugin to quick look at any address, but that was put on hold. Maybe for 0.93.1 |
|
|
|
We have someone looking at it. No ETAs, but we are working the code. |
|
|
|
Do I have to do that every time I start Armory
Yes What happens if I generate the db as a supernode and then later start Armory without the supernode flag
It won't let you |
|
|
|
I did have a question though. When I get a payment in when connected, it flashes into the little notificaton area.
That's the notification on zero conf However, when I'm syncing, going through the blocks and seeing transactions in,it's in the list, but those notifications aren't there. Is that supposed to be the way?
Not sure what you are trying to say. Can you elaborate? |
|
|
|
I think Windows has a configurable way of supplying arguments to an executable, possibly by using the properties window for the .exe you're using.
That would be the target field in a shortcut to the exe And I'd assume that Armory for Windows accepts the same command line arguments that Linux does (--datadir=<your Armory database directory> and --satoshi-datadir=<your Bitcoin database directory>).
Yes |
|
|
|
|
Chances are your copy of the blockchain is missing a bunch of blocks. You should do a factory reset.
|
|
|
|
I get the same error when trying to use coin control.
That's fixed in 0.93-bugfix |
|
|
|
This entry is marked as fixed in our bug list. |
|
|
|
|
force the datadir to something else with --datadir="*newpath*"
|
|
|
|
Agreed, it's hardly priority if alot of extra Db coding is needed. I'm contemplating whether such code could be re-used to offer an extended public key view with sorting re-enabled in future, so it can at least be left until after the new wallet format happens.
The threading, signaling and UI interfacing can be leveraged, but I suspect each filter needs to be developed individually. |
|
|
|
I can confirm the first issue is fixed in current 0.93 testing branch for me. 2nd issue remains though.
This isn't broken per say, it's disabled. The previous version of Armory kept all history in RAM both on the C++ and Python side. This allowed for ledger sorting on the Python side, but was slow and mainly, it scaled poorly. To implement proper scalability, there is no more history saved on the Python side. The only thing kept in RAM is the few ledger entries currently displayed in the ledger. The C++ side only keeps a snapshot of transaction count per block range, and builds pages of transaction ledgers on demand. To offer other type of filters (such as ordering by transaction amount or address comment) will require constructing dedicated history summaries for each filter type. It is doable but requires a lot of extra work to put it in place. Indeed, the filter by block height is very fast to compute, as transaction history is keyed by block height in the DB. As such, the summary for each address and wallet is computed in the main backend thread, after the DB has been initialized. More sophisticated filters such as ordering by value can't be preprocessed as easily. You would need to compute the full address and wallet ledgers to know the exact transaction value for each. Not only does it require extra code to achieve this, the operation is also too slow to let it run in the main backend thread. It would dramatically slow startup speed otherwise. As a result they would have to be computed in parallel, and some UI needs to be added to inform the user of the filter availability, kind of like the consistency check. That's too much effort for the benefit considering our current priority queue, so you shouldn't expect to see this feature back in the near future. |
|
|
|
|
Any non ascii characters in the path to Armory's exe?
|
|
|
|
|
Any non ascii characters in your user home folder?
|
|
|
|
Bad: It's incredibly difficult to do this, because Armory starts up so rapidly that there is very little time available to navigate to that menu option before the error occurs again.
I'll add a checkbox to rebuild and rescan on next start in the error dialog |
|
|
|
Sounds like I definitely explained it wrong: there are NO missing transactions/balance for me. None. In any 0.92.99.x testing version. But I am experiencing the tx info error dialog problem as of .99.3
Oh wow, I completely misinterpreted your posts then. This is the state of 0.93-bugfix currently: You won't get the error dialog anymore, that one is fixed for good. You won't get a dialog at all for coinbase rewards, and I'll have to look into that eventually (possibly have to delay the fix for 0.93.1 if it's too complicated). I couldn't get these dialogs with 0.92.x so I completely ignored that feature since. Tx details for incoming transactions, excluding those transactions that come from your own wallets, will lack sender data (it can't resolve the supporting txn hashes). You won't see the supporting txout value or fee, and the script type will be displayed as non-standard. I'm implementing the fix for that, but that's going into dev, so it'll have to wait for 0.93.1 (which has another round of DB optimizations coded in already) |
|
|
|
I'm 99% that Alan fixed/implemented it at some point in the past, but when that was and when it broke I cannot recall
Ok I'll look into that at some point then. No. I'm using a number of wallets that may or may not be greater than 1  Seriously though, I've tried it and there's no effect on which tx's generate the error dialog, or a way of displaying all/only the affected tx's using a custom filter setting. (...) I'll check .7 isn't the silver bullet before trying that though. I expect the missing txns in ledger and the error dialogs are 2 different issues. I have not managed to reproduce the ledger snafu, and I have reproduced and then fixed the error dialog issue, so I don't think the current state of 0.93-bugfix will fix the ledgers yet. If you run your own builds, you can pull bugfix and try it right now, but you'll have to rescan your DB to see the effect of the error dialog fix. Also, try the following trick to see if that fixes the ledger snafu. Comment out this line in ArmoryQt.py #3131, in finishLoadBlockchainGUI(self): self.createCombinedLedger() (had a # in front of it) Start Armory and see if the ledgers work properly. Otherwise revert the change. If you don't see any ledgers at first, toy with the wallet filter and they'll appear. |
|
|
|
The Transaction you requested be displayed is not in in* Armory's database. This is unusual..."
I just fixed that yesterday in 0.93-bugfix. It'll have to wait for .7 There is no discernible pattern, some tx's are affected and others of similar type are not (exclusively common sort of tx with 1-2 input/s and 2 outputs). Only real exception to this is that coinbase tx's do not even generate any error dialog. (edit: just cross-checked coinbase tx's in 92.99.2; it refuses to display tx details for coinabse tx's as with .3-.6)
afaik Armory never had tx detail dialogs for coinbase transactions. Export transactions .csv contains all details from the transactions that .3-.6 refuse to display. All details from all missing tx's are present and correct. This is indicating to me that the issue is related to reading/interpreting the Db and not writing it
Yeah sounds like GUI or filter snafu, but the DB is sound. CSV export uses the same code path to get and build tx info as the main ledger. It does make a point of reseting all wallet filters first though. Address ledgers do not use filters either so that's my prime culprit for now. Here is a set of new questions: 1) Is this error deterministic? Does the missing set of tx in ledgers vary from start to start? Or per rescan? 2) Is there a choice of wallet filters that reveals all missing transactions? From your log file it looks like you are using only 1 wallet, but try the single wallet filter and the custom wallet filter anyways. 3) This could be an issue that occurs only with single wallets. Do you have another wallet with some history you could load along side this one? 4) Can you try syncing Armory with one of the supported OSes? I need to make sure this isn't a Qt related issue. Something I may not have mentioned: all this is using Bitcoin Core 0.10.0 (currently rc4)
I've been using 0.10 rc3 since .3. Given the symptoms I don't expect this has anything to do with out of order block data anymore. |
|
|
|
|
Do you have a gap in your history is it just missing all tx past a certain point? Can you see these transactions in individual address ledgers? I'd like you to attempt 2 things:
1) Export your transaction history through File -> Export Transactions. Is the CSV missing transactions? Are they same as those missing in your main ledger?
2) Create a new wallet, import some popular private key with lost of history like correct horse battery staple and scan it. Does it exhibit the same issue? Which range of the history is missing?
|
|
|
|
These aren't necessarily usability concerns on their own, but it certainly makes me concerned to use the application! To clarify from earlier comments, it's not just coinbase transactions that are lost in the Db, it's everything after some arbitrary point in time about 2 months ago. Every tx I've sent (with 92.3) since testing pre-0.93 suffers the same fate when displayed in 0.92.99.3 -> .6 (admittedly not very many tx's)
Can you clear your log files, rebuild and rescan the DB with .6 and submit the fresh logs? |
|
|
|
In Export Key Lists, sometimes the wallet doesn't unlock properly and only displays public keys, other times it doesn't show up until i close the wallet's properties. The Goto button in the lockbox transaction is also cut off.
Sounds like something specific to OSX. I'll pass it along. My question regarding the public keys is that Export Key Lists doesn't show the public key used to create lockboxes. Can this be added?
This missing behavior is a bug actually. I never considered considered the relevant piece of code to fail under this perspective, so nice catch. It's also pretty easy to fix. Note that it will only work if the lockbox you created is funded at some point. Short of that it won't consider those public keys in use and thus won't display them in export lists. Also, I have one small request. Can a Cancel button be added to the Send Bitcoins window so that I don't have to restart Armory every time I accidentally open it? (this is the second bug)
OSX snafu too, I'll pass it along as well. |
|
|
|
|
Show Posts
