Hi to all!
Question:
Referencing back to "error" about the cpp header is not initialized after broadcasting over armoryd.
As already commented, it get stuck somewhere (well stuck maybe is not the correct definition,
it get stuck of the state, it returns inputs / outputs which are already spend etc..)
Is there a way to determine in the Heartbeat or somewhere else that the service state is not "healthy" ?
So a if we can determine that the service state is unhealthy a possible workaround would be just restarting the Service.
(Btw: Current deployed version: 0.90.99.5)
Some ideas how to determine it?
Best regards!
It is entirely possible the latest fixed in 0.90.99.5 broke some stuff in armoryd |
|
|
|
I had to redownload the full blockchain but now it is working again  Thanks! What issue were you experiencing? |
|
|
|
I cannot export transactions any more. I tried "Help-> Rebuild and Rescan Databases" with a restart afterwards as well, but it doesn't help. btw: I'm deeply impressed by the startup speed increase  2014-03-31 12:50 (ERROR) -- Traceback (most recent call last):
File "/usr/lib/armory/qtdialogs.py", line 8778, in accept
if self.createFile_CSV():
File "/usr/lib/armory/qtdialogs.py", line 8856, in createFile_CSV
f.write('Export Date:, %s\n' % unixTimeToFormatStr(RightNow()))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 20: ordinal not in range(128)
Should be fixed for 0.90.99.6 |
|
|
|
Most likely a non sequential address entry order. This alone doesn't constitute an error. It's a clue in case other errors occurred though. I just failed to send some coin to three addresses. It got as far as asking for my password, but when I clicked Unlock it returned to the "Sending from Wallet" dialog. There was no error message. I'm pretty sure I had the right password (and if I hadn't, I'd expect a helpful error message saying as much). I tried again after deleting the last address, and that failed the same way. I then deleted another address, so that only one was left, and that succeeded as expected.
(This was all on my desktop; no offline signing shenanigans involved.)
Fixed this error this morning. Will be part of the next testing build |
|
|
|
I don't have an RPi setup that I can use for testing atm I have an extra Pi lying around if you want it for testing. If both wallets are loaded on the online computer, you should see two transactions. As you said, it is two distinct events, one for each wallet, so it should show up (@goatpig: didn't you say something about duplicate ledger entries? did you misread this as a bug and "fix" it?)
Now that you mention it, in addition to no longer seeing an incoming and outgoing entry, I'm also seeing duplicate entires. I created one transaction from an offline to an online wallet, with multiple outputs to the online wallet. In the ledger, I'm seeing multiple entries for the full amount of the transaction, not the individual outputs. If that doesn't make sense, let me know what I can send you. That's the send to many issue I just fixed |
|
|
|
|
Testing this now.
There was a convoluted ledger entry misrepresentation that I caught fixing the send to many issue. This is all post .5, sadly.
|
|
|
|
|
Is your wallet gigantic? Or are you poiting at huge transactions? Do you have a Linux or Windows machine to try this wallet on? Would you be willing to send us a watching only copy of your wallet otherwise?
|
|
|
|
can you pastebin ./Makefile and ./cppForSwig/Makefile please
Please: http://pastebin.com/mTAQmT6Q . I can give a ssh access on non-root user or VNC if this can help. I fix this error by add PYTHON_INCLUDES=$(shell python2.7-config --includes )
to make file but still i have got: ImportError: /home/piotrek/Apps/BitcoinArmory/_CppBlockUtils.so: undefined symbol: _ZN6snappy21GetUncompressedLengthEPKcmPm
This isn't an error, it is meant to resolve the python includes path. Your issue is that LevelDB is built with Snappy support enabled, and you don't have Snappy anywhere in your build paths. What is odd is that Armory isn't set to use Snappy at all, and there's nothing modified in your Makefile so I don't see how LevelDB could have been built with the -DSNAPPY flag. You should make clean in LevelDB's folder and make again. |
|
|
|
|
You're pointing to the wrong Bitcoin Home Dir: You have it pointed at Armory's datadir, it should be pointed to where your BitcoinQt is expecting to find the blockchain
|
|
|
|
Am I glad I backed up my wallets, I launched it to the majority of my comments being wiped out:-
The comment issue is now fixed in branch 0.91-dev EDIT: just to be clear, the comments were never deleted from your wallet, they were not displayed, as an unattended consequence of the 99% crash fix. |
|
|
|
Also, is it correct it's on a system with 512 MB of RAM? Yes. Are you trying to run this online? No. As I said in my first post, this is intended to be an offline wallet, using a cheap netbook running XP. I tried using Process Monitor. That suggests Armory: - Successfully finds _CppBlockUtils.pyd
- Fails to find registry key HKCU\Control Panel\Desktop\MultiUILanguageId
- Fails to find _CppBlockUtils.pyd.2.Manifest
- Closes CppBlockUtils.pyd
- Fails to find ArmoryQt.pyc
- Fails to find ALL.pyc
- Fails to find ArmoryUtils.pyc
- Fails to find CppBlockUtils.pyc
- Closes various files and registry keys and exits.
That makes me wonder if some .pyc components are missing. No wonder it wouldn't work, the WinXP specific code was not in this branch. Fixed now, you'll have to wait for the next build. |
|
|
|
|
That's enough information to know where to look at.
|
|
|
|
If Armory shows up in the task manager briefly, it's probably opening the log file and dumping errors before quitting. You need to look at the log that it wrote to:
C:\Users\<user>\AppData\Roaming\Armory\armorylog.txt There's no Users folder on this XP machine. There is "C:\Documents and settings\<user>\Application Data\Armory\armory.exe.log.txt", but it's left over from the 0.8.8.1 install. It has data from two runs; the second one begins with: 2014-03-23 20:22 (INFO) -- armoryengine.pyc:816 - Loading Armory Engine:
2014-03-23 20:22 (INFO) -- armoryengine.pyc:817 - Armory Version : 0.88.1
2014-03-23 20:22 (INFO) -- armoryengine.pyc:818 - PyBtcWallet Version : 1.35
2014-03-23 20:22 (INFO) -- armoryengine.pyc:819 - Detected Operating system: Windows
2014-03-23 20:22 (INFO) -- armoryengine.pyc:820 - OS Variant : XP-5.1.2600-SP3-Uniprocessor Free
2014-03-23 20:22 (INFO) -- armoryengine.pyc:821 - User home-directory : C:\Documents and Settings\Owner\Application Data
2014-03-23 20:22 (INFO) -- armoryengine.pyc:822 - Satoshi BTC directory : C:\Documents and Settings\Owner\Application Data\Bitcoin\
2014-03-23 20:22 (INFO) -- armoryengine.pyc:823 - First blk*.dat file : C:\Documents and Settings\Owner\Application Data\Bitcoin\blocks\blk0001.dat
2014-03-23 20:22 (INFO) -- armoryengine.pyc:824 - Armory home dir : C:\Documents and Settings\Owner\Application Data\Armory\
2014-03-23 20:22 (INFO) -- armoryengine.pyc:825 - Detected System Specs :
2014-03-23 20:22 (INFO) -- armoryengine.pyc:826 - Total Available RAM : 0.49 GB
2014-03-23 20:22 (INFO) -- armoryengine.pyc:827 - CPU ID string : x86 Family 6 Model 13 Stepping 8, GenuineIntel
2014-03-23 20:22 (INFO) -- armoryengine.pyc:828 - Number of CPU cores : 1 cores
2014-03-23 20:22 (INFO) -- armoryengine.pyc:829 - System is 64-bit : False
2014-03-23 20:22 (INFO) -- armoryengine.pyc:830 - Preferred Encoding : cp1252
I can post the whole thing if it would help. It's about 16k. --skip-announce-check made no difference. Essentially we need the end of the file, like the last 200 lines or so. Pastebin it and post the link here. |
|
|
|
|
In your Armory data folder, do you have this folder: atisignedannounce ?
|
|
|
|
I've just installed 0.90.99.4 on netbook that I intend to become an offline wallet, and it doesn't seem to run. Clicking the desktop icon, ArmoryQT.exe shows up momentarily in Task Manager, and then disappears again. The notebook is an Asus Eee PC 701 running XP SP3 and not much else. The screen is (faked) 800x600 and there's no network driver; it's a pretty minimal configuration. I've tried adding "--offline", and also giving it an explicit logfile path in the command line, and it doesn't seem to get as far as creating it. I've tried rebooting the machine.
Hmm. Looking in the Program Files directory, there's a file "ArmoryQt.exe" that's only 1k long, and claimed by Windows to be a text file. It contains lines like "(ERROR) BDM.pyc:1122 - Resetting BDM and all wallets". There is also a file "ArmoryQt" (no extension) that's 251k long. Weird.
I previously installed it on my Win 8.1 desktop and that seemed fine. I'm using the Windows installer, from the first post in this thread. Scanning this thread, I seem to be the first person to mention using XP. Lucky me.
Edit: I've now uninstalled it and tried the old 0.88.1 instead. That runs up fine, so I guess the netbook is capable. (I've not actually created a wallet with it as I'd rather use the new version with the improved randomness.)
Try it with --test-announce, then without. |
|
|
|
It is possible to delete imported address with private key from encrypted wallet without entering the password. I dont know how this is possible - it shouldnt be that way. The private part of wallet should be encrypted so it should not be possible to mess with it without password.
It will not hurt the wallet's consistency to delete an entry in full, whether it is encrypted or not. However I'm not sure this can be done from our UI. If it can be done, then it is a mistake on our part and we'll get to fixing it right away. 0.90.99.40-test did the trick. I can now open my wallet with many multipool inputs and it does not crash. I did not do a factory reset - just installed the testing version over 0.90. I did have to manually point Armory to Bitcoin Core 0.90, I'm guessing because I installed the 64-bit version.
First of all, 0.90.99.4 (essentially it 0.91-beta RC3) uses different LevelDB system parameters, so we highly recommend you wipe your current DB and rebuild it. As for finding x64 version of 0.9.0 bitcoin core, it should find it on its own. Empty the path input line in the settings file, restart Armory and it should find it on its own. Let me know if it doesn't (it does work just fine on my end). |
|
|
|
When clients tie themselves to a single implementation it gets in the way of that goal.
That's disappointing, because it's good to encourage people to run full nodes, and it's also good for the network if full node implementations are heterogeneous.
Our current approach is to use bitcoin-core as our network gateway and block verification. From our point of view, we opt for the added security and reduced implementation cost. To give you an idea of the implementation cost to move to such model: currently Armory only uses bitcoin core to push transactions to the network. New blocks are detected by polling the blockchain folder. We could move to a model where we receive and parse new blocks from p2p directly. That would be cheap to implement but Armory would need access to a local copy of the blockchain, and it would still need bitcoin core as a gateway, so there's no improvement in the attempt the decouple from a permanent bitcoin core process. We mentioned in some discussions between devs to consider integrating the core's connectivity codebase directly to Armory, since we now have the manpower. The current implementation is cheap and secure, no wonder Alan opted for it. The opposite isn't quite as true. We'd have to build a in house wrapper around the current bitcoin core network classes and adapt it as new releases come out. Admitedly bitcoin core isn't changed all that often so we could do that, but it would still require of one of us to maintain it for every release, the same way one of us is dedicated to testing and guaranteeing builds on his dedicated OS. That has a certain cost that we can't justify right now, seeing that we currently have very few issues with bitcoind and that bitcoin core is striving to offer a strong gateway/p2p router solution. The added benefit to our users however is simplicity and versatility in their setup, and this is probably the only reason we have not entirely given up on this front. The true issue is the implementation cost vs returns. We have a functional setup right now. Another approach would be to drop bitcoind and use our upcoming litenode servers to maintain grab a full copy of the chain. However Armory would still not run as a full node, since this time it would use our centralized servers for connectivity. What I am getting to is that there is no shortcut in fully decoupling Armory from bitcoin core and still functionning as a full node. Ideally, we want to support and promote full nodes, and the safest, simplest way for us to do this is to piggy back on bitcoin core. This is why, if we ever plan on moving to another model, it will be on a very low priority, as we have other fronts we need to expand on first, and why I mentionned the far future. I hope this gives you a clearer idea what to expect on that front. |
|
|
|
I'm really looking forward to Armory no longer needing blockchain file-level access to a Bitcoin node.
I'd rather run Armory against a btcd node, and the only thing stopping that from working is that btcd doesn't use the same file format for storing the blockchain.
A lite node would achieve that, but they you wouldn't be a full node. I'm assuming what you're thinking of is a Armory mode that takes its block from p2p instead of local file access. We may look into that in the far future, however I don't think that's the direction we're taking right now. |
|
|
|
So, I'm running a full node on my computer with bitcoin-qt, and the only reason that I'm running said full node is because Armory requires it to run properly. Maybe I shouldn't bother because I don't have any bitcoins any more other than dust, but I might buy more in the future, and I would want to keep them in Armory.
Thus, the question: is there any possible way (development wise) to make Armory have a thin client option without sacrificing it's existing security? If it's not possible to do this without sacrificing security, I'd say don't bother, because that's the reason I use Armory, and I suspect that's true for most people who use Armory as a client.
Our plan is to have a lite node eventually. Part of the team is working on code to prepare that front. Granted, there still are a few major features to add before we can integrate lite nodes. |
|
|
|
|
can you pastebin ./Makefile and ./cppForSwig/Makefile please
|
|
|
|
|
Show Posts
