Topic: 0.96.4 RC1 - page 3. (Read 14281 times)
It looks like stuff that's already fixed in the testing branch. I'll put out another release soon.
I've found an error regarding tx preview. I have sent some tx multiple times by using RBF and CPFP via Armory and cleared all unconfirmed tx also multiple times, which could have messed up Armory's indices.
armorylog.txt
Could this be a damaged wallet file or is it "just" a tx index that's not working. I'm currently doing a rebuild and rescan.
Kind regards :-)
armorylog.txt
Code:
2017-12-17 17:30:29 (WARNING) -- Transaction.pyc:1263 - Unexpected nested type for TxIn 16
2017-12-17 17:30:29 (WARNING) -- Transaction.pyc:1263 - Unexpected nested type for TxIn 16
2017-12-17 17:30:29 (ERROR) -- Traceback (most recent call last):
File "ui\TxFrames.pyc", line 897, in createTxAndBroadcast
File "ui\TxFrames.pyc", line 862, in validateInputsGetUSTX
File "qtdialogs.pyc", line 4546, in __init__
File "armoryengine\Transaction.pyc", line 2727, in verifySigsAllInputs
File "armoryengine\Transaction.pyc", line 1579, in verifyAllSignatures
File "armoryengine\Transaction.pyc", line 1863, in evaluateSigningStatus
IndexError: list index out of range
2017-12-17 17:30:29 (WARNING) -- Transaction.pyc:1263 - Unexpected nested type for TxIn 16
2017-12-17 17:30:29 (ERROR) -- Traceback (most recent call last):
File "ui\TxFrames.pyc", line 897, in createTxAndBroadcast
File "ui\TxFrames.pyc", line 862, in validateInputsGetUSTX
File "qtdialogs.pyc", line 4546, in __init__
File "armoryengine\Transaction.pyc", line 2727, in verifySigsAllInputs
File "armoryengine\Transaction.pyc", line 1579, in verifyAllSignatures
File "armoryengine\Transaction.pyc", line 1863, in evaluateSigningStatus
IndexError: list index out of range
Could this be a damaged wallet file or is it "just" a tx index that's not working. I'm currently doing a rebuild and rescan.
Kind regards :-)
I already did that thrice. What I've done now is deleted the last few block files from bitcoin core corresponding to about where that recurring 99%-ish point would be(going by the logs), and restarted it with -reindex. Once it's back up to sync I will -AGAIN- rebuild the armory DB.
Your issue reminds me on mine serveral months ago. Are you using any Anti-Virus software, NAS or encrypted HDD?
I already did that thrice. What I've done now is deleted the last few block files from bitcoin core corresponding to about where that recurring 99%-ish point would be(going by the logs), and restarted it with -reindex. Once it's back up to sync I will -AGAIN- rebuild the armory DB.
Delete your databases folder and try from scratch.
Another hour spent fruitlessly trying to scan the transaction history for a wallet, at 99% and 28 seconds left admorydb.exe quits and armoryQt says nothing about even a connection loss, it just sits there. I only found in armorycpplog.txt "ERROR - 1486672480: (SwigClient.cpp:61) POLLERR error in readAndWrite", that is just the Qt losing connection to ADB but again - Qt said nothing about it. It will display tray messages about connection to bitcoind being lost but not ADB, which coupled with the ADB's lack of relevant reports, conspires to make these crashes as silent and obscure as possible. Even moreso, when I relaunch everything the history is rescanned from scratch.
dbLog.txt last states "-INFO - 20:33:49.875: (..\BlockchainScanner.cpp:852) scanned from block #498700 to #499207", whatever it was doing at the time before it dropped and how far it got, and after that nothing. I don't think I have anything more to give.
dbLog.txt last states "-INFO - 20:33:49.875: (..\BlockchainScanner.cpp:852) scanned from block #498700 to #499207", whatever it was doing at the time before it dropped and how far it got, and after that nothing. I don't think I have anything more to give.
Will look into it.
Created myself a new wallet and after scanning transaction history, armoryDB.exe always silently exits at around 99%. I already deleted the entire ADB twice. I've had issues with scanning transaction history in times past and what frustrates me the most - then and now - is how it just silently exits without any application error window or writing anything in the logs about it. Are there exception handlers missing somewhere? What should I do next?
Thanks for that. I'm going to create a new wallet then.
Quote
Sadly I'm not all that clear in the head and I'd be making assumptions based off that and need a more layman-friendly answer... would one private key of one address, and a bunch of public addresses jeopardize the entire wallet's private keys?
ELI5: any private key + the WO wallet is enough to reveal the whole wallet.
Quote
ALSO, if that key was P2PKH and I only use P2SH-P2WPKH keys, does it extend to them, or would it only compromise that one branch?
There's only one derivation branch in Armory wallets. A key pair is an asset, addresses (p2kh, p2sh and what not) are tied to an underlying asset.
Sadly I'm not all that clear in the head and I'd be making assumptions based off that and need a more layman-friendly answer... would one private key of one address, and a bunch of public addresses jeopardize the entire wallet's private keys?
ALSO, if that key was P2PKH and I only use P2SH-P2WPKH keys, does it extend to them, or would it only compromise that one branch?
ALSO, if that key was P2PKH and I only use P2SH-P2WPKH keys, does it extend to them, or would it only compromise that one branch?
To reveal the root, you need:
1) Private Key N
2) The public key chain from 0 to N
3) The chaincode
1) Private Key N
2) The public key chain from 0 to N
3) The chaincode
Are individual private keys relatable? If a single private key of one generated address becomes public(through manual export and accidental misuse for example), can the other private keys in the Armory wallet be determined from it?
wow, dude. this version kicks some ass. very fast and can import several different wallets at once. and i can use Coin Control reliably!
the key for me was deleting the old version and starting from scratch with the new compile. much happier!
the key for me was deleting the old version and starting from scratch with the new compile. much happier!
Any traceback in your logs? Otherwise delete this line in ArmorySettings.txt:
ccDlgGeometry
ccDlgGeometry
ended up deleting .armory and rebuilding from source. seems everything is working now. thanks.
Any traceback in your logs? Otherwise delete this line in ArmorySettings.txt:
ccDlgGeometry
ccDlgGeometry
Using 0.96.2 expert mode in Debian VM. Any news on fixing this?
Ummm, try 0.96.4 RC1? You're posting in this thread, after all....
Coin Control still freezes GUI with 0.96.3.99
It's not frozen, the dialog is modal and reduced. You have to find the reduced title bar and expand the dialog anew.
i've used the Coin Control dialog box many times before in the past; it's usually easily visible on popup. currently though, nothing seems to happen upon clicking the rectangular icon box; the Coin Control dialog is nowhere to be found on the desktop.
Using 0.96.2 expert mode in Debian VM. Any news on fixing this?
Ummm, try 0.96.4 RC1? You're posting in this thread, after all....
Coin Control still freezes GUI with 0.96.3.99
It's not frozen, the dialog is modal and reduced. You have to find the reduced title bar and expand the dialog anew.
now getting this:
when i run TOP, i don't see an instance of ArmoryQt running.
sudo kill -9 5955 doesn't fix it either.
edit: nvm, i closed it with sudo killall -9 ArmoryDB
is there a way to close Armory w/o generating this error repeatedly?
Code:
debian@debian:~$ armory
/home/debian
(ERROR) ArmoryUtils.py:3720 - Unsupported language specified. Defaulting to English (en)
/usr/lib/armory/armoryengine/Transaction.py:3074: SyntaxWarning: import * only allowed at module level
def PyCreateAndSignTx_old(srcTxOuts, dstAddrsVals):
(ERROR) ArmoryQt.py:5955 - Socket already in use. Sent CLI args to existing proc.
(ERROR) ArmoryQt.py:5956 - Exiting...
when i run TOP, i don't see an instance of ArmoryQt running.
sudo kill -9 5955 doesn't fix it either.
edit: nvm, i closed it with sudo killall -9 ArmoryDB
is there a way to close Armory w/o generating this error repeatedly?
arghhh, sudo killall -9 ArmoryDB only works intermittently.
now getting this:
when i run TOP, i don't see an instance of ArmoryQt running.
sudo kill -9 5955 doesn't fix it either.
edit: nvm, i closed it with sudo killall -9 ArmoryDB
is there a way to close Armory w/o generating this error repeatedly?
Code:
debian@debian:~$ armory
/home/debian
(ERROR) ArmoryUtils.py:3720 - Unsupported language specified. Defaulting to English (en)
/usr/lib/armory/armoryengine/Transaction.py:3074: SyntaxWarning: import * only allowed at module level
def PyCreateAndSignTx_old(srcTxOuts, dstAddrsVals):
(ERROR) ArmoryQt.py:5955 - Socket already in use. Sent CLI args to existing proc.
(ERROR) ArmoryQt.py:5956 - Exiting...
when i run TOP, i don't see an instance of ArmoryQt running.
sudo kill -9 5955 doesn't fix it either.
edit: nvm, i closed it with sudo killall -9 ArmoryDB
is there a way to close Armory w/o generating this error repeatedly?
Jump to: