System: Win7
I am listed as the owner
I checked all permissions indicated in the properties window and in the cmd-window (attrib command)
Everything seems ok.
From the db.log:
file wallet.dat has LSN 1/109756, past end of log at 1/333
Commonly caused by moving a database from one database environment
to another without clearing the database LSNs, or by removing all of
the log files from a database environment
DB_ENV->log_flush: LSN of 1/109756 past current end-of-log of 1/333
Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment
PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
wallet.dat: unable to flush page: 7
txn_checkpoint: failed to flush the buffer cache: DB_RUNRECOVERY: Fatal error, run database recovery
PANIC: fatal region error detected; run recovery
PANIC: fatal region error detected; run recovery
PANIC: fatal region error detected; run recovery
So that means that your wallet.dat file is corrupted. That means that while you were moving that file around something got corrupted. Try getting a copy of the file as close to the original from the server. |
|
|
|
I am unable to see the balance in the wallet to even see if the funds have been deposited. I know which address in the wallet is supposed to receive the funds. I would really like to access these funds ASAP. I'm going to post the log files right now in a separate message. What can I do to access these coins today? Armory says I still have 9 hours left  You will not be able to see the balance until the wallet is fully synced. All you can do is wait for Armory to sync. Your Bitcoin is safe. What version of Armory are you using? It sounds like you are using one of the older versions which took a long time to sync. ValueError: No JSON object could be decoded
2016-10-09 22:04 (ERROR) -- SDM.pyc:883 - ValueError in bkgd req top blk
Traceback (most recent call last):
File "SDM.pyc", line 857, in __backgroundRequestTopBlock
File "bitcoinrpc_jsonrpc\authproxy.pyc", line 104, in __call__
File "json\__init__.pyc", line 351, in loads
File "json\decoder.pyc", line 366, in decode
File "json\decoder.pyc", line 384, in raw_decode
ValueError: No JSON object could be decoded
2016-10-09 22:04 (ERROR) -- SDM.pyc:883 - ValueError in bkgd req top blk
Traceback (most recent call last):
File "SDM.pyc", line 857, in __backgroundRequestTopBlock
File "bitcoinrpc_jsonrpc\authproxy.pyc", line 104, in __call__
File "json\__init__.pyc", line 351, in loads
File "json\decoder.pyc", line 366, in decode
File "json\decoder.pyc", line 384, in raw_decode
ValueError: No JSON object could be decoded
the log files have this over and over
That happens every so often. It means that Armory is unable to get a response from the rpc server. This does not really matter though and Armory will still work fine with those errors. |
|
|
|
I know I'm probably opening a can of worms and that this isn't a priority, but 0.94.1 can't seem to auto manage bitcoind in Windows 10 14931.
I've had similar problem before, and back then it was because of permissions, but this time I've set them before running bitcoind and Armory.
Check the permissions on the bitcoin.conf file. Make sure that you are allowed to change it's permissions. |
|
|
|
Been using multibit, but saw how you can keep track of a single address on blockchain so I made the switch for that. However, I can't find a place to import nor can I find how to keep the same address.
Multibit HD does not allow you to import addresses. It seems to create a new address for receiving every time and when I sent 2 payments, it was sent from 2 different addresses.
It should not allow you to reuse addresses. Address reuse is not advised. Does multibit have a feature where you can see your total sent/received?
I don' think so. |
|
|
|
Hey guys, would appreciate some help here.
Once Armory FINALLY finishes all 3 steps to go online I get ArmoryQt.exe has stopped working and the application closes. I reinstalled Armory and now I have another 17 hour wait on my hands. I was wondering if there was anything else I can do to either speed up the bitcoin engine or avoid this problem altogether.
What version of Armory are you using? Can you please post the log files? Also, does it matter I have yet to access my wallet? I posted the address for someone to send coins to me but I have yet to even go online and see if they are available.
thanks
You can always receive Bitcoin when you are offline. Your wallet does not need to be online because nothing is actually sent to it. If you have any opportunity to export your private key you can use it on any other Wallet solutions. Try Mycelium or coinb.in to access Funds if you have the Key. the dont need to Sync with the Server because they every time uptodate.
Please don't post when you don't know what you are talking about. There is no "the server" to sync with. Bitcoin is s decentralized network. |
|
|
|
AFAICT, you can't sign messages using their new UI.
Thanks man. Now my question is how can I use the old one so that I can sign a message. Thank again You can't. |
|
|
|
|
AFAICT, you can't sign messages using their new UI.
|
|
|
|
I believe there will be a slight change to the current wallet format to include some meta data about whether that wallet will support segwit (and thus do this conversion).
Any thoughts yet as to what issue/s could prevent the conversion working? The issue is only knowing whether it should be doing stuff with segwit or with legacy transactions, i.e. does it give you the segwit address or the normal one. |
|
|
|
Ok but I was referring to as using a bitcoin address without public key, unspent, viewing it from a block explorer
VS
Using a BIP32 wallet, where you have to expose the master pub key to use it watch only.
So a BIP32 wallet has inferior security than 1 single address.
In that regard, yes it is less secure. It would be impossible to hide the public key while still being able to derive all of the addresses for lookup. |
|
|
|
I checked the permissions.
The file is not write- or readprotected.
If I write in the console
walletpassphrase ... 300
The answer is:
CWallet::GenerateNewKey(): AddKey failed (code -1)
What do I need to access to this file?
At this point, I am not sure what exactly is wrong and how to fix it. The problem lies in the wallet and Bitcoin Core being unable to write to it. Can you post the contents of the db.log (not debug.log). There may be something useful in there. |
|
|
|
This is what I feared, so basically BIP 32 is useless then, and better keep bitcoin in 1 unspent address.
No, it isn't useless. Just don't give out your Master public key. It is still useful for deterministic backups. One thing to remember is that the keys are not derived off of each other. The keys are derived from the master public key, not the child key that came before it. So it is still safe to use BIP 32 wallets, just don't give out your Master public key and don't derive child keys based on addresses you already used. Yeah but you cannot use it as watching only, since the master pub key is exposed. Yeah its still good for normal use but not the "ultimate security" i was expecting. Any chance the BIP32 will be uppgraded to quantum resistance and make master public keys hardened? The only way to get quantum resistance is to move off of ECDSA altogether. In that case, everything would move to a quantum resistance signing algorithm. Once QCs start becoming more viable, I think that there is a very high chance that there will be a fork to move Bitcoin to a quantum resistant algo. |
|
|
|
This is what I feared, so basically BIP 32 is useless then, and better keep bitcoin in 1 unspent address.
No, it isn't useless. Just don't give out your Master public key. It is still useful for deterministic backups. One thing to remember is that the keys are not derived off of each other. The keys are derived from the master public key, not the child key that came before it. So it is still safe to use BIP 32 wallets, just don't give out your Master public key and don't derive child keys based on addresses you already used. |
|
|
|
I have already done that manually (checked every address on blockexplorer) . And its 10% shorter than what was last shown by armory.
Then that means you recorded the wrong numbers or there was a spend between when you recorded it and now. |
|
|
|
BIP 32 keys are still ECDSA keys. Therefore they have the same problems that all ECDSA keys have, which is to say they are not quantum resistant.
Well i have done some research and most experts say that in the context of child keys: Unspent addresses are safe against quantum hackers -> Because the public key is not revealed,so unless somebody posts his public key on facebook, it should hold, because it has another layer of RIPEMD protecting it. That should hold against quantum computers. However I want to see what is the context of this theory in the BIP32 wallets ,where we are talking about master public keys. The Extended public keys are not hashed. Otherwise it would not be possible to actually get the public key and derive the non-hardened child addresses. This means that once QCs are viable, you should not hand out your xpub because then the public key can be gotten and the corresponding private key can be retrieved. Then the attacker can derive all of your address's private keys and steal your Bitcoin. |
|
|
|
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#restrictions-on-public-key-typeThe linked section in BIP143 sounds alot like any attempt to spend an Armory wallet output (held by uncompressed public keys) to a P2WPKH or P2WSH address will not be relayed by default policy. Does this mean that we may have to rely on miners who use non-standard relay policy to spend directly to P2WPKH or P2WSH addresses? There's also a suggestion that trying this carries a danger that could render the outputs unspendable when the native Segwit addresses are activated. (I realise the new wallet format could be used as an intermediate step. Sounds expensive to me though....) This has already been discussed and solved (mostly). At some point we will be moving to a new wallet format which supports BIP 32 and compressed keys. For now, what will happen is that the uncompressed keys will be dynamically converted to compressed keys for the creation of the scripts. I believe there will be a slight change to the current wallet format to include some meta data about whether that wallet will support segwit (and thus do this conversion). |
|
|
|
Ok im sad to say im still at a considerable loss.
I have installed the latest armory client (0.94.1) and the latest bitcoin core (0.13) on my PC. It all works as it should and i have recovered my wallet (via my seed) on to this fresh set up.
My missing balance is still not showing. I scanned and rebuilt database with the wallet backed-up. Its still considerably short (10% short). Im wondering is there anyway i can check the last displayed online balance, on my original armory on my laptop. If that make any sense?
Like is there a way (debug or other way) to show my last known balance as shown when the system was last online? Im 100% sure i keep my balances 100% accurate but i feel as though im going crazy here and literally doubting myself.
Any advise would be welcome.
Armory does not store your balance data in the logs. I advise you to go through every single address in your wallet and look them up in a block explorer. Then add up how much Bitcoin it should have and see if that matches what the wallet says or what you previously recorded. |
|
|
|
|
BIP 32 keys are still ECDSA keys. Therefore they have the same problems that all ECDSA keys have, which is to say they are not quantum resistant.
|
|
|
|
Well i spent the whole last 5 days downloading/syncing Bitcoin core. I have made a copy of the whole "Bitcoin" file into my documents. If that program/file (armorycpplog.txt) was open the whole time i was downloading the Blockchain. Is there a chance im sitting on a corrupted blockchain here? *bites nails and stares into the abyss*  No. It will not affect anything Bitcoin Core does because that log is only for Armory. It won't affect Armory does either because it is just a log file. |
|
|
|
Where would i be able to find the armorycpplog.txt file?
I want to completely wipe armory 0.93 on my mac and install 0.94
But it my mac says its unable to wipe the program since armorycpplog.txt is open.
Check that you don't have a text editor with the file open. IIRC Macs don't actually close the program when you click the x so it might still be open. |
|
|
|
|
Show Posts
