Bitcoin Forum

Binaries:

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

Changelog:


Notes:

SegWit lockboxes use compressed keys as opposed to the legacy ones, therefor they are sensibly smaller while also being a whole lot cheaper. Users looking to try them out should test around on testnet first.

Linux users that were having trouble with older CPUs, try the noasm .deb

Damn, you are on fire! :-)

Interesting, now I might connect armory-db and armory-qt directly via FCGI? I was under the impression this is not the suggested way, and to always have some ngnix or comparable in between?

Cheers,

Ente

This is a convenience change to let people connect within their LAN without the need of running a HTTP deamon. Makes the setup simpler basically. DO NOT use this to expose your DB to the WAN, that's a bad idea through and through. I still believe you should use the proper setup within your own LAN, i.e. DB locked on localhost -> nginx -> LAN -> clients, but at this point it's nitpicking, so there you go, easier setup options.

Just FYI, this is the first OSX build using the latest tools (Command Line Tools 9.0 on macOS 10.13). Hopefully this will solve certain issues. If not, post logs and such here. Just remember, as always, you'll need to make sure that GateKeeper lets the binary execute! I believe that, with 10.13, you no longer need to unlock the settings. You can just push a button that allows the binary to run after macOS catches it the first time.

is there a way to run an offline version of this?  i'm still having issues getting 0.96.2 to work offline.

As per the post, give that one a whirl. If you've already installed the psutil dependency from a previous offline package this should work.

in years past, i've always DL'd specific "offline" versions for each release.  is that not the case anymore?  the last specific one i see is for 0.96.2 here: https://btcarmory.com/0.96.2-release/

Offline just means the binary is bundled with the dependencies required to setup up Armory on a fresh install of the target OS. The build does not change.

Just installed 0.96.3.99 (noasm version) on Kubuntu and running core 0.15.
Imported my old Armory wallet files and the balances show up as 0.0.

Any pointers how I can fix this?

Wait until both bitcoin-core and armory are fully synced. Check the lower right corner of armory for status (offline, online, synced until what block).

Ente

Unless things have changed recently, I believe the user may also need to generate some extra addresses if they've used a lot of them. (I forget the default number generated.)

Armory signaled 'Armory is online!' while bitcoin-core was still syncing.
That made me confused, looks like all is fine now.

Is there any advantage of using FCGI over not using it?

Both bitcoin-core and Armory use HD-wallets, i.e. an infinite stream of deterministic addresses are created from one seed in the wallet.
No pre- or recreation of addresses any more, no periodic backups needed because new addresses would not be in the old backup.

Ente

Comparing FCGI to what?

FCGI or nothing:
You only need FCGI for connecting a remote armorydb with armoryqt.

FCGI or http-server in between:
Not exposing the FCGI directly, but having a http server in between (on the same machine as armorydb) is a security plus.

Ente

ok, got it setup on offline pc.  but where did the "compute new addresses" button go in the Wallet Properties window?

FCGI vs HTTP security yes. Is HTTPS supported any?

having consistent freezing with Coin Control after initiating a single successful BCH tx with Coin Control.  no response upon click with entire GUI freezing.  this also happened in 0.96.1.  rebooting ArmoryQt nor the entire VM helps.

the only user improvement would be to have a sortable/find address button for Coin Control.  with thousands of UTXO's to choose from, it's laborious trying to find specific one's for multi input tx's.

maybe also an option button to disable "mirroring" of wallets in offline bundle for when you only want to do a legacy tx.  it takes a few minutes.

*using Debian in Vbox VM with truncated blockchain disconnected from bitcoind attempting to claim BCH.

Coin Control always freezes at the *second* tx after initial install, not the first.  does this help?:

No, these are GUI false positives. There was someone with your exact isssue before. He restored his wallet from the root key and it fixed it (i.e. this is an issue with the state of the wallet file). I could fix it if you showed me a WO copy, but I don't expect to get one (users ought to protect their privacy).

care to explain how this is done? i'd like to fix mine too.

Create a paper backup, test it, then delete your wallet and restore from the backup.

but this is occurring on the online pc in the WO wallet during Coin Control selection.  am i missing something?

Delete your WO and import a fresh one.

didn't work for me:

1. deleted offline wallet
2.  restored from paper backup
3.  exported WO wallet
4.  restored WO wallet to online pc
5.  no luck with frozen Coin Control

edit:  nvm, i see what you're saying now.  didn't realize you could export a paper WO root key and restore, all on the online pc, w/o touching the offline wallet.  will try that.

suddenly, everything's good and working.

Hi , I am using this version of release and my my blockchain is completely downloaded and then my scanning transaction history comes to like 98% and gets stuck , it has been running for 2 days now and still stuck at the same time , when i export the log file it says :
:22:08 (INFO) -- ArmoryQt.py:1687 - Changing usermode:
2017-10-02 18:22:08 (INFO) -- ArmoryQt.py:1688 -    From: Advanced
2017-10-02 18:22:08 (INFO) -- ArmoryQt.py:1696 -      To: Advanced
2017-10-02 18:22:08 (INFO) -- ArmoryQt.py:1825 - startBitcoindIfNecessary
2017-10-02 18:22:08 (INFO) -- ArmoryQt.py:1861 - setSatoshiPaths
2017-10-02 18:22:08 (INFO) -- SDM.pyc:169 - Found bitcoind in the following places:
2017-10-02 18:22:08 (INFO) -- SDM.pyc:171 -    C:\Program Files\Bitcoin\daemon\bitcoind.exe
2017-10-02 18:22:08 (INFO) -- SDM.pyc:173 - Using: C:\Program Files\Bitcoin\daemon\bitcoind.exe
2017-10-02 18:22:08 (INFO) -- SDM.pyc:337 - Called startBitcoind
2017-10-02 18:22:08 (INFO) -- ArmoryUtils.pyc:667 - Executing popen: ['C:\\Program Files\\Bitcoin\\daemon\\bitcoind.exe', u'-datadir=C:\\Users\\Morpheus\\AppData\\Roaming\\Bitcoin\\']
2017-10-02 18:22:09 (INFO) -- SDM.pyc:450 - PID of bitcoind: 12828
2017-10-02 18:22:09 (INFO) -- SDM.pyc:451 - PID of armory:   6092
2017-10-02 18:22:09 (INFO) -- ArmoryUtils.pyc:667 - Executing popen: ['.\\guardian.exe', '6092', '12828']
2017-10-02 18:22:12 (INFO) -- ArmoryQt.py:1861 - setSatoshiPaths
2017-10-02 18:22:12 (WARNING) -- SDM.pyc:403 - Spawning DB with command:./ArmoryDB.exe --db-type="DB_FULL" --cookie --satoshi-datadir="C:\Users\Morpheus\AppData\Roaming\Bitcoin\" --datadir="C:\Users\Morpheus\AppData\Roaming\Armory\" --dbdir="C:\Users\Morpheus\AppData\Roaming\Armory\databases"
2017-10-02 18:22:12 (INFO) -- ArmoryUtils.pyc:667 - Executing popen: ['./ArmoryDB.exe', '--db-type="DB_FULL"', '--cookie', u'--satoshi-datadir="C:\\Users\\Morpheus\\AppData\\Roaming\\Bitcoin\\"', '--datadir="C:\\Users\\Morpheus\\AppData\\Roaming\\Armory\\"', u'--dbdir="C:\\Users\\Morpheus\\AppData\\Roaming\\Armory\\databases"']
2017-10-02 18:22:15 (INFO) -- ArmoryQt.py:1813 - Connecting on port 54321
2017-10-02 18:22:15 (INFO) -- ArmoryQt.py:1913 - Setting netmode: 1
2017-10-02 18:22:15 (INFO) -- ArmoryQt.py:1895 - loadBlockchainIfNecessary
2017-10-02 18:22:15 (ERROR) -- ArmoryQt.py:1194 - 19 attempts to load blockchain failed.  Remove mempool.bin.
2017-10-02 18:22:15 (ERROR) -- ArmoryQt.py:1199 - File mempool.bin does not exist. Nothing deleted.
2017-10-02 18:22:15 (INFO) -- ArmoryQt.py:1913 - Setting netmode: 1
2017-10-02 18:22:15 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-10-02 18:22:15 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-10-02 18:22:15 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-10-02 18:22:15 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-10-02 18:22:16 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-10-02 18:22:16 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-10-02 18:22:16 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-10-02 18:22:16 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-10-02 18:22:17 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode

post dbLog.txt

I fail to send BCH from a lockbox. I am connected to my node (Bitcoin ABC), started the Armory DB from scratch, selected the BCH signer, and disabled RBF. When I send a transaction (either directly in the dialog, or after exporting -> exporting as hex -> importing on http://blockdozer.com/insight/tx/send) I get the error that SIGHASH_FORKID is not used.

Bitcoin ABC:
2017-10-09 18:39:50 Misbehaving: 127.0.0.1:43462 peer=0 (0 -> 100) reason: mandatory-script-verify-flag-failed (Signature must use SIGHASH_FORKID) BAN THRESHOLD EXCEEDED

Blockdozer:
64: non-mandatory-script-verify-flag (Signature must use SIGHASH_FORKID). Code:-26

2017-10-09 20:39:50 (INFO) -- (PPRINT from /usr/bin/../lib/armory/ArmoryQt.py:3118)

  01000000 025661a7 bba1588e 2085052f be725eeb e0afb382 d152ffd4 7aafa8e9
  a831bf82 81000000 00fd5c01 00473044 02203fb9 6d77b6ee e47c82a1 55dfc3c4
  7b89cfc9 17c469d8 85c83c16 f1320c0a f8940220 7ed35215 d943badc 28c5e15e
  b01a001a 1a624d1d f44b4fff 333358b9 25cdb042 01473044 02203852 5fc553a8
  d134f200 9d520bf2 9c87b096 7cfaea7c db043a0d 0f6b135b f7140220 26315e4d
  88edabc7 6b39241e 6f7ea4bd 95af0c8a 31c6c497 9006724a bed70450 014cc952
  410434be 1ffcac1c fdea8f80 01e31af2 75a2b2b1 2c00461d 2727fc30 ef025116
  ba918c78 31d23bb5 bb52ef60 d098b82c d9275391 934e2fa7 24f641b5 a8f51549
  2c8d4104 a3b81cc8 fde26d66 5c11133f a6e0e562 c80122d0 fd6d25b7 9cc1478a
  7ad77d06 b403565b 0a016a6b 971c664d 686bd590 f1bd4d08 982909b1 3d45128c
  39e22bbd 4104ce75 f88b933d 0cdc647a 28d24547 0481a6b3 8caa1720 ba143fe8
  94d49c54 6a4eecc8 5b5e817a 1dda3fbb fbe5dbb7 0b83294c c9c617cd 27f1eff3
  e50ef043 0c0453ae ffffffff 2c5ce43c 90a0a120 2196b660 d48b5085 70ff1e8a
  b5ac03fd 4864cb77 8a09d3b3 00000000 fd5e0100 48304502 2100c808 7a7e467e
  3c10faef a32fd620 67ab5003 ff0bfc1f eceecb38 e6906277 eb2b0220 7b28db72
  7a1fe783 f15a5b04 93c49391 990017fb 88d9a7d5 d2498c27 c71ac6d6 01483045
  022100ff c7d05f2f e891cde2 06d5e725 8505cc2c 995eaccb f7791e07 5846e8b4
  931d2402 20158177 42b8d1b5 f1abe051 21ca5abd 390b2e82 9b3d9af5 3ed9240e
  7f307937 d9014cc9 52410434 be1ffcac 1cfdea8f 8001e31a f275a2b2 b12c0046
  1d2727fc 30ef0251 16ba918c 7831d23b b5bb52ef 60d098b8 2cd92753 91934e2f
  a724f641 b5a8f515 492c8d41 04a3b81c c8fde26d 665c1113 3fa6e0e5 62c80122
  d0fd6d25 b79cc147 8a7ad77d 06b40356 5b0a016a 6b971c66 4d686bd5 90f1bd4d
  08982909 b13d4512 8c39e22b bd4104ce 75f88b93 3d0cdc64 7a28d245 470481a6
  b38caa17 20ba143f e894d49c 546a4eec c85b5e81 7a1dda3f bbfbe5db b70b8329
  4cc9c617 cd27f1ef f3e50ef0 430c0453 aeffffff ff014277 fb040000 00001976
  a9141a33 d9d2aa52 d4ff6425 f9e98f5f c6686588 6a6588ac bd8a0700
2017-10-09 20:39:50 (INFO) -- (PPRINT from /usr/bin/../lib/armory/ArmoryQt.py:3119)
Transaction:
   TxHash:    1eb2421b07620977a49c2b2a9ab1ac4dbb4f057b1424bfdf84f9b50cf40a1ba8 (BE)
   Version:   1
   nInputs:   2
   nOutputs:  1
   LockTime:  494269
   Inputs:
      PyTxIn:
         PrevTxHash: 8182bf31a8e9a8af7ad4ff52d182b3afe0eb5e72be2f0585208e58a1bba76156 (BE)
         TxOutIndex: 0
         Script:     (0047304402203fb96d77b6eee47c82a155dfc3c47b89cfc917c469d885c83c16)
         Sender:     33Rsw83aYK9ChQx68C1aXxaJb5j5LzyLhw
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: b3d3098a77cb6448fd03acb58a1eff7085508bd460b6962120a1a0903ce45c2c (BE)
         TxOutIndex: 0
         Script:     (00483045022100c8087a7e467e3c10faefa32fd62067ab5003ff0bfc1feceecb)
         Sender:     33Rsw83aYK9ChQx68C1aXxaJb5j5LzyLhw
         Seq:        4294967295
   Outputs:
      TxOut:
         Value:   83588930 (0.8358893)
         Script:  OP_DUP OP_HASH160 (13PYgef5Lsbhnk2D3W6z8zHiHiaAeHRdyp) OP_EQUALVERIFY OP_CHECKSIG

2017-10-09 20:39:50 (INFO) -- ArmoryQt.py:3124 - Sending Tx, a81b0af40cb5f984dfbf24147b054fbb4dacb19a2a2b9ca4770962071b42b21e
2017-10-09 20:39:50 (INFO) -- ArmoryQt.py:3138 - Failed to broadcast Tx through P2P
2017-10-09 20:39:50 (ERROR) -- ArmoryQt.py:3159 - Transaction was not accepted by the Satoshi client
2017-10-09 20:39:50 (ERROR) -- ArmoryQt.py:3160 - Raw transaction:
2017-10-09 20:39:50 (ERROR) -- (PPRINT from /usr/bin/../lib/armory/ArmoryQt.py:3161)

  01000000 025661a7 bba1588e 2085052f be725eeb e0afb382 d152ffd4 7aafa8e9
  a831bf82 81000000 00fd5c01 00473044 02203fb9 6d77b6ee e47c82a1 55dfc3c4
  7b89cfc9 17c469d8 85c83c16 f1320c0a f8940220 7ed35215 d943badc 28c5e15e
  b01a001a 1a624d1d f44b4fff 333358b9 25cdb042 01473044 02203852 5fc553a8
  d134f200 9d520bf2 9c87b096 7cfaea7c db043a0d 0f6b135b f7140220 26315e4d
  88edabc7 6b39241e 6f7ea4bd 95af0c8a 31c6c497 9006724a bed70450 014cc952
  410434be 1ffcac1c fdea8f80 01e31af2 75a2b2b1 2c00461d 2727fc30 ef025116
  ba918c78 31d23bb5 bb52ef60 d098b82c d9275391 934e2fa7 24f641b5 a8f51549
  2c8d4104 a3b81cc8 fde26d66 5c11133f a6e0e562 c80122d0 fd6d25b7 9cc1478a
  7ad77d06 b403565b 0a016a6b 971c664d 686bd590 f1bd4d08 982909b1 3d45128c
  39e22bbd 4104ce75 f88b933d 0cdc647a 28d24547 0481a6b3 8caa1720 ba143fe8
  94d49c54 6a4eecc8 5b5e817a 1dda3fbb fbe5dbb7 0b83294c c9c617cd 27f1eff3
  e50ef043 0c0453ae ffffffff 2c5ce43c 90a0a120 2196b660 d48b5085 70ff1e8a
  b5ac03fd 4864cb77 8a09d3b3 00000000 fd5e0100 48304502 2100c808 7a7e467e
  3c10faef a32fd620 67ab5003 ff0bfc1f eceecb38 e6906277 eb2b0220 7b28db72
  7a1fe783 f15a5b04 93c49391 990017fb 88d9a7d5 d2498c27 c71ac6d6 01483045
  022100ff c7d05f2f e891cde2 06d5e725 8505cc2c 995eaccb f7791e07 5846e8b4
  931d2402 20158177 42b8d1b5 f1abe051 21ca5abd 390b2e82 9b3d9af5 3ed9240e
  7f307937 d9014cc9 52410434 be1ffcac 1cfdea8f 8001e31a f275a2b2 b12c0046
  1d2727fc 30ef0251 16ba918c 7831d23b b5bb52ef 60d098b8 2cd92753 91934e2f
  a724f641 b5a8f515 492c8d41 04a3b81c c8fde26d 665c1113 3fa6e0e5 62c80122
  d0fd6d25 b79cc147 8a7ad77d 06b40356 5b0a016a 6b971c66 4d686bd5 90f1bd4d
  08982909 b13d4512 8c39e22b bd4104ce 75f88b93 3d0cdc64 7a28d245 470481a6
  b38caa17 20ba143f e894d49c 546a4eec c85b5e81 7a1dda3f bbfbe5db b70b8329
  4cc9c617 cd27f1ef f3e50ef0 430c0453 aeffffff ff014277 fb040000 00001976
  a9141a33 d9d2aa52 d4ff6425 f9e98f5f c6686588 6a6588ac bd8a0700
2017-10-09 20:39:50 (ERROR) -- ArmoryQt.py:3162 - Transaction details
2017-10-09 20:39:50 (ERROR) -- (PPRINT from /usr/bin/../lib/armory/ArmoryQt.py:3163)
Transaction:
   TxHash:    1eb2421b07620977a49c2b2a9ab1ac4dbb4f057b1424bfdf84f9b50cf40a1ba8 (BE)
   Version:   1
   nInputs:   2
   nOutputs:  1
   LockTime:  494269
   Inputs:
      PyTxIn:
         PrevTxHash: 8182bf31a8e9a8af7ad4ff52d182b3afe0eb5e72be2f0585208e58a1bba76156 (BE)
         TxOutIndex: 0
         Script:     (0047304402203fb96d77b6eee47c82a155dfc3c47b89cfc917c469d885c83c16)
         Sender:     33Rsw83aYK9ChQx68C1aXxaJb5j5LzyLhw
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: b3d3098a77cb6448fd03acb58a1eff7085508bd460b6962120a1a0903ce45c2c (BE)
         TxOutIndex: 0
         Script:     (00483045022100c8087a7e467e3c10faefa32fd62067ab5003ff0bfc1feceecb)
         Sender:     33Rsw83aYK9ChQx68C1aXxaJb5j5LzyLhw
         Seq:        4294967295
   Outputs:
      TxOut:
         Value:   83588930 (0.8358893)
         Script:  OP_DUP OP_HASH160 (13PYgef5Lsbhnk2D3W6z8zHiHiaAeHRdyp) OP_EQUALVERIFY OP_CHECKSIG

2017-10-09 20:39:50 (ERROR) -- ArmoryQt.py:3164 - Failure message: mandatory-script-verify-flag-failed (Signature must use SIGHASH_FORKID)
2017-10-09 20:39:50 (WARNING) -- ArmoryQt.py:4111 - Called updateSyncProgress while not sync'ing

I finally got around to try the RC build on my Macbook (macOS Sierra 10.12.6).  Unfortunately, it cannot broadcast transactions.

When I load a transaction that I signed offline, I cannot broadcast it.  The usual dialog comes up, I load the transaction from file, the usual gibberish appear in the window, but Broadcast and Copy Raw Tx (Hex) buttons remain gray.  And the green text "All Signatures Valid" does not appear.  Instead, a number of exceptions appear in the log: https://pastebin.com/7pv6U5iE

I have now reverted to the previous version and have broadcasted my transaction, but I am ready to try again (and to patch the Python code to test solutions).

EDIT: It is a BCH transaction, signed with the BCH signer.

Did you update the offline side too?

I've been having lots of trouble creating new transactions. I've tried from 0.96.2, 0.96.3, and even 0.96.3.99. I was successfully able to send coins stored in P2PKH type addresses, but it seems that something is keeping me from creating transactions for P2SH-P2WPKH, of which I have two.

This wallet was an offline cold storage wallet. After uploading both hot and cold computers to this version, I still had these problems. When I tried to do an offline transaction, I could successfully create the transaction on the hot computer, but then the cold computer said the transaction was unrecognized.

I then moved the whole wallet to the hot computer. It's a low balance wallet I'm just using for testing so I'm not too concerned about keeping it cold. I'll create a new cold wallet once I'm ready. I now get the following in my log when attempting to create a transaction:


What can I do to get this working?

Make sure you are using matching versions on the signer and the online machine.

I did. I got errors when both had 0.96.3.99. The above is actually just from the online machine after restoring the full wallet onto that machine. So I wasn't using an online and offline copy any more at this point.

What else do you need from me to be able to diagnose this?

I'll look into it.

Thank you! Please let us spend 0 conf someday tho, an expert setting would be perfect :)

Can't I use my 0.96.3 offline signer with 0.96.4 ?

Updated to this latest version of Armory. Armory won't go online and gets to 99% scanned transactions and won't budge. I really need to get to my bitcoin but can't.

The "MAX" button functionality is broken. It can calculate the exact amount but it is not possible to spend any coins.

armorylog.txt

I've seen the same error code from another user on this topic. Actually when downgrading to 0.96.3 "MAX" button is working and I'm able to spend.

Hi from me.
I downloaded v 096.3.99 and it was scanning transaction history forever, never seemed to end.
I downgraded back to v 96.3:  "Building Databases" finishes after a few minutes,  "synchronizing with network" [Edit] also finishes but "scanning transaction history" runs forever and never ends.

When I quit, via the menu, it gets stuck. I need to kill ArmoryQT and armoryDB from the Task Manager.


 I run QT core 0.15.1 which is fully synchronized.

Please help. I cannot access my balances anymore.

This is on a windows10  64bit machine.

It seems armory does not add the amount of the original UTXO (complete, so before subtracting fees) when signing the transaction. I fixed this in a small script: https://bitcointalk.org/index.php?topic=2309673.0

I'm unable to set the preferred receive address type to P2SH-P2WPKH for my offline machine. I've just updated both my online and my offline to this release. My online, connected computer allows all the address types. The offline one has P2SH-P2WPKH disabled. Is there a reason for this?

PS I really think you should have a sticky post at the top of this forum pointing to https://btcarmory.com/docs/. I just tried searching ang got https://www.bitcoinarmory.com/ again. It's not clear which is the best site to use.

https://github.com/goatpig/BitcoinArmory/blob/testing/changelog.txt#L9

Thanks. I'm surprised it needs a commandline option, given that SegWit is off by default.

Has Armory got slower to launch recently? I had it running and synced, closed it, then immediately restarted it. It's taken several minutes to build databases and now says an hour to scan transaction history. I'm sure it used to be much quicker just a few months ago.

SegWit is off by default. Activation is detected by the node it is running against. Therefor an offline instance cannot detect SegWit activation, which is why you need to manually enable it.


Some event increased the address chain without registering the new addresses. On the next run, they have to be scanned.

Is armory 0.96.4 RC1 the same as 0.96.3.99? I can't seem to find the download for 0.96.4 RC1. Sorry for the noob question.

0.96.3.99 is 0.96.4 RC1

An offline transactions with Input from Segwit addresses it not recognized by the signer.
Signer and online version are both on the 0.96.4 RC1 version

There was a bug reported when using several SW inputs the process would choke. I'm working on it.

Exactly, I try to move inputs from an incoming wallet where lot inputs on different SW addresses comes in.
Guess have to use non segwit inputs then for now.

If you're willing to build from the testing branch I could probably have this fixed today.

I can do that.

Should be fixed, try it out.

Nope, not working.
Does the signer need to be updated as well?

Yes both the offline and online instance need the fix.

Ok build the signer as well but seems its still starting the old one or the version wasn't updated.
Have to figure out later, its not working with the new build but maybe somehow the old version is loaded so could be a problem on my side.

I'll try with offline signing and let you know.

Edit: offline sign works too on my end. There is no version bump on the software, maybe you want to bootleg that to be sure you're running the right code:

https://github.com/goatpig/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L71

No luck for me so far. I'm back to an older version but currently rebuilding the DB.
Maybe its because I just have a lot inputs in such transactions.

Shouldn't be related. If you're having errors, let me see the logs. The user who reported the issue confirmed the fix on his end, so you may be experiencing something different.

Ok, but that would take some time... Can't just keep testing all the time as i usual need to make transactions.
Now i'm rebuilding the db with a old version, i can go back to newer version when i moved some coins after that.

The logs with the error backtraces should be there regardless of what version you are running now though. That's what I'm asking for.

2017-11-22 15:15:39 (INFO) -- TxFrames.py:727 - Change address behavior: NewAddr
2017-11-22 15:15:39 (ERROR) -- Traceback (most recent call last):
  File "/usr/local/lib/armory/ui/TxFrames.py", line 848, in createTxAndBroadcast
    ustx = self.validateInputsGetUSTX()
  File "/usr/local/lib/armory/ui/TxFrames.py", line 802, in validateInputsGetUSTX
    lockTime=TheBDM.getTopBlockHeight())
  File "/usr/local/lib/armory/armoryengine/Transaction.py", line 2287, in createFromTxOutSelection
    return self.createFromPyTx(thePyTx, pubKeyMap, txMap, p2shMap)
  File "/usr/local/lib/armory/armoryengine/Transaction.py", line 2196, in createFromPyTx
    cppPrevTx = TheBDM.bdv().getTxByHash(txhash)
  File "/usr/local/lib/armory/CppBlockUtils.py", line 2758, in getTxByHash
    return _CppBlockUtils.BlockDataViewer_getTxByHash(self, txHash)
DbErrorMsg: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7fc0d9941a80> >

It's suggesting your DB is corrupt.

Rebuild more than once in the last days...

Put the call in a try block and print the error message. Something like this:


Btw this traceback is for code from master (0.96.3). Have you reproduced the same issue with the testing branch?

I'll build the testing tomorrow again. ( ATM its rebuilding the DB again ).

I've setup on a clean new machine and now it works.
The signer still need to be fixed on my side as the signed TX is not recognized but i'm able to just broadcast the raw tx.

Do you have an error log for that last part?

Guess this one:

But could be just because the signer is on an older version and the online node is on the current testing.

Ah indeed, the signer and online instance need to be in lockstep.

Same problem with my save and restored 1RustyR vanity wallet:

(ERROR) TxFrames.py:925 - Problem sending transaction!
Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 919, in createTxAndBroadcast
    ustxSigned = self.wlt.signUnsignedTx(ustx, signer=self.signerType)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 2705, in signUnsignedTx
    signerType=signer)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2886, in createAndInsertSignatureForInput
    DetSign, signerType=signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1507, in createAndInsertSignature
    DetSign, signerType=signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1425, 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 919, in createTxAndBroadcast
    ustxSigned = self.wlt.signUnsignedTx(ustx, signer=self.signerType)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 2705, in signUnsignedTx
    signerType=signer)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2886, in createAndInsertSignatureForInput
    DetSign, signerType=signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1507, in createAndInsertSignature
    DetSign, signerType=signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1425, 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 919, in createTxAndBroadcast
    ustxSigned = self.wlt.signUnsignedTx(ustx, signer=self.signerType)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 2705, in signUnsignedTx
    signerType=signer)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2886, in createAndInsertSignatureForInput
    DetSign, signerType=signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1507, in createAndInsertSignature
    DetSign, signerType=signerType)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 1425, in createTxSignature
    raise SignatureError('No PubKey that matches this privKey')     
armoryengine.ArmoryUtils.SignatureError: No PubKey that matches this privKey

What's vanity about it? Did you import a private key?

Edit:

Did you update your signer? Are you using mismatched versions between signer and online?

Yes, 1RustyRX2oai4EYYDpQGWvEL62BBGqN9T didn't occur naturally :)

Hmm, it's the armory_0.96.3.99-gcc5.4_amd64.deb so I assume it's all included.  I'm not doing offline signing.

I don't need to reboot or anything?

Happy to hand you whatever you need via GPG email, if it helps.

Thanks,
Rusty.

It looks like the Python signer is failing to populate the pubkey list of the unsigned tx object when it comes to imports. I'll investigate. For now, set yourself in expert user mode and try to manually pick the C++ signer at spend time, see if that fixes your issue.

(ERROR) TxFrames.py:925 - Problem sending transaction!
Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 919, in createTxAndBroadcast
    ustxSigned = self.wlt.signUnsignedTx(ustx, signer=self.signerType)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 2722, in signUnsignedTx
    cppsigner.signTx()
  File "/usr/lib/armory/CppBlockUtils.py", line 4165, in signTx
    return _CppBlockUtils.PythonSigner_signTx(self)
RuntimeError: failed signature
(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 919, in createTxAndBroadcast
    ustxSigned = self.wlt.signUnsignedTx(ustx, signer=self.signerType)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 2722, in signUnsignedTx
    cppsigner.signTx()
  File "/usr/lib/armory/CppBlockUtils.py", line 4165, in signTx
    return _CppBlockUtils.PythonSigner_signTx(self)
RuntimeError: failed signature

Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 919, in createTxAndBroadcast
    ustxSigned = self.wlt.signUnsignedTx(ustx, signer=self.signerType)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 2722, in signUnsignedTx
    cppsigner.signTx()
  File "/usr/lib/armory/CppBlockUtils.py", line 4165, in signTx
    return _CppBlockUtils.PythonSigner_signTx(self)
RuntimeError: failed signature

I'll try to reproduce on my end and report back here.

I have failed to reproduce the issue on my own. This has something to do with the state of your wallets. I'm going to need more data to figure out what's going. For starters, delete the .lmdb files in your datadir. They will reconstructed on the next run. See if that helps with the C++ signer.

Woot!  Thanks, removing them, and with C++ signer, it worked.

Still have those 4 confirmed txs which Armory thinks aren't confirmed (and offers to bump fee).  I'll append tomorrow this one gets similarly stuck.

I'm going to assume the situation has not change with the Python signer, right? Definitely something weird with the wallet state.


There are 3 possible states:

1) The ZC DB is corrupt and still shows the tx as unconfirmed, while they also appear as confirmed in the ledger. In this case, you can clear unconfirmed tx from the Help menu and restart Armory.

2) The ZC never actually mined. In this case, they may or may not be in the in a miner's mempool. You can just RBF these. You'll probably have to build the current state of testing as it has the RBF fixes in there. If you want signed builds, you'll have to wait till I'm done with this accursed BTG signer.

3) Your DB is stuck and can't see new blocks, therefor will never see these tx mined. You can check for this state by comparing Armory's top block (bottom right corner) to your network's top block. In this case, I'd need to see dbLog.txt before I can give you recommendations on how to proceed.

I'm trying to spend some mixed inputs but armory wont let me.


Selecting only 1 type of inputs works.
Isn't it possible to mix segwit with non segwit inputs?

Is this with the latest state of testing?


It should work.

Compiled few days back when i had the other issues.
Now i sent already with coin control and that worked so guess compiling latest makes no sense for now as I wont be able to test the same again.

Should be easy enough to reproduce anyways, just wanted to make sure it was with current code.

Coin Control freezing acting up again.  Clicking the button results in nothing happening.  Can't cancel out or close pop up window.  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

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?

arghhh, sudo killall -9 ArmoryDB only works intermittently.

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.

Any traceback in your logs?  Otherwise delete this line in ArmorySettings.txt:

ccDlgGeometry

ended up deleting .armory and rebuilding from source.   seems everything is working now.  thanks.

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!

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?

To reveal the root, you need:

1) Private Key N
2) The public key chain from 0 to N
3) The chaincode

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?

ELI5: any private key + the WO wallet is enough to reveal the whole wallet.


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.

Thanks for that. I'm going to create a new wallet then.

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?

Will look into it.

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.

Delete your databases folder and try from scratch.

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'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 :-)

It looks like stuff that's already fixed in the testing branch. I'll put out another release soon.

No encrypted HDD, no NAS, and antivirus already excludes the Armory folder(which cotains both ADB and Bitcoin blockchain) due to some well-known trolling events where ppl deliberately included transaction bytes to resemble malware and flag false-positives.

I've used McAfee AV some time ago. Previously everything worked pretty well, but all in a sudden I've gotten corrupted files and crashes of ArmoryDB. I also tried to set folder exemptions, but it didn't really prevent these errors from happening. So I've tried to deinstall my AV and gotten rid of all of my AV services (except Win Defender) and then it worked like it should.
But I have to admit it was hard to drop something that's already paid in order to get Armory running. So I can't tell if that might solve your issue, but again it looks pretty similar to mine.

Nay, I ain't using McAffee either.

EDIT: I found something that may be useful. I had generated 22 P2SH-P2WPKH addresses by clicking on the "receive bitcoins" button and another 2000 using compute. However, on the next restart of Qt, it moved ALL those addresses that I hadn't spent from into the P2PKH area, where they looked completely different. The only way I was able to tell was because they carried the labels I had given them. And the unused P2SH-P2WPKH field became empty. They were effectively all converted. I now had 2022 P2PKH addresses and none others.

I'm pretty that's fixed in testing as well.

So if there's another testing build is it gonna be an RC or a CR? (christmas release) :D

Yeah, sometimes next week probably.

having never had to do this before with a non-RBF enabled tx, what's the fastest, safest, most reliable way to unstick a too low fee stuck tx from the mempool using this version?  specific details would be appreciated.

CPFP. Spend the change of the stuck ZC with a big fee back to yourself.

crap, now Coin Control button freezes again!

Remove the dlg size entry from Settings.txt

ok, i totally screwed that up somehow the last time you told me to do that and i had to recompile.  this is what i see in the Settings.tx file.  what exactly do i delete?:

ccDlgGeometry                        | 01d9d0cb000100000000000000000000000004ff000003050000000000000000fffffffefffffff e000000000200

everything after the "|" ?  or do i make it a true or false?  or delete the entire line?

The entire line.

ok, i'm off.  will let you know how CPFP goes...

everything worked like a charm.  thx goatpig!

how do i make the ccDlgGeometry line deletion persistent? 

Idk, it's some weird shit where the dialog appears minimized or out frame for whatever reason. I may just get rid of the damn geometry saving for this dialog if I can figure out what's going on.

Dawm, struckelling all around at Christmasday..lol..


Situation: New Mac Air with Sierra 10.13.2, Bitcoin core V0.15.1 and Armory 0.96.3.99.

Bitcoin core went well bulding upend connecting, is now done with connecting.

Starting up Armory is the big issue....

package Armory will install, that aint the problem. but after that...

First start up Bitcoine core, then after that started Armory. No result. Just a few seconds the image of Armory blinking. Then its disappears, it won't start up.

I ve removed the program to another folder, didn't work.

Disabled Gatekeeper in terminal, didn't work.

dump:
Process:               Python [1151]
Path:                  /Applications/Armory 2.app/Contents/MacOS/Armory
Identifier:            com.armory.armory
Version:               Huh
Code Type:             X86-64 (Native)
Parent Process:        Huh [1]
Responsible:           Python [1151]
User ID:               501

Date/Time:             2017-12-25 22:24:44.333 +0100
OS Version:            Mac OS X 10.13.2 (17C88)
Report Version:        12
Anonymous UUID:        09F2F47F-BC4C-4A7D-387C-4C91029BC4AA

Sleep/Wake UUID:       E364B7A2-23AD-463F-88A5-48E12B87C69D

Time Awake Since Boot: 9700 seconds
Time Since Wake:       500 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x1] Library missing

Application Specific Information:
dyld: launch, loading dependent libraries
DYLD_FRAMEWORK_PATH=/Applications/Armory 2.app/Contents/MacOS/../Dependencies:/Applications/Armory 2.app/Contents/MacOS/../Frameworks
DYLD_LIBRARY_PATH=/Applications/Armory 2.app/Contents/MacOS/../Dependencies:/Applications/Armory 2.app/Contents/MacOS/../Frameworks

Dyld Error Message:
  Library not loaded: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
  Referenced from: /Applications/Armory 2.app/Contents/MacOS/Python
  Reason: image not found

Binary Images:
       0x100000000 -        0x100000fff +Python (Huh) <DE9F445E-AF87-3A6F-B171-EF96DCC5B5D1> /Applications/Armory 2.app/Contents/MacOS/Python
       0x10a62d000 -        0x10a67798f  dyld (519.2.2) <6695F30B-4E88-3C0B-9867-7D738C44A3E6> /usr/lib/dyld

Model: MacBookAir7,2, BootROM MBA71.0171.B00, 2 processors, Intel Core i5, 1,8 GHz, 8 GB, SMC 2.27f2
Graphics: Intel HD Graphics 6000, Intel HD Graphics 6000, Built-In
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x02FE, -
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x02FE, -
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x117), Broadcom BCM43xx 1.0 (7.77.37.5.1a3)
Bluetooth: Version 6.0.2f2, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
Serial ATA Device: APPLE SSD SM0512G, 500,28 GB
USB Device: USB 3.0 Bus
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
Thunderbolt Bus: MacBook Air, Apple Inc., 27.2

I did read all the treats so far I could find, but no solutions for. Are there more members with this problem?


Happy Christmas to all for you from Belgium!

Read me. (https://github.com/goatpig/BitcoinArmory/blob/master/README_OSX.md)

Ok, thanks showing me the way. The instructions didn't work for me, after searching  https://brew.sh/index_nl.html  worked well. I had also to replace armory to another map, then it worked! Pjieuw! ;D

Many txs! ;)

What do you mean they didn't work? I'd like to know what exactly you did in case I need to update the directions. :)

So I installed this version of Armory in order to get the BCH signer so I could claim my BCH, but when I start Armory it just sits at "Preparing Databases" and nothing happens. I can't see my BTC balance and it says that Armory is offline in the bottom right corner.

The CPU is idling and no disk or wifi is being used, so I'm fairly confident it doesn't actually do anything. What can be the problem and what can I do to solve it?

EDIT: I first tried to install 0.96.3 but had the exact same problem.

EDIT2: I'm also using bitcoin core 0.13.1, should I update?

EDIT3: Looking at the logs, this is what is says:
"Log file opened at 23:30:55.000: C:\Users\Bla\AppData\Roaming/Armory/dbLog.txt
-INFO  - 23:30:55.000: (..\main.cpp:32) Running on 8 threads
-INFO  - 23:30:55.000: (..\main.cpp:33) Ram usage level: 50
-INFO  - 23:30:55.000: (c:\users\goat\code\armory3\cppforswig\BDM_Server.h:263) Listening on port 9001
-ERROR - 23:30:55.016: (..\BDM_Server.cpp:1270) There is already a process listening on 127.0.0.1:9001
-ERROR - 23:30:55.016: (..\BDM_Server.cpp:1272) ArmoryDB cannot start under these conditions. Shutting down!
-ERROR - 23:30:55.016: (..\BDM_Server.cpp:1273) Make sure to shutdown the conflicting processbefore trying again (most likely another ArmoryDB instance)."

Hello ConnyH,

Bitcoin Core will never ever follow the BCH chain (no matter which version). Replace Bitcoin Core temporarily with Bitcoin ABC and let that work as backend to Armory. Then you will be getting there.

EDIT1: And then move your BCH funds to a new wallet you create in a wallet that intends to support the future hard forks of BCH (e.g. Bitcoin ABC). Goatpig has made it clear, that he will not support Altcoins in Armory other than moving your hard-fork funds out of Armory wallets.

Have you set Armory to specifically use port 9001? Mine uses a random-ish high port each launch and I'm fairly sure that is the default.
Either way, something is listening on port 9001, and ArmoryDB is trying to use that port too. As it says, it could be another ArmoryDB process that you would need to kill, or another program entirely.
If it is ArmoryDB, it is possible that it is choking on a bad DB, depending on which version you upgraded from, which is usually resolved with a rebuild and rescan.

Probably, yeah. I think Core will need to update the DB format so be prepared for that to take a little while.

Depends on how they intend to split the BCH and the situation with UTXOs, but ABC isn't always required. All covered in the BCH thread, though.

The user should read the guide to moving funds before proceeding. If nothing else, it'll tell them about pathing, which they'll need to worry about it they don't want Armory to be deeply confused whenever people switch between chains.

Hi,
I’ve read the guide about claiming your BCH and if I understand it correctly I don’t need Bitcoin ABC, have I missunderstood the guide?
Thanks for your reply!
   

Nope, I haven’t set Armory to specifically use that port. I don’t even know how to set Armory to use a specific port. How do I set Armory to use another port?
I will try with a rebuild and rescan! I will also try to update Core.
Thanks for your reply!


I’ve read the thread, but the problem is that I’m very new to this (I've had bitcoins in an Armory wallet for a couple of years, but never really did anything with them), so I barely understood anything.
If I understood it correctly this is what I have to do:
1. Update Armory to a version that has the BCH signer
2. Delete some blocks to somehow see the BCH balance I had at the time at the fork.
3. Send all those funds to a ”real” BCH wallet using the BCH signer.
Have I understood it correctly or am I completely lost?
Thanks for your reply!

Yes. You need Bitcoin ABC (or Bitcoin Unlimited, although it crashes a lot last I checked) in order to access your Bcash coins.


1)Yes.
2)Yes, by using ABC or Unlimited. You'll want to follow the guide and use alternate paths (https://btcarmory.com/docs/pathing) in order to not wreck your regular Bitcoin Core setup. I believe this is covered in the guide.
3)Yes, or to an exchange so that you can sell them. :)

Thanks for your fast reply!
I think I might understand a little bit more what I need to do now.
I'll install Bitcoin ABC on an external HDD and let that sync until it's done. Then I'll set my Armory path to that external harddrive. Do I still need to delete some blocks then? According to the BCH network (or whatever it's called) I have not spent any BCH since the fork (even though I've spent BTC since the fork)?
I still can't see my current BTC balance, but when I've solved that (I updated bitcoin core to the newest version, and it looks like it doesn't say anything about another process listening on that port, but it still won't let me see my current balance), would it be wise to first send my current BTC balance to another wallet so I don't fuck up, or is it literally completely impossible to fuck up? (I'm sorry if I'm being paranoid, but since I'm a student with very little money I would rather not accidentally lose my BTC)

I have one question about a line in the log file:
 "-INFO  - 09:44:27.000: (c:\users\goat\code\armory3\cppforswig\BDM_Server.h:263) Listening on port 9001"
I know goat is one of the developers of Armory, but is it trying to access his user or something? Because I of course don't have a user called goat on my computer.

And again, thanks for your reply!

You're welcome, and you're close. You should be able to copy your Core data and Armory data over to the external drive. (Make sure they're copies!) Cash should do a large reorg and reset the blockchain, downloading only the data starting from the split. The Armory wallets will work as-is but you'll want to use copies since the wallets themselves (and the Armory DB) will split once you use the coins.


Are you running Armory and Core at the same time? What exactly is happening?


Send the Bcash coins first. Cheaper fees, and they're the ones you want to move anyway.


No clue. Presumably a bug in the logging code somewhere. Don't worry, goatpig isn't after your coins. :) I can take a peek around the coins and see if I can figure out what's going on.

This is what I was running up until yesterday.
I have 2 SSD:s, one 500GB with Windows etc. installed and one 250 GB with both Armory and Bitcoin Core installed.
The bitcoin core folder is about 160 GB and the Armory folder is not even 100 MB. I don't know how this works because if I've understood it correctly the Armory folder should be about as large as the bitcoin core folder (and it would not fit in my 250 GB SSD if that were the case). But somehow this was how it was installed before (I followed a thread here on Bitcointalk to make it work).
What I had to do before to access my bitcoins and send them:
1. Start bitcoin core and let it sync.
2. Without closing bitcoin core, start Armory and let that finish. Then I would see my BTC balance in Armory and could send my bitcoins wherever I wanted.
If I did it in any other way (i.e. starting Armory without first having Bitcoin Core opened) I would not see my BTC balance in Armory and could not do anything.


Yesterday I installed the newest version of Armory and when I do the exact same thing Armory gets stuck at "Preparing Databases" and nothing seems to happen. In the right corner it says offline and I can't see my current balance.


So I don't really have alot of Armory data, should I have it somewhere? Should it be about the same size as the bitcoin data (i.e. approx 160 GB)? If then, should I maybe uninstall both Bitcoin core and Armory and then maybe install Bitcoin core on my 500 GB drive and only Armory on my 250 GB drive and let them sync? (I have a fairly fast computer, i7 quad core) and 1 Gbit/s internet, so it should not take more than a day or two, right? I also have a armory paper wallet, so I should be able to retrieve my BTC, right?
I have an external HDD with 320 GB (is that enough or do I need more space?), should I install Bitcoin ABC on that one and copy the bitcoin core blockchain files into that folder and then let it sync?
If I start Armory and path it to the bitcoin core, then I would see my BTC balance, right?
And if I start Armory and path it to Bitcoin ABC then I would see my BCH balance, right? (or am I completely lost now?)
(Since the fork I have sold approx half of my BTC, but none of my BCH, so I should have different amount of them).


Yes, will do when I get it to work :)

Okay thanks!

And thank you so much for your help! As you've probably understood by now, I'm quite the newbie and need very specific instructions :)

I strongly disagree. Get the bitcoins disassociated and secure before messing around with the bcash (or any other altjunkairdropcoins).

Bcash does have some replay protection, and as long as you send the coins back to addresses you control, you can always import the private keys on the Core side if that somehow becomes necessary. Besides, if something goes wrong on the Core side and the coins can't be recovered (wrong address entered by accident or something), that's a tragedy. If Ver's crappy altcoins get burned, that would be a resaon to celebrate were usable fiat not involved. :)

I uninstalled both Bitcoin Core and Armory and then reinstalled Bitcoin core in its default path. I let them sync and now I can see my current BTC balance!

If I understand it correctly, my next step is to install Bitcoin ABC on an external harddrive and let it sync. I can then set the path of Armory to where those blocks are and I will se my current BCH balance? Or do I need to install and run another instance of Armory?

EDIT: And it looks like I remembered it completely wrong about the HDD space needed. I believe when I first got Armory (2014) the total space needed was 2 times the blockchain size, since armory took up the same amount of space. Now it looks like this is not the case (or maybe it wasn't ever like that, and I just remember it wrong)

1)Glad you can see your balance. :)

2)Basically. As mentioned before, copy the Core data and Armory data to the external drive, use command line pathing to get ABC to update the blockchain, and then use pathing on Armory (with ABC running) to access your coins under Armory.

3)You're right. My understanding of the progress of Armory was managing the blockchain directly in memory (all versions before 0.9), then using LevelDB to manage the blockchain (0.9-0.93.3), and then LMDB to manage the blockchain (0.94-present). You're probably thinking of LevelDB, where Armory basically replicated the blockchain, which would now be ~370 GB of data when combined with the blockchain. LMDB is much smarter and only uses ~1 GB on my setup (+ ~185 GB for the blockchain).

Hi guys. I am a newb to bitcoin armory. I hope you could please help me. I haven't used Armory since 2015 and I was using Bitcoin core 0.10 with Armory. I first tried rebuilding the Armory data base and block chain but that didn't work. After that i updated Armory to 0.96 and couldn't get it to work correctly so i update Bitcoin core to 0.15.1 After that it would crash on startup with a ArmoryDB.exe stopped error. I have tried updating Armory to 0.96.4 RC1 to work with Bitcoin core 0.15.1 and it crashes before Armory completely opens with a ArmoryQt.exe has stopped error. 

Hey goatpig I found a strange bug in 0.96.1. Not sure if it's present in this version too. Here it is: I tried setting the fee to 218 sat/byte, but Armory would just set it to 21. It's not important, but just saying.

Thank you for your effort as always!

Delete your Armory database folder and try again. (Don't worry, deleting the DB won't affect your coins, although it will take awhile for Armory to rebuild the DB.)

Replying to the multiple topics in this thread:  (for purpose of separating BCH from legacy BTC) and upgrading to the most recent workable versions of Armory (which will address and separate out BCH from legacy BTC).  

The last Armory transaction occurred on July 19, 2017 (pre fork) moving some pre-fork BTC between two different Armory 0.96.0.4 wallets (for the confirmation where that version of Armory had been successfully installed - with Bitcoin Core 0.14.2).  

The early summer 2017 successful install of BCCore 0.14.2 and Armory 0.96.0.4 seemed to have opposite sequence for successful sync (than the former 0.93.3) where the BC core 0.14.2 was synced first to itself; then Armory 0.96 (and subsequent 0.96.0.4) all easily synced to the full 0.14.2 bitcoin core database.

---

Present questions:

Now updating a friend's 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 former 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 early summer 2017 experience I let the BC core 0.15.1 fully sync itself.  Armory 0.96.3 seems to
recognize that the database might be present, but does not sync properly to the 0.15.1 data base.  

All wallets successfully installed into the off line Armory 0.96.3 and watching only copies also indicate to the On Line Armory 0.96.3.  The 5 watching only On Line wallets have identified as "This Wallet Is Mine" (and where the on line Armory now correctly indicates Offline for Security).  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?  

---

2nd task regards separating the BCH in each of those wallets into a separate system.  Once the above Armory 0.96.3 is fully synced for all wallets, is it necessary to use an external hard drive (or other computer) and install the Bitcoin ABC database also with Armory 0.96.3 as the driver for that database? and from which one can separate out the BCH from each respective legacy BTC wallet?  (per some of the forum comments above).  

Thank you for your assistance.  

We're now into just square one of the separation process (installing the most recent versions of Armory with the most recent BC core databases).    

Hello all, I have tried to install Armory on a new Windows 10 computer with Bitcoin Core v).15.1 (64 bit) running.  Bitcoin Core runs well but Armory 0.96.4 will not get past a runtime error and shutdown.  Have tried uninstalling and re-installing Armory but it just does not seem to want to run. Virus protection is Malwarebytes Premium.  I have never had Armory running on this computer before and plenty of disk space available.  Regards, Alan

Which RC are you running? (RC3 is out.) Can you tell us more about your PC?

The PC is a brand new Acer with Windows 10 installed.  I reinstalled windows overnight and have reinstalled Armory 0.96.3.99 which now opens okay.  However, it remains offline and I do not know what it is doing, if anything, to get itself online.  I am just letting it remain open while I write this.  My PC has 700gb available on the hard drive.

Shall I just wait?  Should I install Bitcoin core wallet at the same time and allow it to download and sync the bitcoin core database?

Thanks, Alan

Installing Core and letting it fully sync is mandatory.