Armory 0.96.3 released

[goatpig]

Notes

This is a point release to fix a vulnerability with fragmented backups. If you are using fragmented backups on for your wallets, read the dedicated topic:

https://bitcointalk.org/index.php?topic=2199659.0

Binaries

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3

Changelog

== Vulnerability Fix ==
   - Fragmented backups were using a faulty implementation of Shamir's Secret Sharing (SSS).
     One of the requirement of SSS security parameters is that the coefficients of the curve are chozen randomly. The implementation
     up to this point was deriving these coefficients deterministically.

   - While it is hard to determine how far the deterministic coefficient generation erodes the security of SSS, and how exploitable
     the vulnerability is, the recommendation for users of fragmented backups is to treat the wallets backed up in this fashion as
     compromised and to migrate all funds to a new wallet.

   - The fragmented backup code now properly randomizes the SSS coefficients. Fragmented backups created with version 0.96.3 and later
     are safe to use.

   - The result of this change is that fragmented backups will no longer be deterministic. The previous behavior guaranteed a given
     wallet will always return the same set of fragments for a given M-of-N scheme. Since it deteriorates SSS security properties,
     the behavior has to be rolled back.
   - Fragment sets are now generated randomly, therefor an unique ID has been added to each set to identify them. You cannot mix
     and match sets.
   - While Armory can no longer generate deterministic fragments, it can still restore wallets from deterministic fragments.

   - Many thanks to Gregory Maxwell (greg@xiph.org) for identifying and reporting the vulnerability as well as reviewing the fix.

== Fixed ==
   - Fixed faulty version packet deserialization revealed by Core 0.15.0.1

[1715500241]

1715500241

[1715500241]

1715500241

[1715500241]

1715500241

[1715500241]

1715500241

[droark]

FYI, this version of Armory is the last one built to run on OS X 10.7. Starting with 0.96.4, you'll have to roll your own version if you insist on running Armory on 10.7. Long & technical story short, Armory uses code that can have issues on 10.7. Supporting 10.7 made it more difficult for people on more recent versions to compile the code. So, 10.7 is out the door.

Also, goatpig didn't explicitly mention this but I believe this will fix the issues people were seeing when they ran Core 0.15.0.1 (i.e., the ones where goatpig told them to go back to 0.15). If you're still having issues, post your logs!

Thanks.

[achow101]

Also, goatpig didn't explicitly mention this but I believe this will fix the issues people were seeing when they ran Core 0.15.0.1 (i.e., the ones where goatpig told them to go back to 0.15). If you're still having issues, post your logs!

Yes, it does fix that problem, hence that one line under "== Fixed =="

[Searinox]

I have completely deleted the blockchain, let 14.0.2 redownload all of it which took over a day, let ArmoryDB rebuild its database, and when I launch Qt I get the Same Old issue. Yes I am on 0.96.3 now, and nothing's changed. Really, bitcoind seems to be behaving fine, and ADB is also building up its database normally, I'd wager the issue is with Qt.

EDIT:

I went ahead and I moved the wallets away from ArmoryQt's folder, and deleted the settings file. Started fresh with a new wallet. The issue remains UNCHANGED.

When not using any wallet, the Qt shows Connected and correct number of blocks loaded, and keeps up to date. The problem always seems to appear when having to do anything with scanning transaction history, which never goes ahead. Qt will also close normally when there is no history to scan, as opposed to when there is, in which case it will seem to operate normally right up to being Quit, at which point it will freeze up and require forced termination.

Rechap:

Core 0.14.0.2 - fresh everything - 1.5 days old (I even deleted peers.dat, banlist.dat etc.)
ArmoryDB - fresh everything(including old files deleted and replaced before this update) - few hours old
Qt - same as DB, with fresh config as of - 30min ago



EDIT2:

I updated Core to 1.15.0.1. No dice. So what I have is, whenever Qt launches and connects to ArmoryDB, ADB's log gets this:

Code:

-INFO  - 16:56:45.234: (..\BDM_Server.cpp:1114) registered bdv: 9763f8e6ac8df2c46d7a
-INFO  - 16:56:45.406: (..\BDM_supportClasses.cpp:401) Starting address registration process

Nothing more follows. From what I see it's supposed to start showing "Scanned from height #" events as it processes the blockchain. It does not proceed. Yet the blockchain is loaded properly enough to actually exist in bitcoind, up to date, and with no errors reported by it. The blockchain is also loaded properly enough by DB to build its database out of it. Then when Qt wants to scan an address, suddenly it cannot load it?

bitcoind - all ok, downloaded blockchain up to date, maintaining it, no errors in log
armorydb - all ok, log shows loading all blk files up to date, no errors reported
amroryqt - requests history for wallet, armorydb chokes on the request, qt cannot find/load blockchain - SAME WITH FRESH CONFIG AND NEW EMPTY CLEAN WALLET

What gives?

[HCP]

Are you running on Windows? If so, is your Bitcoin Core blockchain data in the "default" location? (C:\Users\USERNAME\AppData\Roaming\Bitcoin) or did you set it to a custom directory?

[goatpig]

Sounds like your blockchain data is corrupt. Probably somewhere in the first 5 or so files. Could you upload these somewhere so that I can take a look?

[Searinox]

Are you running on Windows? If so, is your Bitcoin Core blockchain data in the "default" location? (C:\Users\USERNAME\AppData\Roaming\Bitcoin) or did you set it to a custom directory?

Windows 10 x64 Creators Update. Location is non-standard. But it's the same folder it's been for years. There have been no changes to paths.

Bitcoin core: satoshi-datadir is "F:\Program Files\Armory\Data_BTC\blocks" where all 140+GB of blockchain are.
ArmoryDB: satoshi-datadir is "F:\Program Files\Armory\Data_BTC\blocks", datadir is "F:\Program Files\Armory\Data_ArmoryDB"
ArmoryQt: satoshi-datadir is "F:\Program Files\Armory\Data_BTC\blocks", datadir is "F:\Program Files\Armory\Data_ArmoryQt"

All 3 executables have under properties -> compatibility -> run as administrator checked. I verify that I can read and write randomly created files in the folders. I'm not getting prompted to confirm any permissions and it works fine.

Sounds like your blockchain data is corrupt. Probably somewhere in the first 5 or so files. Could you upload these somewhere so that I can take a look?

I'm guessing the blocks from Data_BTC\blocks right? Do you want the blk###### files? They're 127MB each. I reiterate that I have a fresh blockchain.

[Searinox]

Rather than wasting time to upload, I hashed them. See if this is enough for you.

Code:

  File: blk00000.dat
CRC-32: 1c7370f0
   MD4: 35d999d57683ec6b8096fc4738ed9d76
   MD5: b1d473ee9ad05a7c5d8c3094840b6295
 SHA-1: 693a0a3466424ca633f297e61e6d496a3a72f207

  File: blk00001.dat
CRC-32: 847b6315
   MD4: 4a0c34dd784338da7e0a13fe9d995ef5
   MD5: ed020c6d24cb0dbf06354f0a92ac10bc
 SHA-1: e09334553bc79a765866fc964cd280555da11dbb

  File: blk00002.dat
CRC-32: 6ac18b34
   MD4: 92c0f8cd783fe7bd8b1bfb193542aa55
   MD5: 97fa4ff5428a15282e304a831e68e312
 SHA-1: b36449e2914ede693cae4983d59ea19b6180b509

  File: blk00003.dat
CRC-32: efee16af
   MD4: f795bd0172260995f1e6c8bc95863ce9
   MD5: 8a057ef398031e4bc75cacf7639219c8
 SHA-1: 6d0828d4655701a8926a4b2acbffbe209eb38992

  File: blk00004.dat
CRC-32: 430c67b8
   MD4: 27a9dd6f59c9ccbae7211756afd0efbf
   MD5: d7141d2a74eac77b77c7c8611cc656a2
 SHA-1: 39db004eeeb7f77b2db431d4af3c455e57151d18

[goatpig]

Hashes are pointless, that data is not downloaded sequentially, no one has the same hash for this stuff.

I have no idea why your setup does not work. You're the only person with this issue so I have no clue to go with. You could give me the full log of a fresh DB bootstrap one last time, but if that doesn't yield anything, at some point I'm going to need to see some backtraces or look at your block files. Later is easier to deliver.

[Searinox]

Blocks 0-4 can be found here: https://drive.google.com/open?id=0B5_lN_xRgoTVU0N0djUtX05QWmM

[goatpig]

There was no issue with the block files. Something in your setup is preventing the DB from progressing forward. You're going to have to get me some debug data.

You can setup a Ubuntu VM and run the DB in there, or make in a different version of Windows, while your client remains on the host, or you need to whip out MSVC, build a debug version of the DB and set some key breakpoints to figure out what's going on. Pick your poison. I'm out of idea about how to do this easily.

[Searinox]

@@; Kay I'm just uh... gonna do some generic troubleshooting and cleanup and wait for everything to work at some point. As an extra bit of info though, bitcoind runs independent.

Code:

-INFO  - 19:24:54.343: (..\BDM_Server.cpp:1114) registered bdv: a2f604a580439d1dc0c0
-INFO  - 19:24:54.515: (..\BDM_supportClasses.cpp:401) Starting address registration process
-INFO  - 19:25:25.437: (..\BlockchainScanner.cpp:52) no history to scan
-INFO  - 19:30:02.500: (..\BlockchainScanner.cpp:52) no history to scan
-INFO  - 19:31:26.625: (..\BlockchainScanner.cpp:52) no history to scan
-INFO  - 19:34:33.015: (..\BlockchainScanner.cpp:52) no history to scan
-INFO  - 19:35:34.781: (..\BlockchainScanner.cpp:52) no history to scan
-INFO  - 19:39:23.625: (..\BlockchainScanner.cpp:52) no history to scan
-INFO  - 19:41:06.250: (..\BlockchainScanner.cpp:52) no history to scan
-INFO  - 19:57:16.109: (..\BlockchainScanner.cpp:52) no history to scan

WAIT A MONENT!

I accidentally started Qt before ADB and it began building its own DB in its own foloder. I used to start bitcoind, armoryDB and armoryQt each individually with its own command line; since when is DB managed by Qt??? Let's see how this works.

[goatpig]

since when is DB managed by Qt???

Which Qt? BitcoinQt or ArmoryQt?

-INFO  - 19:25:25.437: (..\BlockchainScanner.cpp:52) no history to scan

That means the DB has seen a new block but it has not address data to scan against it.

[Searinox]

since when is DB managed by Qt???

Which Qt? BitcoinQt or ArmoryQt?

-INFO  - 19:25:25.437: (..\BlockchainScanner.cpp:52) no history to scan

That means the DB has seen a new block but it has not address data to scan against it.

ArmoryQt(I don't use BitcoinQt). I used to be able to launch ADB independently of AQt. Now when I start AQt it also launches -another- instance of ADB with its own separate database folder. Is there a way to stop AQt from doing this? Or is this the only way AQt will run properly?

[goatpig]

ArmoryQt will first look for a DB on the given IP:port. If it can't find one, it will spawn a DB. If you are running a DB but ArmoryQt can't find it, you aren't giving it the proper IP:port to look at.

[Searinox]

ArmoryQt will first look for a DB on the given IP:port. If it can't find one, it will spawn a DB. If you are running a DB but ArmoryQt can't find it, you aren't giving it the proper IP:port to look at.

ArmoryDB is running on localhost with no exotic IP:port setup. But it is running independently. What commandline should Qt use to connect?

[droark]

Also, goatpig didn't explicitly mention this but I believe this will fix the issues people were seeing when they ran Core 0.15.0.1 (i.e., the ones where goatpig told them to go back to 0.15). If you're still having issues, post your logs!

Yes, it does fix that problem, hence that one line under "== Fixed =="

Sorry, what I meant was that, IMO, the phrasing wasn't as clear as it could've been. I definitely saw the entry. I just wanted to make it clear to those who don't speak technobabble.

[goatpig]

ArmoryDB is running on localhost with no exotic IP:port setup. But it is running independently. What commandline should Qt use to connect?

It should find the DB instance by default.

[Searinox]

ArmoryDB is running on localhost with no exotic IP:port setup. But it is running independently. What commandline should Qt use to connect?

It should find the DB instance by default.

DB managed by QT builds the tx history. I tried to replicate its command line in my own version of it. The one thing I could not do was connect QT to the DB once it starts with --cookie, because it randomizes the listen port.

[goatpig]

Something is off with how you pass your custom arguments. The cookie arg is not mandatory, if you start an instance of the DB and give that arg to your client you should be fine. Are you using something else than 127.0.0.1? Is localhost resolved to some other IP? You need to list out all parts of you setup that deviate from default settings and isolate them one after another.

[Searinox]

I managed to nail it down to calling with --ram-usage=1. When I don't use the parameter, it scans tx history just fine. Please have an attempt to repro this.

Several hours later, I am at this point able to tell that removing --ram-usage fixes all the issues and building completes with success. Looking at the memory usage, I'm not even noticing any differences(stays at around 700-900MB). Is that parameter still valid even or is it just legacy at this point?

[AlienLifeForm]

I'm back to 0.96.2.

With 0.96.3 I've the problem with scanning the transaction history. It say's , that it starts and that is the last what it says.

I've found the following entries in the log:

Traceback (most recent call last):
  File "ArmoryQt.py", line 5449, in closeForReal
  File "SDM.pyc", line 485, in stopBitcoind
  File "armoryengine\ArmoryUtils.pyc", line 836, in LOGERROR
TypeError: cannot concatenate 'str' and 'exceptions.RuntimeError' objects

[Searinox]

Are you running any custom command line parameters on armoryDB or are you just running everything standard?

[goatpig]

I managed to nail it down to calling with --ram-usage=1. When I don't use the parameter, it scans tx history just fine. Please have an attempt to repro this.

Hmm that sounds unlikely but I will definitely test it out.

Several hours later, I am at this point able to tell that removing --ram-usage fixes all the issues and building completes with success. Looking at the memory usage, I'm not even noticing any differences(stays at around 700-900MB). Is that parameter still valid even or is it just legacy at this point?

This parameter controls the write queue depth for scan threads. It's only one element that controls total RAM footprint for scans, which would be broken down to these items:

- size of batches (hardcoded here: https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockchainScanner.h#L24)
- batch queue depth
- constant overhead from the container objects
- speed at which your system goes through the batches

After a substantial rework of the scanning queu mechanism, this parameter doesn't have much effect on full node scans as they're leaner, nor is it really necessary anymore. It is very significant for supernode however.

[Searinox]

I picked the parameter up like a year ago and have been using it up til now. I might use this opportunity to look again through all the params.

[Ente]

Updating both a remote armorydb and a local armory client went smooth, on debian via git. Works fine with bitcoin-conr 0.15.0.1 now.

Thank you everyone.

Ente

[markle]

Hi Goatpig,
I am near cracking with the frustration !
Thanks for 0.96.3 OS X, it is appreciated.
I tried to run this tar etc. I am still getting the error message Armoury Client failed unexpectedly...
It is not writing at all to my /Users/Name/Library/Application Support/Armory/Armorylog file or my dblog.txt file. My Bitcoin wallet.dat file is in this path /Users/Name/Library/Application Support/Bitcoin.
My armoury wallet file is in /Users/Name/Library/Application Support/Armory/armory_2Ar36k775_wallet but it is no longer opening or updating.
Droak mentioned that I might be able to just copy my wallet.dat to a Windows PC armoury client and run it from there ?
Any , any guidance would be appreciated as I am tearing my hair out ! Thanks

Bitcoin Core 0.14.2
Mac 10.11.6

[goatpig]

I'm no OSX expert. At this point I'd suggest you just run a Ubuntu VM and run Armory off of that.

[markle]

Hi Goatpig, Thank you.
I did also try deleting the Databases Folder for the armory Client but still no luck :-( I will read up about ubuntu vm on mac, Thanks

[droark]

Hi Goatpig, Thank you.
I did also try deleting the Databases Folder for the armory Client but still no luck :-( I will read up about ubuntu vm on mac, Thanks

Hi. Have you read the OSX readme? If it's not starting and you don't have a newer version of OpenSSL installed, Armory will never start. If it is failing, what exactly is happening? Can you post a screencap or something similar?

In any event, if you move over to a Linux VM, I think VMware Fusion is nice. It's not free but it generally works without issues. You can just copy your Armory and Core/Cash/whatever data over there so that you don't have to re-download the entire blockchain.

Thanks.

[Searinox]

What is the new memory usage limit for wallet decryption?

[goatpig]

What is the new memory usage limit for wallet decryption?

Was never changed.

[gangtraet]

Hi Goatpig,
I am near cracking with the frustration !
Thanks for 0.96.3 OS X, it is appreciated.
I tried to run this tar etc. I am still getting the error message Armoury Client failed unexpectedly...
It is not writing at all to my /Users/Name/Library/Application Support/Armory/Armorylog file or my dblog.txt file. My Bitcoin wallet.dat file is in this path /Users/Name/Library/Application Support/Bitcoin.
My armoury wallet file is in /Users/Name/Library/Application Support/Armory/armory_2Ar36k775_wallet but it is no longer opening or updating.
Droak mentioned that I might be able to just copy my wallet.dat to a Windows PC armoury client and run it from there ?
Any , any guidance would be appreciated as I am tearing my hair out ! Thanks

Bitcoin Core 0.14.2
Mac 10.11.6

Have you moved the app after you unpacked it? 

Some fancy security measure in OS X kicks in when an app is unpacked from a tar file or a zip file.  Most apps are not harmed by this, but it prevents armory from starting.  Once you move the app using the Finder, this security measure is disabled, and Armory should work again.

[goatpig]

Run this script:

https://github.com/goatpig/BitcoinArmory/blob/master/dpkgfiles/make_deb_package.py

[visdude]

ArmoryDB.exe lingers in a couple of Windows 7 machine after exiting ArmoryQT per Windows Task Manager. I never had this behavior before 0.96.3. Must "End Process" manually. Otherwise, it hangs right after Wallet Consistency Check.

 

[goatpig]

ArmoryDB.exe lingers in a couple of Windows 7 machine after exiting ArmoryQT per Windows Task Manager. I never had this behavior before 0.96.3. Must "End Process" manually. Otherwise, it hangs right after Wallet Consistency Check.

 

How long is "linger"?

[visdude]

ArmoryDB.exe lingers in a couple of Windows 7 machine after exiting ArmoryQT per Windows Task Manager. I never had this behavior before 0.96.3. Must "End Process" manually. Otherwise, it hangs right after Wallet Consistency Check.

 

How long is "linger"?

Seems forever...until manually ending process.

[goatpig]

Ok, will look at it.

[Ente]

After two weeks, suddenly Armory doesn't load up properly any more. The GUI hangs at "preparing databases". The shell says

-ERROR - ���iGx: (SwigClient.cpp:61) ser/deser type error:
expected type id: 4
got type id: 0 instead

..with changing random bytes in the first line.

Armorydb is on a remote host. I didn't change anything that I know of lately.
Anything I can do except updating to 0.06.4R1?

Thank you,

ente

[morpheus123]

Question : If we loose the wallet but i see that somehow we still store the private key and multiplier in the app data of armory for every recieving address generated for every wallet , is there a way i can use these to restore the deleted wallet or some way of getting hold of my lost wallet ?

[goatpig]

After two weeks, suddenly Armory doesn't load up properly any more. The GUI hangs at "preparing databases". The shell says

-ERROR - ���iGx: (SwigClient.cpp:61) ser/deser type error:
expected type id: 4
got type id: 0 instead

..with changing random bytes in the first line.

Armorydb is on a remote host. I didn't change anything that I know of lately.
Anything I can do except updating to 0.06.4R1?

Thank you,

ente

It's trying to register with the DB and gets an empty message in return. Make sure the http daemon is running properly. Alternatively you can 0.96.4 and get rid of the http daemon part.

[goatpig]

Question : If we loose the wallet but i see that somehow we still store the private key and multiplier in the app data of armory for every recieving address generated for every wallet , is there a way i can use these to restore the deleted wallet or some way of getting hold of my lost wallet ?

The multipliers are basically useless. You need the private keys.

[Ente]

After two weeks, suddenly Armory doesn't load up properly any more. The GUI hangs at "preparing databases". The shell says

-ERROR - ���iGx: (SwigClient.cpp:61) ser/deser type error:
expected type id: 4
got type id: 0 instead

..with changing random bytes in the first line.

Armorydb is on a remote host. I didn't change anything that I know of lately.
Anything I can do except updating to 0.06.4R1?

Thank you,

ente

It's trying to register with the DB and gets an empty message in return. Make sure the http daemon is running properly. Alternatively you can 0.96.4 and get rid of the http daemon part.

Oops, of course you are right, my armorydb service stopped..
Thanks, now I know how that looks like too! :-)

Cheers,

Ente

[goatpig]

Oops, of course you are right, my armorydb service stopped..
Thanks, now I know how that looks like too! :-)

Did it crash or did you stop it on your own?

[Ente]

Oops, of course you are right, my armorydb service stopped..
Thanks, now I know how that looks like too! :-)

Did it crash or did you stop it on your own?

I didn't stop it at least. Didn't even log into that remote machine for some time.
I checked with 'service armorydb status', did look all ok. Stopped/started nevertheless, and it worked again.
I'm unsure if it was really crashed or something else was hanging. I can try to dig up the old system logs if you want.
I'm still on "months and months of bitcoind & armorydb running with no issues whatsoever" in my counting :-)

Ente

[Ente]

Oops, of course you are right, my armorydb service stopped..
Thanks, now I know how that looks like too! :-)

Did it crash or did you stop it on your own?

I didn't stop it at least. Didn't even log into that remote machine for some time.
I checked with 'service armorydb status', did look all ok. Stopped/started nevertheless, and it worked again.
I'm unsure if it was really crashed or something else was hanging. I can try to dig up the old system logs if you want.
I'm still on "months and months of bitcoind & armorydb running with no issues whatsoever" in my counting :-)

Ente

Well, by chance I found the problem why armorydb wasn't running some weeks ago:

Out of memory: Kill process 13329 (ArmoryDB) score 864 or sacrifice child
Killed process 13329 (ArmoryDB) total-vm:11996956kB, anon-rss:6895508kB, file-rss:0kB

That means 6.6 gigs used? 8 GB memory installed, no swap configured.

Right now it chucks away at a more modest

VIRT        RES         SHR  S  %CPU %MEM     TIME+     COMMAND
5603608 537828   7584 S   1.3      6.7          21:58.85 ArmoryDB   

Cheers,

Ente

[goatpig]

Will look into it.

[carl.byington]

I have a python script that generates a receiving address for an invoice.

Code:

wallet      = PyBtcWallet().readWalletFile(w)
receive     = wallet.getNextUnusedAddress()
parms       = urllib.urlencode({'amount':'%1.8f'%btc, 'label':comment})
url         = "bitcoin:%s?%s" % (receive.getAddrStr(), parms)
wallet.setComment(receive.getAddr160(), fullcomment)

Recently (0.96.x ??) that fails in getAddrStr(). Is there a replacement function?  I presume this is a side effect of the multiple address formats, segwit stuff.

[goatpig]

You can't do it like this anymore, you need to load the cpp mirror wallet as well.

[carl.byington]

I am trying to get the next address from a watchonly (offline) wallet. I have:

Code:

ls -1 .armory/*wal*

.armory/armory_2JkNrCxmd_backup.wallet
.armory/armory_2JkNrCxmd_.wallet
.armory/armory_2MhR27GuV_wallet.lmdb
.armory/armory_2MhR27GuV_wallet.lmdb-lock
.armory/armory_mwFUHedu_.watchonly_backup.wallet
.armory/armory_mwFUHedu_.watchonly.wallet
.armory/armory_wfeRswio_wallet.lmdb
.armory/armory_wfeRswio_wallet.lmdb-lock

How do I associate the correct .lmdb mirror wallet with a specific .wallet file?

[goatpig]

https://github.com/goatpig/BitcoinArmory/blob/master/ArmoryQt.py#L2212

[heywheelie]

I am using Armory 0.96.0 with bitcoin core 0.14.2.  I have been advised to update to the latest version of Armory which I assume is 0.96.3.

I have 2 questions:

1.  Can I just install Armory 0.96.3 straight  over 0.96.0 (I'm using windows x64 installer) or do I need to totally remove 0.960 and do a clean install of 0.96.3?

2.  Do I need to update bitcoin core or can I stay with my existing version 0.14.2

[markle]

Hi Goatpig,

Some help please if you can !
After guidance I moved from using OSX 0.93 to Ubuntu 0.93 with a separate Bitcoin Core installation however I am getting the error message "No block in DB at height 481824" in my armorycpplog.txt file. I have cleared the Blocks file in the .armory path and have rebuilt but it always seems to fail with the advice to 'reset Databases', which I have tried. Is this a Segwit problem with the Wallet or Armoury Client, is there anyway around this please ?

[goatpig]

0.93 is over 3 years old. Update.

[carl.byington]

Thanks. This code seems to work:

Code:

walletManager = Cpp.WalletManager('~/.armory')
wallet        = PyBtcWallet().readWalletFile(w)
cppwallet     = walletManager.getCppWallet(wallet.uniqueIDB58)
receive       = wallet.getNextUnusedAddress()
parms         = urllib.urlencode({'amount':'%1.8f'%btc, 'label':comment})
addr          = cppwallet.getP2PKHAddrForIndex(receive.chainIndex)
url           = "bitcoin:%s?%s" % (addr, parms)
wallet.setComment(receive.getAddr160(), fullcomment)

[markle]

Hi Goatpig,Droak,
So I moved the install to Ubuntu via VirtualBox on my Mac, now on 0.96.3. Following some issues with Armory running the Bitcoin Core I did a separate installation of BTC 0.15.*. The armory Database/s are building however the Scan Transaction history fails with the following fault in the armorycpplog.txt "Error - :(StringSockets.cpp:351) FcgiSocket:writeAndRead FcgiError: unexpected fcgi header version".
I made sure there were no armory or bitcoin processes running beforehand, I have also tried to run armory manually. The transaction history gets to about 15% or less before an issue.

I am pretty disappointed about the lack of progress to get my Wallet open :-/

Two questions please...

1. Is there anything else I can try to progress this Transaction History issue ?
2. I am getting to the stage to ask if there is any other Wallet System that could open up my existing armoury wallet.dat ?

Thank you for any advice or input

[gangtraet]

I think the latest Bitcoin Core is incompatible with  0.96.3.  You need to either downgrade Bitcoin Core or upgrade Armory to the release candidate.

[markle]

Thanks gangtraet

[skyhawk]

Is it possible to RBF-bump offline transactions?

I see the "right-click to bump", but when I right-click and select "Bump Fee" nothing happens.  I was hoping/expecting for an offline transaction window to create an updated unsigned transaction....

[goatpig]

Is it possible to RBF-bump offline transactions?

I see the "right-click to bump", but when I right-click and select "Bump Fee" nothing happens.  I was hoping/expecting for an offline transaction window to create an updated unsigned transaction....

Show me your armorylog.txt

[skyhawk]

I've anonymized this log output -- let me know if you need the un-anonymized output, or if you need to see the entire logfile rather than the output from the troubled period.  I'd want a confidential way of getting that to you.

https://pastebin.com/AEtpcSHM

The transaction had 3 Segwit inputs, and one Segwit output (change) and one legacy address output.

Ignore the errors at the top -- I had an issue with the flashdrive, after I realized this and used a different drive I was able to save/sign/broadcast the transaction normally.  I was never able to make RBF work -- no errors or crashes, Armory just didn't do anything when I clicked on "Bump fee" on the context menu.

[goatpig]

I'd want a confidential way of getting that to you.

You can GPG me the thing at the email of my github repo.

This is the pubkey for emails (don't use the offline signing key registered to the same email. This is for offline release signing only):

Code:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQINBFXrA7sBEACyM7MpPE9+H+7YJ94kAu/JZMajOjJaWnw4pb4oiKBu2yMqQQpv
EnRG0t7Qpx/xw+/5bkvyszs9c/Rf9jnSFn7bMEjOwk+cVRIIkhtOG2p2/ZV0d8mw
v5bGTMBIxAhTDY371PzcW42aT+CNEGxeLThHuDauHWVkWxLnYlVabs3oZIBZR2y0
YtVTPSYgI5/XYEQLDze4uwpQuZsvnsCa5doCmX+iJURyUJtFTY3GW/Dx/XqWtQfu
PzRJSGZgxaO40+zOskmbjMerVSjXjEQZlMwzwjB0TR/8Zhu94f1Q98E8W4F4gRXo
X+gcLe0U+zD8rLb7lP99auEw3z8O7Nmxi9sjRN4PoeHB2isshM02j/iL+7qeKpvG
fqZg1yU3Pi4hPqictQGhEpekk/3FxuGWNX5V/PUTeqjfc0aHaYrfRG9ESW59OYnf
QOswdLzrnxyAlmX3cYWOQp4c6vsdbmCMAE4SMhGhIZL4NhxeSoOARR4eB2PNlvIs
u0dCoA6TJLUVVryp0SqnOV5UfUtxCIfyqquYiE5HUFwz418HAVWg+oPEBWp83pp7
kroDgvGF55Q58ZV9Jcx4vHLNFrlo1bVlCY7IZDdFfVJ6scAgiZGcTY+/M5skcaTo
ean9bER4QZ3F6eE+7P9j1p3dPa4Swwy5GQ89+EE3BUYH3kO3F7vXK/pDDQARAQAB
tCJKb2huIERvZSA8bW9vdGhlY293bG9yZEBnbWFpbC5jb20+iQI5BBMBAgAjBQJV
6wO7AhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQIvAz3luFh6JFHw/9
FjT9r2ifgQKbVCoKUzzWGBJ6J5iUTqBClcUXg0DEXa4kCZf9zfCjVL/Cfc5vxPus
WK4f1PT/0Hr0mJBbxTz1yhiePd8zwOfoDVvc8OCPR1FgJRZSItGKl4x3KDWPan76
hrWQyRQTsJ8YLgyzFvkvXhnhsLyY4eTuE3dqlKzWL5Mez+pkvOuYkn+eK2vpC4nK
RzqnN2Okyuu0k6mbnFqxsMevu/IaK6KN9fO5MqIJSLbzqNogUMetyuuXCv80Hw5g
BwrZKQQYhSXZTDAXYBZQ5QdDkcl3ALR+qMBN4ttoQaihJpLPBfdYo2CxgAD+tBjr
/F2YOlZvCCPZFxomncFGXANOQop2h/pRjR88KhLZEYPgob4OsZbbujsZdPJmTwx1
rBvrdEj72Y8PLqtCXM7pze6NtOUbz9qwJc0CXoODHQE7n9ZIkyAp15kzGNEDuN+9
a2aavzJU8KsbRhJ4OMokN6lgsyxfwIqeAZg95dz5fSDg7mSJjBoArlo5kX5s3KDl
QyFkq7pTuVuGer7v2XxATbXt95HrIQzUP8YO0j8Z78xNbHsvwTafmWD9SEyl/Vdu
aECpvXkJ80DPnHsC7L98Dx7snrhABlFqe1hRYThN/5k0Dp7EUI4ETG336QhbmKDN
72XH0gz78x+0RzgFXN5h1wndeyV6SbRM1jpv5Jvfw3e5Ag0EVesDuwEQAMEuHi4f
OdE5dOD9Nb91ftiVrblySbHGjkWrJRgJiUo+jWLsJR1ykPoprNrsvJmbRXs7+tNl
mvDXc9Rd45qbdzpL9Qwsjvhinnw9BGzawivJ08RfrYv86QW6ABu7TJVEy1qKMuK9
Y/yhMe7+DkYn+xACL2alHefdpGYJbCIq1YbAV2hU8+bS52rr5dQyvsvv4NArqKmE
GJiVN+mXksnVtgXvYfhO5Jn/i72WVWYLKpA1JxcluVXDGC6ptn/lJERG9oZsACdU
+t043Poitcrz9jimQD/RRWk9N6X372ys4aeVuVrTl51chOkuyJec/D7PCyxN35P+
I8FSgdtCL3iDl+UdEm3IDXvr4+KXYnJgzCZu3+bV9xwVj6adHf8tOnbAM4yEwnWz
ihZLQu8RTXAGpx0KKVkyFdhdaGTLXntXmLSJSEnmhGYuNKmM9B5d3cklmQ8y9Rqs
ZI1QDD+K74RWeKYlxRDJj29Aezu+W53m5Ol3CkXkEC6ClzAV2JHcFn1kgBaZyc1+
p/XSoSgInwGB+X/aD64dxEgeEuK6uTv/sQMXnWbJLT8XlyHozUO4E23OPU3b9Ssg
keS4ZiPBNXrZPKyqHMxW1J/4HP4jI5aR18jopMO7VTyH8uIt6WYeR540LCSnFCaP
wQv8V4k+Ga3uj0ITEEjCU4IQqt4ByLj5ajkfABEBAAGJAh8EGAECAAkFAlXrA7sC
GwwACgkQIvAz3luFh6Kt5hAAqi+B8Ae1rZOP5SR/ZyjXbB42DUan/R5gmHdi7AIt
3vTKWXJQwFT6Jxy5rS22vwJVd/azi0OxdHSpasqCV45I9oq1ES3//8yOvzhb3d02
7cuh8LTN2iOQgcqjKI8MYMFzP2z7cu4CGYj1wJ2X4L8QbZXA2irzlVT2C6SJ5/Ow
zHJyBCSG3ZkRYUkuIAadK/gZ7hJaDMlkiuvoR1s2SaYm4hTeC0viTDGJFJ9+ReM3
jzEfP8wn0k/95SqFRgMv+38aem6Y1XdU4LHtBGf+3TGrjwPrw2xPmpUXX7tl+6vw
s+60wem8B/8+WCq+11ZLPRdFvqePAQVQolbEVaH8BGHTsQ/wX+L1W8myimkYF4Iq
OTf9wRnfCn/yYZYWwN1UqFsfsRoPKmcY5frIYVV/TnZn9DVfUPE5OKHvR61HglaH
E9aQONQe3u1ZGMmOnvFhFiKTvKRVQgpp4/QoQdptNscU7jB0F2VMOWsfU59u1vWo
phmWZ68P1h/0VgAtqZHcNLmqbrqIn9V9mbPc91yVWhYyoBBlUm9fgXR0pqSi+gGe
5LZTNGd4VhyfETbSAGrKJB7JblIj+dfjcCU2wE87nQAycP569h9dvTPt7huSUFIy
E0Kp1V93yAEr4+UiiheJuNNEPz0rPIDBDVfdP9JH95G2ADLbEUYQ7fxU5gTBMs4+
QdU=
=fgZn
-----END PGP PUBLIC KEY BLOCK-----

[goatpig]

DbErrorMsg: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x00000000074EE1B0> >

Is your DB running? Do you have any Python in you and what OS do you use?

[skyhawk]

Armory is running on Windows.  It's connected via http to ArmoryDB running on an Ubuntu machine.

This Windows install does have a functioning install of Python 2.7.14

[goatpig]

You could help me debug this by writing some lines of Python in there, but this is harder to achieve with Windows than Linux. If you want to process further, email me. I'll be away this weekend btw, so that may take a while.

Ultimately, if you want to speed up that one tx regardless of figuring out what's going with RBF, you could CPFP it (assuming it has change).

[TierNolan]

I realize that in this is fixed in 0.96.4, but I just want to confirm that my backups are ok.  I would rather not use a RC for an actual wallet.

I generated an M of N backup and then printed out the fragments.  When I test the backup, it gives the wrong fragment id.

To confirm, the way to verify the backup is

- enter all N fragments (rather than just M of them)
- say "Yes" when it asks if the fragment id matches (even though it doesn't)
- The actual check is to make sure that the Wallet id matches after reconstruction

[sconklinbtc]

I've just done a fresh install of Armory 0.96.3 on a fresh install of Windows 10 and when I go to change my default address type to segwit, like I previously had before I needed to reinstall windows, the option for P2SH-P2WPKH addresses is greyed out. I'm using this in expert mode as well as running armory as administrator, so I'm unsure what is preventing me from being able to select segwit. Any help to point me in the right direction to correct this would be greatly appreciated. I'm also using bitcoin core 0.15.1 if that helps.

https://imgur.com/a/FElM4

[goatpig]

It's not detecting your node.

[sconklinbtc]

It's not detecting your node.

I must've just been trying to fast while it was doing the initial sync, as it's now scanning for transactions and it's detected as I can select segwit now. Thanks for the quick reply.

[RustyRussell]

Hmm, my vanity-address wallet problems continue

I selected a single UTXO and tried to send MAX with manully-set 135 sat/byte feerate:

Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 871, in createTxAndBroadcast
    finalTx = ustxSigned.getSignedPyTx(signer=self.signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2635, in getSignedPyTx
    raise SignatureError('Invalid signature while preparing final tx')
armoryengine.ArmoryUtils.SignatureError: Invalid signature while preparing final tx

 (ERROR) Transaction.py:1488 - Signature in USTXI is not valid
(ERROR) Transaction.py:2634 - Attempted to prepare final tx, but not all sigs available
(ERROR) TxFrames.py:876 - Problem sending transaction!
Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 871, in createTxAndBroadcast
    finalTx = ustxSigned.getSignedPyTx(signer=self.signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2635, in getSignedPyTx
    raise SignatureError('Invalid signature while preparing final tx')
SignatureError: Invalid signature while preparing final tx
(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 871, in createTxAndBroadcast
    finalTx = ustxSigned.getSignedPyTx(signer=self.signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2635, in getSignedPyTx
    raise SignatureError('Invalid signature while preparing final tx')
SignatureError: Invalid signature while preparing final tx

Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 871, in createTxAndBroadcast
    finalTx = ustxSigned.getSignedPyTx(signer=self.signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2635, in getSignedPyTx
    raise SignatureError('Invalid signature while preparing final tx')
armoryengine.ArmoryUtils.SignatureError: Invalid signature while preparing final tx

It then (I think it was after this) started scanning.  After an hour or so, same error.

This was the encrypted wallet I removed then restored, trying to get it to see that those "Right click to RBF" txs had actually gone through.

[goatpig]

What version are you using? 0.96.3 has some signer issues.

[RustyRussell]

What version are you using? 0.96.3 has some signer issues.

Yep.  Will try downgrading...

[goatpig]

You really want to use the RC for 0.96.4. As for 0.96.3 you can operate it but you have to pick the signer manually, as the default signer detection is botched.

[RustyRussell]

What version are you using? 0.96.3 has some signer issues.

Yep.  Will try downgrading...

0.96.1 has same problem, different error:

(ERROR) TxFrames.py:834 - Problem sending transaction!
Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 828, in createTxAndBroadcast
    ustxSigned = self.wlt.signUnsignedTx(ustx)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 2682, in signUnsignedTx
    ustx.createAndInsertSignatureForInput(idx, addrObj.binPrivKey32_Plain)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2646, in createAndInsertSignatureForInput
    ustxi.createAndInsertSignature(self.pytxObj, sbdPrivKey, hashcode, DetSign)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1398, in createAndInsertSignature
    derSig = self.createTxSignature(pytx, sbdPrivKey, hashcode, DetSign)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1355, in createTxSignature
    raise SignatureError('No PubKey that matches this privKey')
SignatureError: No PubKey that matches this privKey
(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 828, in createTxAndBroadcast
    ustxSigned = self.wlt.signUnsignedTx(ustx)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 2682, in signUnsignedTx
    ustx.createAndInsertSignatureForInput(idx, addrObj.binPrivKey32_Plain)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2646, in createAndInsertSignatureForInput
    ustxi.createAndInsertSignature(self.pytxObj, sbdPrivKey, hashcode, DetSign)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1398, in createAndInsertSignature
    derSig = self.createTxSignature(pytx, sbdPrivKey, hashcode, DetSign)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1355, in createTxSignature
    raise SignatureError('No PubKey that matches this privKey')
SignatureError: No PubKey that matches this privKey

Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 828, in createTxAndBroadcast
    ustxSigned = self.wlt.signUnsignedTx(ustx)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 2682, in signUnsignedTx
    ustx.createAndInsertSignatureForInput(idx, addrObj.binPrivKey32_Plain)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2646, in createAndInsertSignatureForInput
    ustxi.createAndInsertSignature(self.pytxObj, sbdPrivKey, hashcode, DetSign)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1398, in createAndInsertSignature
    derSig = self.createTxSignature(pytx, sbdPrivKey, hashcode, DetSign)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1355, in createTxSignature
    raise SignatureError('No PubKey that matches this privKey')
armoryengine.ArmoryUtils.SignatureError: No PubKey that matches this privKey

[goatpig]

Yeah you want .2 or RC1

[RustyRussell]

Yeah you want .2 or RC1

Didn't work.  Moved the bug to RC1 thread.

[jojo69]

Greetings goatpig

I recently read in the bitcoin wiki

Armory deterministic wallet

Armory has its own Type-2 deterministic wallet format based on a "root key" and a "chain code." Earlier versions of Armory required backing up both the "root key" and "chaincode," while newer versions start deriving the chaincode from the private key in a non-reversible way. These newer Armory wallets (0.89+) only require the single, 256-bit root key. This older format is intended to be phased out in favor of the standard BIP0032 format. [3]

Should users with older format cold storage paper wallets be concerned about not being able to access their coins due to this "phase out"?

[goatpig]

Nothing is ever getting phased out.

[Armory non geek]

TY for your assistance on this question which I think I have now posted to the correct thread:

Now updating a friend's Win 10 computer, which formerly had Armory 0.93.3 and an old Bitcoin core database.  Both of them fully deleted and scrubbed.  


Installed Armory 0.96.3 to his Win 10 off line computer, and also to his on line desktop (Win 10).  Installed the new Bitcoincore 0.15.1
database to the friend's desktop.  Per a successful summer 2017 experiment (re Armory 0.96.0.4 with bitcoin core 0.14.2) I let the BC core 0.15.1 fully sync itself before attempting to sync with Armory 0.96.3.  

Armory 0.96.3 seems to recognize that the BCcore 0.15.1 database might be present, but does not sync properly to the 0.15.1 data base.  

All paperbackups successfully installed into the off line Armory 0.96.3 and watching only copies also indicate correctly to the On Line Armory 0.96.3.  The watching only On Line wallets have been identified as "This Wallet Is Mine" under Wallet Properties (and where the On Line Armory 0.96.3 now correctly indicates Offline Security for each respective "Watching Only copy").  Balance continues to indicate as zero for each of those wallets.  

Is there some other procedure needed to be performed for those wallets to indicate their balances and for Armory 0.96.3 to be fully synced to core datebase 0.15.1  

Each time Armory 0.96.3 is activated it does not update the BCcore 0.15.1 database (which only updates when Armory is closed, and BCcore is separately opened)

TY for your assistance.

[jojo69]

Nothing is ever getting phased out.

Unequivocal and to the point, thank you.

I suspected as much.  Your dedication to this project has earned my enduring respect sir.

[Ente]

Tonight, apparently ArmoryDB crashed. This happened once before, months ago. Both times on 0.96.3.
This is what I got in logs:

armorydb.sh[12614]: -INFO  - 03:34:40: (BlockchainScanner.cpp:852) scanned from block #504582 to #504583
armorydb.sh[12614]: -INFO  - 04:06:12: (BlockchainScanner.cpp:852) scanned from block #504584 to #504586
armorydb.sh[12614]: -INFO  - 04:06:31: (BlockchainScanner.cpp:857) scanned block #504587
armorydb.sh[12614]: -INFO  - 04:28:58: (BlockchainScanner.cpp:857) scanned block #504588
armorydb.sh[12614]: -ERROR - 04:39:33: (BlockchainScanner.cpp:445) Missing file map for output scan, thi...xpected
armorydb.sh[12614]: -ERROR - 04:39:33: (BlockchainScanner.cpp:447) Has the following block files:
armorydb.sh[12614]: -ERROR - 04:39:33: (BlockchainScanner.cpp:449)  --- #1144
armorydb.sh[12614]: -ERROR - 04:39:33: (BlockchainScanner.cpp:451) Was looking for id #1145
armorydb.sh[12614]: terminate called after throwing an instance of 'std::runtime_error'
armorydb.sh[12614]: what():  missing file map

A simple "service armorydb {stop-start}" fixed it (I had to stop it, only a start didn't suffice).

It's a FIY only, it's no hassle for me, and eventually I'll update to 0.96.4 anyway.

Cheers,

Ente

[goatpig]

Can I ask you a few questions about your DB usage and experience in PMs?

[Ente]

Can I ask you a few questions about your DB usage and experience in PMs?

Yes please! :-)

Ente

[Ente]

..happened twice again:

-INFO  - 20:54:37: (BlockchainScanner.cpp:852) scanned from block #506854 to #506855
-INFO  - 20:54:41: (BlockchainScanner.cpp:857) scanned block #506856
-INFO  - 20:54:42: (BlockchainScanner.cpp:857) scanned block #506857
-INFO  - 20:54:43: (BlockchainScanner.cpp:857) scanned block #506858
-INFO  - 20:54:45: (BlockchainScanner.cpp:857) scanned block #506859
-ERROR - 20:54:47: (BlockchainScanner.cpp:445) Missing file map for output scan, this is unexpected
-ERROR - 20:54:47: (BlockchainScanner.cpp:447) Has the following block files:
-ERROR - 20:54:47: (BlockchainScanner.cpp:449)  --- #1162
-ERROR - 20:54:47: (BlockchainScanner.cpp:451) Was looking for id #1165

At least in this cae, it seems like my machine was offline (unrelated to armory) and went online (I have to pull the ethernet cable once in a while). That's why it found the blocks so fast.

Cheers,

Ente

[goatpig]

Does it use a SSD or a HDD?

[Ente]

Does it use a SSD or a HDD?

SSD for OS and program files, HDD for core blockchain and armory db.

Ente

[goatpig]

HDD for core blockchain and armory db.

That's your culprit.

[Ente]

HDD for core blockchain and armory db.

That's your culprit.

Sorry, doesn't seem to be the hdd. It's a btrfs filesystem, I scrubbed it, shows zero errors. Nothing in syslog neither.

Ente

[goatpig]

It's not a matter of filesystem so much as cost of flushing. The DB looks for data on disk after it receives notification for a new block from the node. The node may not have been done flushing the data on disk by the time it has pushed the block over the P2P.

[alomar]

i'm trying to print out a list of all private keys and especially imported private keys to move to another wallet.  when i go to "Backup this Wallet" and "Export Key Lists", i don't see a display of all the individual private keys like i used to.  could this be b/c i'm working with a "Restored" wallet?

[goatpig]

i'm trying to print out a list of all private keys and especially imported private keys to move to another wallet.  when i go to "Backup this Wallet" and "Export Key Lists", i don't see a display of all the individual private keys like i used to.  could this be b/c i'm working with a "Restored" wallet?

You'd have to elaborate on  what you mean by "Restored". Did you restore this wallet from the private root? What makes you think you have imports in there?

[alomar]

i'm trying to print out a list of all private keys and especially imported private keys to move to another wallet.  when i go to "Backup this Wallet" and "Export Key Lists", i don't see a display of all the individual private keys like i used to.  could this be b/c i'm working with a "Restored" wallet?

You'd have to elaborate on  what you mean by "Restored". Did you restore this wallet from the private root? What makes you think you have imports in there?

yes, a restore from the private root.  yeah, i guess i forgot about that part about imported keys not being included in that restore method.  but i don't even see the native keys whereas i have before.

[goatpig]

but i don't even see the native keys whereas i have before.

It won't show you addresses that aren't used nor requested. You need to extend the address chain, request new addresses or sync the wallet.

[alomar]

confused about something.  for a long while i've been working with the std Armory wallet with one imported key. i'd like to get rid of that imported key.

since there doesn't seem to be a way to delete that single imported key, i decided to do a Restore of my offline wallet using the root seed.  i then made a new watching only wallet which i then imported into my online Armory (after deleting the existing watching wallet) expecting it to display without the imported key.  yet when i go into Coin Control, i still see this imported key with a balance in it.  how does this happen?

[goatpig]

If you restore on top of an existing wallet, you get the option to recover the meta data from the existing one (comments, address chain length, imports). This is the most likely explanation. You can delete imports from a wallet, but you have to be in Expert User mode.

[alomar]

If you restore on top of an existing wallet, you get the option to recover the meta data from the existing one (comments, address chain length, imports). This is the most likely explanation. You can delete imports from a wallet, but you have to be in Expert User mode.

are you talking about the offline or online wallet?

[goatpig]

Applies to both.

[alomar]

Applies to both.

then that's weird b/c i deleted the old WO wallet from Armory first before importing the restored new one.  that should have deleted the imported key.  but it's still there while the comments are not...

[alomar]

You can delete imports from a wallet, but you have to be in Expert User mode.

i've been in Expert Mode.  i don't see an option to delete an imported key anywhere...

[goatpig]

https://imgur.com/a/v7Tlz

[alomar]

https://imgur.com/a/v7Tlz

there must be a bug somewhere.  

as you can see in the same section in my wallet, there is no Imported Addresses category nor the Remove Import Address command over on the right (which is expected if Armory isn't detecting an imported address, i guess):  

https://i.imgur.com/C9mNWEs.png

yet, when i open Coin Control, i plainly see the imported address with it's balance.

using 0.96.3.992 in expert mode

[goatpig]

How did you restore this wallet?

[alomar]

How did you restore this wallet?

i described it above

[goatpig]

I need more detail. What was the state of your offline instance when you restored? Was this particular wallet there?

EDIT: did you cycle the .lmdb mirror wallet file?

[PhoenixFire]

https://imgur.com/a/v7Tlz

there must be a bug somewhere.  

as you can see in the same section in my wallet, there is no Imported Addresses category nor the Remove Import Address command over on the right (which is expected if Armory isn't detecting an imported address, i guess):  

https://i.imgur.com/C9mNWEs.png

yet, when i open Coin Control, i plainly see the imported address with it's balance.

using 0.96.3.992 in expert mode

As far as I know, the option doesn't appear for a watch only wallet. Is that the case here?
Scratch that, missed some info. Strange issue!

[alomar]

I need more detail. What was the state of your offline instance when you restored? Was this particular wallet there?

EDIT: did you cycle the .lmdb mirror wallet file?

no, Armory offline was devoid of any and all wallets prior to the restore. 

after signing, i always delete/remove the wallet in the GUI, nothing more.

[goatpig]

after signing, i always delete/remove the wallet in the GUI, nothing more.

On the online side?

[alomar]

after signing, i always delete/remove the wallet in the GUI, nothing more.

On the online side?

same thing.  deleted online wallet first before importing new restored WO wallet.  Armory even labels it as a "Restored" wallet in the description.  again, the bizarre thing is that when i open Wallet Properties, the imported key is NOT listed nor is the "Imported Key" key category even displayed, as i showed in that screenshot above.  but i still see it in Coin Control with a balance.  i can even construct a tx with it.  but it won't sign on the offline wallet b/c the imported private key has been successfully deleted on that pc.

[goatpig]

What I am asking is whether you delete the .lmdb mirror wallet files in the Armory datadir at all.

[alomar]

What I am asking is whether you delete the .lmdb mirror wallet files in the Armory datadir at all.

no, why?  what does that do?

[goatpig]

What I am asking is whether you delete the .lmdb mirror wallet files in the Armory datadir at all.

no, why?  what does that do?

It's a watching only copy of your wallet used to interface with the DB. This most likely still has the imported public key in it, which is why the DB returns those UTXO in coin control.

[alomar]

What I am asking is whether you delete the .lmdb mirror wallet files in the Armory datadir at all.

no, why?  what does that do?

It's a watching only copy of your wallet used to interface with the DB. This most likely still has the imported public key in it, which is why the DB returns those UTXO in coin control.

looking inside user@Ubuntu:~/.armory$ , i see these wallets:

armory_IekLiRmn_wallet.lmdb
armory_IekLiRmn_wallet.lmdb-lock

but those ID's numbers don't match the imported WO wallet ID number that has the imported private key.

[goatpig]

These are the one. The .lmdb wallets do not carry the same file ID cause the ID is built differently. You can nuke any .lmdb (and lock files) file with anything prior to 0.97 (this is to future proof this comment) as they are built on the fly WO copies of the python wallets.

[alomar]

These are the one. The .lmdb wallets do not carry the same file ID cause the ID is built differently. You can nuke any .lmdb (and lock files) file with anything prior to 0.97 (this is to future proof this comment) as they are built on the fly WO copies of the python wallets.

ok, that killed it.  thanks.

[Ente]

I imported a new address in 0.96.3, scanning hangs close to finished:

ArmoryDB:

(BlockchainScanner.cpp:852) scanned from block #514744 to #515526

ArmoryQt:

-ERROR - �Q��o: (BinaryData.h:563) odd hexit count
-ERROR - �Q��o: (SwigClient.cpp:61) odd hexit count

I restarted both a few times, always the same. Around half an hour scanning, then it hangs in Qt, and wouldn't show a time estimate any more after restarting Qt.

Well, first time I have a computer problem where I literally find noone with the same problem before, yay! :-)

Ente

[goatpig]

I imported a new address in 0.96.3, scanning hangs close to finished:

Have you tried with 0.96.4?

[Ente]

I imported a new address in 0.96.3, scanning hangs close to finished:

Have you tried with 0.96.4?

Not yet, as it's an RC.
If you have no other suggestions, I'll upgrade and recheck.

Ente

[goatpig]

I've tagged 0.96.4, there just aren't builds for it yet.

[Ente]

Ah, neat!
I upgraded both ArmoryDB and ArmoryQt to 0.96.4, still the exact same messages and scanning never finishes..

Ente

[alomar]

i also tried building from the 0.96.4 source but run into this error upon "make":

Code:

user@user-VirtualBox:~/Downloads/BitcoinArmory-0.96.4$ make
Making all in cppForSwig
make[1]: Entering directory '/home/user/Downloads/BitcoinArmory-0.96.4/cppForSwig'
Making all in lmdb
make[2]: Entering directory '/home/user/Downloads/BitcoinArmory-0.96.4/cppForSwig/lmdb'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/user/Downloads/BitcoinArmory-0.96.4/cppForSwig/lmdb'
Making all in fcgi
make[2]: Entering directory '/home/user/Downloads/BitcoinArmory-0.96.4/cppForSwig/fcgi'
make[2]: *** No rule to make target 'all'.  Stop.
make[2]: Leaving directory '/home/user/Downloads/BitcoinArmory-0.96.4/cppForSwig/fcgi'
Makefile:1538: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/user/Downloads/BitcoinArmory-0.96.4/cppForSwig'
Makefile:413: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

[Holliday]

Ah, neat!
I upgraded both ArmoryDB and ArmoryQt to 0.96.4, still the exact same messages and scanning never finishes..

Ente

Did you happen to delete the armory/databases folder after updating and try the new version from scratch?

[goatpig]

Ah, neat!
I upgraded both ArmoryDB and ArmoryQt to 0.96.4, still the exact same messages and scanning never finishes..

Ente

I need to see the full Qt log.

[goatpig]

i also tried building from the 0.96.4 source but run into this error upon "make":

Code:

git submodule init
git submodule update
sh autogen.sh
./configure
make clean
make -j8
sudo make install

[Ente]

i also tried building from the 0.96.4 source but run into this error upon "make":

Code:

user@user-VirtualBox:~/Downloads/BitcoinArmory-0.96.4$ make
Making all in cppForSwig
make[1]: Entering directory '/home/user/Downloads/BitcoinArmory-0.96.4/cppForSwig'
Making all in lmdb
make[2]: Entering directory '/home/user/Downloads/BitcoinArmory-0.96.4/cppForSwig/lmdb'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/user/Downloads/BitcoinArmory-0.96.4/cppForSwig/lmdb'
Making all in fcgi
make[2]: Entering directory '/home/user/Downloads/BitcoinArmory-0.96.4/cppForSwig/fcgi'
make[2]: *** No rule to make target 'all'.  Stop.
make[2]: Leaving directory '/home/user/Downloads/BitcoinArmory-0.96.4/cppForSwig/fcgi'
Makefile:1538: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/user/Downloads/BitcoinArmory-0.96.4/cppForSwig'
Makefile:413: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

before

sh autoconfigure.sh

do

git submodule init
git submodule update

edit: oops, didn't notice the new thread page.

Cheers,

Ente

[Ente]

Ah, neat!
I upgraded both ArmoryDB and ArmoryQt to 0.96.4, still the exact same messages and scanning never finishes..

Ente

I need to see the full Qt log.

Is ArmoryQT --debug enough? Nothing more to see, afaik:

(INFO) ArmoryQt.py:566 - Usermode: Expert
(INFO) ArmoryQt.py:1698 - Changing usermode:
(INFO) ArmoryQt.py:1699 -    From: Expert
(INFO) ArmoryQt.py:1707 -      To: Expert
(INFO) ArmoryQt.py:1836 - startBitcoindIfNecessary
(WARNING) ArmoryQt.py:1826 - DB is already running
(INFO) ArmoryQt.py:1924 - Setting netmode: 1
-ERROR - : (BinaryData.h:563) odd hexit count
-ERROR - : (SwigClient.cpp:61) odd hexit count
(INFO) ArmoryQt.py:1924 - Setting netmode: 0
(INFO) ArmoryQt.py:1906 - loadBlockchainIfNecessary
(INFO) ArmoryQt.py:4673 - Dashboard switched to "Scanning" mode
(INFO) ArmoryQt.py:4673 - Dashboard switched to "Scanning" mode

Cheers,

Ente

[goatpig]

I gather you're getting to load the client before it gets to that stage, right? Have you tried deleting the .lmdb mirror files? Also, consider running the wallet through the recovery tool in full mode.

[alomar]

i also tried building from the 0.96.4 source but run into this error upon "make":

Code:

git submodule init
git submodule update
sh autogen.sh
./configure
make clean
make -j8
sudo make install

since i don't use git, how can i accomplish the same thing?  i merely downloaded the source code tarball zip directly from your github, unpacked, and ran the standard commands.

[goatpig]

since i don't use git, how can i accomplish the same thing?  i merely downloaded the source code tarball zip directly from your github, unpacked, and ran the standard commands.

Which source? The link called "Source Code"? That's an automated tarball put together by GitHub, which somehow skips submodules (don't ask why, I wish I knew). You want to use the signed sources. There is only a signed tag for 0.96.4 atm, so you'd have to use git to procure that code. There's a signed source for RC3 however:

https://github.com/goatpig/BitcoinArmory/releases/download/v0.96.3.992/armory_0.96.3.992_src.tar.gz

[Ente]

I gather you're getting to load the client before it gets to that stage, right? Have you tried deleting the .lmdb mirror files? Also, consider running the wallet through the recovery tool in full mode.

I removed the two new wallets (one imported watch-only, one freshly created with one imported address), and removed all .lmdb and .lmdb-lock files. And I checked all wallets on "full recovery", no errors found.
Still same behavior.
Like, now, I only have my ages old walletsagain, and still have the "odd hexit count" errors in Qt.

edit: restarting ArmoryDB, and everything works with the old wallets only. I'll check a few combinations of wallets, files, scans, and will report back.

Is this a wallet problem? And/or a Qt problem? Or a DB problem? DB seems to start scanning from the beginning every time too.

Ente

[goatpig]

I'm thinking it's a Qt problem.

[Ente]

So, with the newly generated wallet including one imported address, it scans history for an hour, then DB hangs, at -30secs, with

(BlockchainScanner.cpp:852) scanned from block #514744 to #515526

as the last line in dbLog.txt. I can't get a Qt connection any more after restarting Qt, no matter what wallets it has loaded.
After restarting DB, Qt connects fine and loads wallets and tx instantly.

With the watch-only wallet newly added, exactly the same as above.

To triplecheck, after removing those wallets again, I created a fresh wallet while not connected to DB. Restarting DB and then Qt, it starts scanning history. Everything again the same, seconds before finishing it hangs DB and Qt. This time I got ever-repeating errors in Qt:

(python:7717): Gtk-CRITICAL **: IA__gtk_progress_configure: assertion 'value >= min && value <= max' failed
-ERROR - : (BinaryData.h:563) odd hexit count
-ERROR - }: (BinaryData.h:563) odd hexit count
-ERROR - : (BinaryData.h:563) odd hexit count
-ERROR - }: (BinaryData.h:563) odd hexit count

Well, I have no clue how to go on from here?

Ente

[goatpig]

To triplecheck, after removing those wallets again, I created a fresh wallet while not connected to DB. Restarting DB and then Qt, it starts scanning history. Everything again the same, seconds before finishing it hangs DB and Qt. This time I got ever-repeating errors in Qt:

You mean the DB hangs even without any imports?

[Ente]

To triplecheck, after removing those wallets again, I created a fresh wallet while not connected to DB. Restarting DB and then Qt, it starts scanning history. Everything again the same, seconds before finishing it hangs DB and Qt. This time I got ever-repeating errors in Qt:

You mean the DB hangs even without any imports?

These symptoms happen with creating a new plain armory-wallet via GUI, yes. Nothing imported, neither the wallet itself nor any single address.
Of course I kept Armory offline when creating the wallet, so it would start a full rescan when being online, reaching DB again.

Ente

[goatpig]

Start the DB on its own (no GUIs), how far does it get? Try and post the last 10 lines of the dbLog.

[Ente]

ArmoryDB is running by itself on its own headless host.
Restarting the ArmoryDB service runs just fine, the last dbLog.txt entries are:

-WARN  - 16:13:54: (BDM_supportClasses.cpp:1944) running 35 zc parser threads
-INFO  - 16:21:05: (BlockchainScanner.cpp:857) scanned block #518330
-INFO  - 16:21:26: (BlockchainScanner.cpp:857) scanned block #518331

Starting ArmoryQt on a remote machine:
(again, dbLog.txt)

-INFO  - 16:28:37: (BDM_Server.cpp:1121) registered bdv: a*****0
-INFO  - 16:28:38: (BDM_supportClasses.cpp:401) Starting address registration process
-INFO  - 16:28:43: (BlockchainScanner.cpp:852) scanned from block #0 to #142691
[..]

and then, finally:

-INFO  - 17:11:48: (BlockchainScanner.cpp:852) scanned from block #514744 to #515526

As the last line, from then on ArmoryDB hangs.

ArmoryQt says:

(INFO) ArmoryQt.py:4673 - Dashboard switched to "Scanning" mode
-ERROR - : (BinaryData.h:563) odd hexit count

(scanning comes a few hundred times, then the hexit error several times a second)

Ente

[goatpig]

The DB runs fine. The issue is the client. Do you have comments in that wallet, written in a non ASCII locale?

[Ente]

To remove factors, I tried again:

- removed all wallets, ArmoryQt starts fine in online mode
- created a new wallet, it's online immediately
- shut down Qt and DB
- started Qt, created a new wallet with password, nothing else changed or touched (in offline mode)
- shutdown Qt
- started DB, then Qt
- Qt starts scanning

(INFO) ArmoryQt.py:4673 - Dashboard switched to "Scanning" mode
(python:14412): Gtk-CRITICAL **: IA__gtk_progress_configure: assertion 'value >= min && value <= max' failed

"Scanning" comes around every 5 secs, that Gtk warning came only once. Nothing else for an hour scanning.

At "35 sec left", the last DBlog.txt line is

-INFO  - 12:29:15: (BlockchainScanner.cpp:852) scanned from block #514744 to #515526

(which is not the current blockheight)

and Qt says

-ERROR - : (BinaryData.h:563) odd hexit count

over and over.

After restarting Qt, I can't connect to DB any more, I have to restart the service.

tl;dr: a single fresh plain wallet, nothing changed, nor commented, and Qt hangs.

Oh, maybe it has something to do with a recent upgrade to Debian 9? I probably didn't import/rescan since then.
But I did install/compile v0.96.4, which threw no errors.

Ente

[goatpig]

To remove factors, I tried again:

- removed all wallets, ArmoryQt starts fine in online mode
- created a new wallet, it's online immediately
- shut down Qt and DB
- started Qt, created a new wallet with password, nothing else changed or touched (in offline mode)
- shutdown Qt
- started DB, then Qt
- Qt starts scanning

(INFO) ArmoryQt.py:4673 - Dashboard switched to "Scanning" mode
(python:14412): Gtk-CRITICAL **: IA__gtk_progress_configure: assertion 'value >= min && value <= max' failed

"Scanning" comes around every 5 secs, that Gtk warning came only once. Nothing else for an hour scanning.

At "35 sec left", the last DBlog.txt line is

-INFO  - 12:29:15: (BlockchainScanner.cpp:852) scanned from block #514744 to #515526

(which is not the current blockheight)

and Qt says

-ERROR - : (BinaryData.h:563) odd hexit count

over and over.

After restarting Qt, I can't connect to DB any more, I have to restart the service.

tl;dr: a single fresh plain wallet, nothing changed, nor commented, and Qt hangs.

Oh, maybe it has something to do with a recent upgrade to Debian 9? I probably didn't import/rescan since then.
But I did install/compile v0.96.4, which threw no errors.

Ente

Send me one of those fresh, broken wallets.

[Ente]

Send me one of those fresh, broken wallets.

E-mail sent.

Ente

[Ente]

I started over with a freshly installed Debian 9, and then with again with a completely empty .armory folder too. v0.96.4, local ArmoryQT connecting to remote ArmoryDB.
Again, the same symptoms, it stops scanning at "one minute left" with those hexit errors.

I did everything exactly like always, with dependencies and commands from old written down notes.
So it can only be something broken at my ArmoryDB, or a general imcompatibility with the Qubes OS Debian VM templates, or a networking problem in between?

Ente

[Ente]

Next, I used a fresh Debian 8 for ArmoryQt. Still "hexit" errors.
Then I installed a fresh Debian 9 on a physical machine (instead of the VMs before). Just installed ArmoryQt, nothing else. And, again, scanning for a new wallet never ends in ArmoryQt, with "hexit" errors.
So it must be ArmoryDB after all?
Any ideas what to do? I did upgrade ArmoryDB before, no change. The last thing I didn't do yet is delete the ArmoryDB database?

Ente

[Carlton Banks]

The last thing I didn't do yet is delete the ArmoryDB database?

Try that. I had a similar sounding problem to yours, solved when I nuked the database files and rebuilt from zero.

[goatpig]

Been away for a couple weeks. You should nuke your DB and start from scratch, I'll try on a Debian9 VM in the meantime. Lastly, can you try with the testnet instead?

[Ente]

Hope you had a good time, whatever you were up to, goatpig.

What can I say, I removed the armorydb database folder, let it rescan, and it now seems to work! Previously unknown wallets scan and show their (empty) balance.
I'll test some more scenarios, but for now it's solved.

Thank you for staying with me!

Ente