Topic: Using Armory on the BCH chain (Read 46031 times)

Aside from creating the transaction in Armory, there's a simpler method of exporting your private key(s) to be imported to clients that support those chains.
But the script type must be supported by such wallets; so if you're using the rare P2SH-P2PK addresses, this export method will not work.

Note that this is less secure so you must spend your BTC first before doing so.
And absolutely not privacy-oriented method since you're going to rely on third-party public servers (nodes).

For example (BCH):

• Download Electron Cash (Electrum Fork - GitHub Repo), stand it aside.
• Open your Armory, and export the private key(s) of the addresses with BCH in "Wallet Properties->Backup This Wallet->Export Key Lists".
• Untick "Private Key (Plain HEX)" and other strings that you don't need, tick "Omit spaces in key data" if you're going to Copy->Paste.
• Then in the list, find the addresses that you need and copy their "PrivBase58" private keys.
• Go back to Electron Cash and create a new [imported] wallet by selecting "Import Bitcoin Cash addresses or private keys".
• Paste your private keys in the next window, one line per key; then finish creating the wallet.
• Wait for the balance to sync (just a few minutes since it's SPV), then send it out ASAP.

To be on the safer side, you may also import the private keys to an offline machine (export from Armory in that machine as well) and the addresses to an online machine.
Then do this "Cold-Storage" setup (Electrum) that the fork clients can also do: electrum.readthedocs.io/en/latest/coldstorage.html#create-an-unsigned-transaction

From the looks of it, you're using 0.96. If you're trying to send BTC, you should upgrade to 0.96.5, fixes the bugs you're running into: https://github.com/goatpig/BitcoinArmory/releases

If you're looking to spend BCH, you will have to go through a more convoluted process:

1. You want to try 0.96.2 as the target release.
2.a. Find dedicated BCH wallet software (I dont have recommendations, sorry), create a wallet with that, back it up, test the backup. Then grab a legacy BCH address from said wallet (starts with a '2').
2.b. Make a backup of your Armory wallet if you don't already have one. Test the backup to be safe.

The hard part (you do not run Core for the entirety of these steps)

3. you will need to setup a dedicated "environment" for your BCH signature process:
   a. Create a copy of your blockchain data, cull blkXXXXX.data files away to be around 450~500k blocks. Aim for 30GB, you can add files as you go. You do not need the revXXXXX.dat files.
   b. Run a 0.96.2 version of ArmoryDB against this copy of the chain. You can get a standalone (no install) binary through the win64.zip release.
   c. Make a copy of your wallet in a dedicated datadir and run ArmoryQt 0.96.2 against it while the target ArmoryDB instance is running. You will require some path magic for this to work unfortunately. A "solution" to avoid the path-fu is to do this on a second PC. When this is finally running, you will have ArmoryQt running, showing the top block to be in that 450~500k range.
   d. You can now create an unsigned transaction moving your BCH to the freshly made BCH address from Armory. To do this, check the "create unsigned" checkbox in the Send dialog. You will be served with a blob. You can choose to sign it. Pick the BCH signer and sign it. Once the blob is signed, choose to export it as "raw hex".
   e.With the raw hex blob, you can now broadcast your tx via any online BCH broadcast tool, at your own leisure.

This is the leanest setup I can think of, as you would have to run some old version of the BCH node to get to broadcast from Armory, which is probably impossible these days, due to various backwards incompatible changes on the BCH side.

4. Bonus round:
   If you're paranoid, you can choose to create the signed BCH tx, then move your actual BTC to a new wallet via regular Armory, then broadcast the BCH tx last. At any rate, my recommendation is to move your BTC off that wallet if you're gonna split the BCH out.

Trying to send BTC I had the fee set to automatically calculate that. I changed that and the transaction failed, the error message said the fee may be too low. I adjusted a few times and it continued to fail.

Can you describe how you got to that error?

Still sitting there right now.

I actually went to move them earlier but got error: targetval > value I am trying to figure that one out now.

Did you move these coins since the BCH fork? Depending on that, the solution will differ a bit.

I did a lot of reading trying to understand this to wind up reading this. Not that I had enough understanding to try and acquire my BCH anyway.

So, if I have an armory wallet with BTC from before the fork how do I get my BCH now? In my reading I also found out there was a fork for BTG is that something I can/should try to get as well?

you only need 1 copy of the BCH blockchain post-fork#1, so just copy it to any machine you would like to use it on. Remember that there were bugs in the original BCH hardforking logic, it didn't always manifest, and so you're kinda lucky that it even worked on 1 machine at this late stage tbh. Finding peers to connect to from between BCH fork#1 and BCH fork #2 is probably like looking for a needle in a haystack at this juncture.

Hi Carlton,

I'm trying to follow your script, I am at step 2 ( Sync the BCH chain up to the block that ABC 0.14 )
I have a copy of the binaries of the version bitcoin-0.14.6-x86_64-linux-gnu that I downloaded from

https://download.bitcoinabc.org/0.14.6/linux/

the sha256sum of the binaries files I got on my storage is

9f37b8ec36a37944b016bbbf07340adb8ba644abb897b2d2e0edeb99ccf709c0  bitcoin-0.14.6-x86_64-linux-gnu.tar.gz

the weird thing is that in one machine those files starts get in sync with other peers, but the same binary does not in another machine located in the same IP subnet.

it should be a problem for both copies of the same binary, any hint?

Thanks

;
The funny thing is, in one machine

This feature is long dead and I'll remove all BCH signer code in the next release to boot. Therefor, I'm going to unsticky this thread.

Yes, I've read all the post and it's a good option for me anyway.

I'm not sure if it's possible to access the coins anymore, at least via Armory. Bcash has had several hard forks, and has one scheduled for later this month, actually. You may have to export your keys and try another tool.

I want to move all off my BTC and BCH (in chunks if possible) from my wallet and I havn't any transaction since 2014. What is the easiest way to do this?
To not mess it up with my BTC, can I begin to make transaction(s) to move my BTC to another wallet or do I need to begin with BCH?

Since I will move to a new wallet without any need of bitcoin core, is it then possible to
1. move my BTC from current armory installation
2. remove bitcoin core, armory and the blockchain (or use another user).
3. install BCH node and armory again
4. restore my wallet from a backup
5. move coins and sign it with bitcoin cash signer

Thank you Carlton, I might have another go at it. I've tried some versions of syncing the blockchain up until some point, but I could not get that to work. Then there was something about a certain script-sig(?) to move the BCH if I remember correctly. I learned a lot, but still failed in the end so I gave up temporarily. I'll start checking out Tier Nolan's code.

I'm still open to letting someone else do it, if anybody is willing.

So I think you could use BCH client software from 2017 to do this still

1. Get a copy of that software (ABC 0.14)
2. Sync the BCH chain up to the block that ABC 0.14 got hard forked into ABC 0.15 (it will do this without you telling it to)
3. Open Armory 0.96.5 (which has a lockboxs fix). Sync it against the ABC chain you have
4. Use the wallet on 0.14 ABC to get a new address
5. Compose a transaction sending the BCH to that new address from step 4 (Armory won't work with anything more than 0.14, so this must be done)
6. Save that tx in Armory as a hex string
7. Get latest version of ABC
8. Sync it against the 0.14 blockchain
9. When it's caught up, send your hex string saved tx using bitcoin-cli sendrawtransaction or on the console in ABC gui
10. profit


You might have problems with step 2. It might get stuck syncing the first ever BCH block (their first hard fork basically didn't work, lol). Later versions of ABC might have this fixed, so you could solve it "simply" by switching to latest ABC at that point, then when you're sure it's now switched to the BCH fork, IMMEDIATELY (or at least very quickly) quit the ABC latest and switch back to ABC 0.14. Armory will not sign the transaction with any version after 0.14

---

You can do the above in a "proper" way rather than the "basic" way as outlined above, but as there's money involved, you might find the "proper" way more frustrating. The outcome will be identical in either case.

Also, I think Tier Nolan figured out a patch to latest Armory (0.96.5) that bypasses the above rigmarole, but that involves compiling his code. FWIW, he's known and of good standing on bitcointalk/in bitcoin generally

I have around 14.2 BCH in a lockbox in armory that I can't get to. I'm offering a 10 % reward to the person who helps me get them out. I have tried many hours using the information on this forum, but it hasn't been enough. Is there anyone willing to help me? preferably someone known on the forum. Thanks in advance.

Edit: I just realized it was at least a year ago that I tried last time. Has any of the updates solved the problem?

Bitcoin Unlimited has fixed the blk file bug in their latest release.

In theory, this means that they should be compatible again and not cause 45 minute startup due to having to rescan everything.

They added an "xversion" message at some point and it breaks things again (sigh).  They technically broke protocol backwards compatibility with this change.


I have created a branch that maintains compatibility.  I mostly coded this for myself, but it shows what you need to change to get things compatible.  (Use at own risk etc.)

(You need 1.5.1.0 to get the fix for the blk files.)

There aren't that many changes needed

- adds a -bch command line for Armory that switches to Bitcoin Cash magic net code
- satoshi-port command line fix (I think this is already fixed with latest release)
- sends ping message immediately after an verack to indicate that Armory node doesn't support xversion

Yeah, the block's undo data is put in the corresponding rev file.  Re-orging each block could require looking in a separate file for each block.

And possibly reorg speed? The revXXXXX.dat files hold the snapshot for the utxo changeset per block. Is it in sync with block alignment in blk files?

Right.  Even better would be to create a local variable to indicate things.


He kind of did that, since the new variable is called loadedblockfile, it just isn't used to update the global variable.


I agree that this was possibly overlooked.  Having a pointer to the last file doesn't really do much if it isn't persisted over restarts.

He may have decided that it was more efficient to fill in the free spaces.  This change would make pruning less efficient too.  Ideally, each block should have a set of files from approx the same time, so they can be deleted roughly in order.

I wonder if the BU node writes to blk00000.dat on each restart if pruning is enabled.