Hmm, it unregistered by itself? ArmoryQT is still open and unchanged..
Garbage collected on the server side. Means the client callback loop is dying for some reason and the server considers the client has disconnected ungracefully, which also explains why the lobby is stuck to initializing in the GUI. -INFO - 1494025031: (BitcoinP2P.cpp:783) Connected to Bitcoin node
That line was already there, I'm looking for the one that says "RPC connection established". If you do not have this line yet, means the RPC connection is still borked. The fact that the client gets to register itself means the networking layer is fine though, and what you are experiencing is the notification issue with a half initialized server to node layer. I got a decent idea where to look at to fix this, so I'll try to get it for 0.96.1. On your end, you should try to get the RPC working. |
|
|
|
|
Is Core running behind your DB? There's a bug I need to investigate after moving all things p2p/RPC to the DB that will halt the client if no node is found on the server side.
Edit: actually, try to get the RPC working on your node. Make sure bitcoin.conf has server=1. Log shows it found the node, but didn't connect to the RPC.
|
|
|
|
|
Either extend the address chain on your offline wallet, or initiate the message signing from your online machine.
|
|
|
|
|
1) Delete this folder:
C:\Users\ricca\AppData\Roaming\Armory\databases
2) Make sure Core is fully synced, then shut it down
3) Start ArmoryDB on its own, let it complete building.
4) Once it says "enabling zero conf", start ArmoryQt, then report back.
|
|
|
|
|
Hmm I think it needs a wallet basically. Post the dbLog.txt on the server side.
|
|
|
|
Hi, just updated Core and installed this version.
Getting a crash as this occurs in ArmoryDB: -INFO - 1493967598: (..\BDM_Server.cpp:1025) unregistered bdv: 02f4bc80f1788c274f50
Thanks for any advice!
Post dbLog.txt |
|
|
|
|
Looks like you're out of disk space
|
|
|
|
|
Consider trying to build with clang, which sidesteps most of the asm/sse stuff in cryptopp. In the long term I'll be moving to libsecp and ctaes used in Core, that should reduce the headache.
|
|
|
|
Unfortunately, same problem. I did "make clean", in the end make still gives the same errors.
Do I have to do anything else besides removing those options for crypto++? Anything to activate the new config?
I'm unsure about that, I have to try it out on some old hardware of my own. Cryptopp is a pain like that. I plan to move away from it for the new wallets, that's how much distaste I have for it. |
|
|
|
Yes, the public key will of course be the same. But a bitcoin address based on P2PKH will be different from one based on P2SH-P2PK, even if the key is the same (is that not so?).
The script hash will be different if that's what you are asking about, and balance scanning means looking up script hashes in outputs rather than pub keys in inputs. So yes, you have to look for script hashes, regardless of the underlying pub key. As for the resources required to run Armory: So far I manage just fine with my laptop and the blockchain on a USB disk. But if Bitcoin is to remain useful, the block size must increase somehow (either through a fork, or through segwit - in the long run I expect both), and at some point I (or my heirs restoring my paper wallet) may give up running a full node. Nice to know that there is always another way of extracting the bitcoins, even in the worst-case scenario. Of course I hope that improvements to Armory will keep it running...
There is a scenario with blocks over P2P to allow Armory to run against a pruned node. I may also run a public DB once I get encryption up, to allow users to cash out from my DB instead of having to sync Core. But that will be a one time support out more than anything else. |
|
|
|
If so, I assume the new types generate different bitcoin addresses based on the same(?) underlying private key (I am here assuming that Armory still generates a single chain of private keys. I guess that cannot have changed if it is still sufficient to back the old wallet file up).
A private key yields a unique public key, that public key can encapsulated in any variations of output scripts. The new scripts are just that, different ways to use a public key. The code still makes sure a public is used once, regardless of what script type it was used as. Are the new ways of generating bitcoin addresses Armory-specific, or are they standardized?
There is no real standard to begin with. BIP32/44 assumes P2PKH but doesn't really distinguish between compressed and uncompressed public keys anyways. The conclusion of the Berlin s3nd meet was that we (wallet/service providers) are better off enforcing incompatibility than to try to get things done under one standard, as it just won't fit all use cases. I am asking because who knows what will happen to the Armory project in the future. At some point it may be discontinued, or the blockchain may become so big that I can no longer run Bitcoin Core. It gives me peace of mind that I can always run Armory in a tiny virtual environment and extract the private keys to another wallet. But that of course requires that the other wallet can generate the same kinds of output.
The 2 script types you can expect other wallets to support are P2PKH and P2SH-P2WPKH. As for running Armory in a restricted environment, I have ideas to reduce the requirements (like running off of a pruned node), but they aren't priorities atm. |
|
|
|
It's scanning transaction history now...
Will it take too long?
Depends on your hardware |
|
|
|
|
Will fix the simulfund issue for 0.96.1
|
|
|
|
|
Your drive looks full. This is probably creating a whole lot of issues.
|
|
|
|
|
Start BitcoinQt, let it go until it's done grabbing the blockchain
|
|
|
|
|
Start Core on its own, what's its top block? If it's not in the 46XXXX, let it catch up. Otherwise, delete your Armory database folder and let it rebuild from scratch.
|
|
|
|
|
Show Posts
