Using Armory on the BCH chain

[goatpig]

I'm starting to get it, thank you! Just a few more questions if you don't mind:

1) What broadcasting website did you use? Others have reported http://blockdozer.com/insight/tx/send Have you tried that one? They don't use HTTPS which worries me.

2) I normally use https://bitcoinfees.21.co to check what BTC fees I should be using. What fees do you recommend for BCH? The faster I can dump, the better

3) Let's say I have a total of 2 BTC in various utxos in the Armory wallet. And let's say I'm transferring it all at once (to some BCH exchange address). Let's say I want to use the fee 0.001 BTC. Isn't it then just a matter of selecting all the utxos and transferring 1.999 BTC using a 0.001 BTC fee? I'm almost 100% sure this is correct, but I thought I'd make sure just in case.

1) I sync'ed a BCH node.

Blockchair uses SSL, but I don't know if they have a send API. One thing you need to know if you're going to push through a 3rd party: Armory RBF flags by default, and RBF is disabled on the BCH chain. This doesn't mean RBF flagged transactions are invalid on the BCH chain, but that second RBF won't be broadcasted (first RBF flags potential replacement, second RBF is replacement). However, people have reported 3rd party chain explorers won't broadcast RBF flagged tx on BCH, therefor I suspect they went for the idiot patch and reject anything sequence flagged as a whole (how do they deal with OP_CSV?).

2) Last I checked, you could get first block inclusion with as low as 20 sat/B atm. I expect it's cheaper now

3) Pick all the eligible utxos in the coin control UI (don't bother if you want to move the whole wallet balance), then check the "MAX" box and pick a sat/B fee (force a flat fee).

[pf]

1) I sync'ed a BCH node.

Ok, since you did that, I think I'll do that too. Did you use Bitcoin ABC (https://www.bitcoinabc.org)? Do you trust their code? I'll be compiling it myself.

[goatpig]

Did you use Bitcoin ABC (https://www.bitcoinabc.org)?

Yes

Do you trust their code?

lol no

[pf]

Do you trust their code?

lol no

Hmm, in what sense do you not trust it? I was just wondering if it's trustworthy enough to run just for the purpose of dumping my BCH But who knows, maybe this code contains malware... that's what I meant.

After compiling a binary, maybe I should run the binary on a VM just to be safe.

[gangtraet]

There is a whole community running BCH nodes with almost religious fervor.  I am sure they would have noticed if it installed malware or stole wallets.

[goatpig]

Hmm, in what sense do you not trust it?

Your question was akin to: "do you vouch for this code?". No I don't, nor do I want the responsibility. Also, ABC devs went out of their way to obfuscate their changeset. This is like a manufacturer advertising that you shouldn't trust their product. Alright then, I won't.

There is a whole community running BCH nodes with almost religious fervor.  I am sure they would have noticed if it installed malware or stole wallets.

I do not believe these developers are malevolent. I certainly think they are incompetent. Whether you get screwed intentionally or by negligence, the end result is the same.

[HCP]

I do not believe these developers are malevolent. I certainly think they are incompetent. Whether you get screwed intentionally or by negligence, the end result is the same.

Like the whole "let's configure BitcoinABC so that it installs to and uses the same default data directories as Bitcoin Core" saga... They say you should never attribute to malice, that which can be explained by incompetence...  #noComment

[gangtraet]

You can use Bitcoin Unlimited or Bitcoin Classic instead, if you do not want to touch Bitcoin ABC.  Personally, the lack of digital signatures is enough for me to chose something else.

My personal plan is to use Bitcoin Unlimited to once and for all extract my BCH from my Armory wallet, and move it to my Ledger, where I will keep them hedging for the unpleasant possibility that the main bitcoin chain does not manage to address the scaling issues.

Once I have done that, I will probably clean up the software mess on my 'puter - and wait for the Segwit2x hardfork and its associated mess. 

[XD419]

• With the BCH signer done, here is a guide on how to use it and keeping your stash secure.
  
  -------- The signer --------
  
  In order to sign for BCH, you have to pick your signer manually. This is a new feature, and is only available in Expert mode, so first thing first, set user mode to Expert.
  To pick the signer, you need to get to the "Confirm Transaction" dialog. Once there, you should see the signer select frame, click it and pick the signer for the chain you want to spend on. The default option only picks between Bitcoin signers, to sign for BCH you HAVE to pick the BCH signer manually.
  
  Screenshots for the good measure: https://imgur.com/a/9zXGD
  
  Once you've picked the signer, the rest is business as usual. Note that this step only occurs at the point of signing, i.e. if you sign offline, you have to pick the signer on your offline machine.
  
  

I dont understand how to get to the signer option :[ im very new to this stuff and im pretty slow, will need more assistance at a convenient time for whom ever may help. Cheers

[/list]

[pf]

-------- Tricks --------

If you want to dump BCH but don't want to bother with the BCH node/don't trust their code, you can get around it with this trick:

1) You know all your prefork coins are also available on the BCH chain, therefor you only need blockchain data up to the fork point to move these coins.

2) You have all this data already in the form of the Bitcoin blockchain pre fork, so why not just use that?

3) You'll want to create a copy of your blockchain data then remove blkXXXXX.dat files up until the fork point . I don't know which file this is, something around 950~960, I'm sure someone will figure out the exact file. Note that if you did not move any coins post fork yet, you do not need to delete anything.

4) With this done, you want to sync a fresh DB against this blockchain folder. Do not run a node against it, just start ArmoryDB against this folder, then start ArmoryQt, it will pick up on that DB.

5) Once you're synced (it will show you as offline), you can create your transactions. You should pick utxos manually and keep track of them so as to not create conflicting transactions.

6) Once your tx is ready, make sure to create it as unsigned, even if your private keys are online. You will get a blob of text that you can feed back into the offline tx GUI. There you will get to sign the tx (make sure to pick the BCH miner), and you will get another blob of text. On the right side of that dialog, you will have a button that's called "Copy Raw Tx (Hex)". This is what you are after. This hex string is your signed tx.

7) With the signed tx, all you need now is some online service that will broadcast it to the BCH network for you, and voila.

I decided to go with your Tricks route. I'm using https://pool.viabtc.com/tools/BCC/broadcast/ to broadcast. It works like a charm!

I just have one question now: In Armory, I saw an output address (what you called "utxos") with 10.0 BCH. The problem is that ShapeShift's maximum deposit was 8.0 BCH. So I sent 8.0 BCH to ShapeShift and 2.0 BCH back to the original output address ("utxo"). In other words, I used the original output address ("utxo") as the change address. So now I'm stuck with 2.0 BCH in this original address. My question is this: How do I spend the remaining 2.0 BCH? Can I safely follow the same steps except with 2.0 BCH instead of 10.0 BCH - even though the Armory UI erroneously shows me that 10.0 BCH remain in there?

(In the above 10.0/8.0/2.0 BCH example, I obviously ignored transaction fees to keep the example simple.)

[goatpig]

How do I spend the remaining 2.0 BCH? Can I safely follow the same steps except with 2.0 BCH instead of 10.0 BCH

You screwed yourself here. You basically need a fully validated BCH chain now for Armory to be able to see the tx that created that 2 BCH output, for you to be able to now spend it.

[pf]

How do I spend the remaining 2.0 BCH? Can I safely follow the same steps except with 2.0 BCH instead of 10.0 BCH

You screwed yourself here. You basically need a fully validated BCH chain now for Armory to be able to see the tx that created that 2 BCH output, for you to be able to now spend it.

I'm probably stretching it now, but any chance you could zip and upload somewhere the BCH blk files from 950 until today?

I tried running Bitcoin Classic (it's supposed to be able to re-use Bitcoin Core blocks from before Aug 1) but unfortunately it failed... so I may have to download the entire 150 GB chain :S

[goatpig]

How do I spend the remaining 2.0 BCH? Can I safely follow the same steps except with 2.0 BCH instead of 10.0 BCH

You screwed yourself here. You basically need a fully validated BCH chain now for Armory to be able to see the tx that created that 2 BCH output, for you to be able to now spend it.

I'm probably stretching it now, but any chance you could zip and upload somewhere the BCH blk files from 950 until today?

I tried running Bitcoin Classic (it's supposed to be able to re-use Bitcoin Core blocks from before Aug 1) but unfortunately it failed... so I may have to download the entire 150 GB chain :S

Copy your BTC chain, delete block files up to the fork point and let a BCH node sync against that.

[pf]

How do I spend the remaining 2.0 BCH? Can I safely follow the same steps except with 2.0 BCH instead of 10.0 BCH

You screwed yourself here. You basically need a fully validated BCH chain now for Armory to be able to see the tx that created that 2 BCH output, for you to be able to now spend it.

I'm probably stretching it now, but any chance you could zip and upload somewhere the BCH blk files from 950 until today?

I tried running Bitcoin Classic (it's supposed to be able to re-use Bitcoin Core blocks from before Aug 1) but unfortunately it failed... so I may have to download the entire 150 GB chain :S

Copy your BTC chain, delete block files up to the fork point and let a BCH node sync against that.

Is it enough to delete the blocks/blk*.dat files down to the fork point? There are a bunch of more files in there:

• Files: blocks/rev*.dat
• Folder: blocks/index
• Folder: chainstate
• Files: banlist.dat, db.log, debug.log, fee_estimates.dat, mempool.dat, peers.dat, wallet.dat

I'm not sure which of those I need to delete. (I'm going from Bitcoin Core -> Bitcoin Classic in UAHF mode.)

[pf]

How do I spend the remaining 2.0 BCH? Can I safely follow the same steps except with 2.0 BCH instead of 10.0 BCH

You screwed yourself here. You basically need a fully validated BCH chain now for Armory to be able to see the tx that created that 2 BCH output, for you to be able to now spend it.

I'm probably stretching it now, but any chance you could zip and upload somewhere the BCH blk files from 950 until today?

I tried running Bitcoin Classic (it's supposed to be able to re-use Bitcoin Core blocks from before Aug 1) but unfortunately it failed... so I may have to download the entire 150 GB chain :S

Copy your BTC chain, delete block files up to the fork point and let a BCH node sync against that.

Is it enough to delete the blocks/blk*.dat files down to the fork point? There are a bunch of more files in there:

• Files: blocks/rev*.dat
• Folder: blocks/index
• Folder: chainstate
• Files: banlist.dat, db.log, debug.log, fee_estimates.dat, mempool.dat, peers.dat, wallet.dat

I'm not sure which of those I need to delete. (I'm going from Bitcoin Core -> Bitcoin Classic in UAHF mode.)

For instance, just deleting blocks/blk*.dat files from 930 and onwards, and then launching "./bitcoind -datadir=<new dir with deleted files>" of Bitcoin Classic UAHF gives me "Error loading block database, Do you want to rebuild the block database now?"

I tried various other combinations starting fresh, such as deleting also blocks/rev*.dat and chainstate. Same error. Nothing seems to work.

[goatpig]

Files: blocks/rev*.dat
Folder: blocks/index
Folder: chainstate

Everything here but the blk files are created on the fly during sync. That stuff will be overwritten if it doesn't match the state of the blk files.

For instance, just deleting blocks/blk*.dat files from 930 and onwards, and then launching "./bitcoind -datadir=<new dir with deleted files>" of Bitcoin Classic UAHF gives me "Error loading block database, Do you want to rebuild the block database now?"

Same thing goes with the chainstate db. It's the processed state of the blk files. If you change the blk files, you need to reindex the chainstate.

Files: banlist.dat, db.log, debug.log, fee_estimates.dat, mempool.dat, peers.dat, wallet.dat

These are not relate to the blockchain, you can ignore them.

[Rothbart]

I'd like to sell my BCH, without installing their node/syncing their chain, if possible. My BTC are unmoved since before August 1, and I've got a copy of Armory 0.96.2 synced to the Core chain. I'm a little confused with how to create the BCH transactions on a per-utxo basis.

Does this look correct?:

1. create an unsigned TX on online Armory 0.96.2 machine that's synced to the Core chain
2. sign it with BCH signer on offline Armory 0.96.2 machine
3. broadcast the transaction on, eg. http://blockdozer.com/insight/tx/send
4. repeat steps 1-3 for each of the addresses I have that contain BTC; sending the full amount contained in each address each time? (I think this is necessary, in order to avoid change addresses - since I don't want to run the BCH node/chain?)

Also, it seems I should disable RBF for the sake of compatibility on the BCH chain?
Is it possible/necessary to have the transaction fee come from the utxo, so that if an address contains 1BCH, I can have eg. 0.999BCH send, with the 0.0001 transaction fee coming from the same address, emptying it completely with no change address generation? This aspect is what I'm most confused about - is there some easy way to manage all this within the Armory software?

Is it necessary to move the BTC to new addresses, either before or after dumping the BCH?

Thanks!

[HCP]

Is it possible/necessary to have the transaction fee come from the utxo, so that if an address contains 1BCH, I can have eg. 0.999BCH send, with the 0.0001 transaction fee coming from the same address, emptying it completely with no change address generation? This aspect is what I'm most confused about - is there some easy way to manage all this within the Armory software?

The fee is "the difference between total inputs & total outputs"... so if your input is 1BCH and your output is 0.999BCH then the difference is automagically given to the miners as the fee. Note that BCH network fees are generally a LOT lower than on the BTC network. Generally, they never get enough transactions to fill a block... so 1 BCHtoshi per byte is usually more than adequate

Is it necessary to move the BTC to new addresses, either before or after dumping the BCH?

That is only really a "recommended" security measure when using "untested/untrusted" BCH wallets and/or when having to export/import private keys to try and prevent loss of BTC in the case that the private keys/seed get leaked for whatever reason...

[Rothbart]

Is it possible/necessary to have the transaction fee come from the utxo, so that if an address contains 1BCH, I can have eg. 0.999BCH send, with the 0.0001 transaction fee coming from the same address, emptying it completely with no change address generation? This aspect is what I'm most confused about - is there some easy way to manage all this within the Armory software?

The fee is "the difference between total inputs & total outputs"... so if your input is 1BCH and your output is 0.999BCH then the difference is automagically given to the miners as the fee. Note that BCH network fees are generally a LOT lower than on the BTC network. Generally, they never get enough transactions to fill a block... so 1 BCHtoshi per byte is usually more than adequate

Is it necessary to move the BTC to new addresses, either before or after dumping the BCH?

That is only really a "recommended" security measure when using "untested/untrusted" BCH wallets and/or when having to export/import private keys to try and prevent loss of BTC in the case that the private keys/seed get leaked for whatever reason...

Thanks for your help - I'm just really confused with how to ensure I send all the BCH out, in multiple transactions, without having to install the BCH node/chain.

[pf]

Files: blocks/rev*.dat
Folder: blocks/index
Folder: chainstate

Everything here but the blk files are created on the fly during sync. That stuff will be overwritten if it doesn't match the state of the blk files.

For instance, just deleting blocks/blk*.dat files from 930 and onwards, and then launching "./bitcoind -datadir=<new dir with deleted files>" of Bitcoin Classic UAHF gives me "Error loading block database, Do you want to rebuild the block database now?"

Same thing goes with the chainstate db. It's the processed state of the blk files. If you change the blk files, you need to reindex the chainstate.

Files: banlist.dat, db.log, debug.log, fee_estimates.dat, mempool.dat, peers.dat, wallet.dat

These are not relate to the blockchain, you can ignore them.

Running

./bitcoind -reindex -maxmempool=3000 -datadir=<copy of bitcoin core dir with blk files down to July 28 2017 deleted>

appears to be working, but it's not finished yet. After 24 hours it got to only January 2017! Still running. This is insane lol. I've got a 2.6GHz Intel Core i7. Is this normal? What a painful experience...