Using Armory on the BCH chain

[Rothbart]

-------- 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.

Do I need to do steps 3 and 4 if all my coins are unmoved since August 1st? I've got Armory 0.96.2 synced against the BTC blockchain up to today. Can I use my current setup?

[1714859899]

1714859899

[1714859899]

1714859899

[1714859899]

1714859899

[1714859899]

1714859899

[goatpig]

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...

Oh but by all means, let's raise that block limit!

Do I need to do steps 3 and 4 if all my coins are unmoved since August 1st? I've got Armory 0.96.2 synced against the BTC blockchain up to today. Can I use my current setup?

You're fine as long as you don't move coins on the BTC side that you have not moved on the BCH side.

[pf]

Do I need to do steps 3 and 4 if all my coins are unmoved since August 1st? I've got Armory 0.96.2 synced against the BTC blockchain up to today. Can I use my current setup?

Worth repeating: PICK THE RIGHT SIGNER, BCASH! OTHERWISE YOU RISK LOSING COINS ON OTHER CHAIN!

To be safe, I personally created a new wallet for my BTC stash and moved BTC there before I dared do anything related to BCH.

[pf]

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...

Oh but by all means, let's raise that block limit!

 

[Rothbart]

Thanks for your help, guys!

[Rothbart]

-------- Privacy ---------
Whether you have sent your coins to a KYC exchange or not, you want to cycle your wallets on the other chain afterwards, i.e. if you dumped BCH, you want to move all these coins on BTC chain to a fresh wallet.

The reason for this is that your public keys will be exposed on at least one chain. One of the security layers of Bitcoin is that public keys are behind hashes up until you spend the coin. Once you sign coins on one of the chains, you lose this layer. This is a major reason why you do not reuse addresses in Bitcoin. This is particularly relevant if you have coins in long term cold storage: cycle them if you touch the keys!

As for how to cycle your wallets, it depends on the scenario:

2) You used a non KYC exchange or some sort of cross chain swap scheme. You should move your coins to your new wallet utxo per utxo, or (1 in -> 2-3 outs), over the course of several weeks.

Could you elaborate on this? In what sense is BTC privacy compromised after dumping BCH?

[Ente]

-------- Privacy ---------
Whether you have sent your coins to a KYC exchange or not, you want to cycle your wallets on the other chain afterwards, i.e. if you dumped BCH, you want to move all these coins on BTC chain to a fresh wallet.

The reason for this is that your public keys will be exposed on at least one chain. One of the security layers of Bitcoin is that public keys are behind hashes up until you spend the coin. Once you sign coins on one of the chains, you lose this layer. This is a major reason why you do not reuse addresses in Bitcoin. This is particularly relevant if you have coins in long term cold storage: cycle them if you touch the keys!

As for how to cycle your wallets, it depends on the scenario:

2) You used a non KYC exchange or some sort of cross chain swap scheme. You should move your coins to your new wallet utxo per utxo, or (1 in -> 2-3 outs), over the course of several weeks.

Could you elaborate on this? In what sense is BTC privacy compromised after dumping BCH?

At the time of the fork, you had BTC and bcash 1:1 on the same addresses. So if someone learns your bcash addresses, she knows you have the same amount in BTC on the same BTC address. Prime example, of course, would be an exchange. They might learn your bcash = BTC addresses as well as your bcash = BTC holdings.

Basically all the same as privacy concerning Bitcoin before.

Ente

[Rothbart]

Thanks for the explanation!

[alomar]

it appears to me that BCH isn't going anywhere.  is it possible to make an easier to use BCH claim tool that doesn't involve building a custom blockchain, similar to what Trezor has done?

[goatpig]

Read the "Tricks" section

[alomar]

OK it all worked for me now. Thanks for the help. One of the issues was that I had only deleted one type of file from the blocks folder and not the other. So file 0949 was actually OK in the end. Broadcasted the raw tx and currently receiving BCH. Now almost done consolidating all my BCH....

are you saying we also have to delete the rev*****.dat files from today back to 00949 from the blocks directory/file?

is that all we have to delete to claim BCH?

[goatpig]

rev files shouldn't matter at all, they're only relevant for Core's reorgs. What you need to nuke as well is your ArmoryDB (if you're not going to use a fresh folder).

Also, there's no guarantee file 949 will do it for you. Core does not download files sequentially, there's a chance post fork blocks are embedded somewhere deeper down your blk files. This file # is only relevant if your node was running at the time of the fork. If you caught up for more than a day of blocks after the fork, chances are you have post fork blocks all over the place. Granted, the only thing you are actually after is the blk file with the first post fork block. If that one is taken out, Armory can't compute the chain past the fork point and you should be good.

[alomar]

Granted, the only thing you are actually after is the blk file with the first post fork block. If that one is taken out, Armory can compute the chain past the fork point and you should be good.

i'm not sure i follow what you're saying here.  are you saying i have to load a blockchain btwn zero and the "one block file with the first post fork block" to make your trick work?

i was under the impression that if i loaded a blockchain that was anywhere pre-fork, let's say btwn block files 0-660, that would be sufficient.  the reason i say this is that i found an old USB stick with a copy of the blockchain in that block file range.  since i have done some tx's of BTC post fork, i have to use your trick of this truncated blockchain from what i understand.  will this block file range work?

[goatpig]

Granted, the only thing you are actually after is the blk file with the first post fork block. If that one is taken out, Armory can compute the chain past the fork point and you should be good.

since i have done some tx's of BTC post fork, i have to use your trick of this truncated blockchain from what i understand.  will this block file range work?

Only if you have not moved coins on the prefork chain past that point.

The logic is as follows: your last set of valid utxos pre fork is still valid on the Bcash chain (up until the point you move your bcash). If you roll back the BTC blockchain to a point in time where it stands past your last valid utxo set state and before you moved coins post fork on the BTC chain, these utxos are also valid on the Bcash chain.

Graphically, it would look like this:

Code:

]--------V------------F-------M--------[

- F is the fork point. Anything past F is the Bitcoin side of the fork on this graphic.
- V is the last block you transacted in pre fork. This is your last valid utxo set state pre fork.
- M is the first block you transacted in post fork on the Bitcoin side.

- Transacted means both sending and receiving coins.

Any chain tip between V and M has the utxo set state you need to move coins on the Bcash side of the fork (as there is no divergence in utxo sets yet in between the 2 sides of the fork).

So what you want to do is to feed Armory a copy of the chain with the tip belonging to [V, M[

[alomar]

Thanks goatpig.  that really helps conceptually.

i'm having trouble connecting to that USB connected drive with the truncated /.bitcoin/blocks folder from the genesis block to blk00660.dat.  no tx's have taken place between 660 and post fork.

Bitcoin is installed here:  /home/debian/Downloads/bitcoin-0.15.0/bin

Armory is installed here, with a fresh empty Databases folder inside:  /home/debian/.armory

when trying to run ArmoryQT with controlling bitcoin, i get this.  :

Code:

debian@debian:~/.armory$ armory --satoshi-datadir=/media/debian/UNTITLED/.bitcoin
/home/debian
(ERROR) ArmoryUtils.py:3716 - Unsupported language  specified. Defaulting to English (en)
/usr/local/lib/armory/armoryengine/Transaction.py:2882: SyntaxWarning: import * only allowed at module level
  def PyCreateAndSignTx_old(srcTxOuts, dstAddrsVals):
(WARNING) SDM.py:439 - Spawning bitcoind with command: /usr/local/bin/bitcoind -datadir=/media/debian/UNTITLED/.bitcoin
(WARNING) SDM.py:396 - Spawning DB with command: ArmoryDB --db-type="DB_FULL" --cookie --satoshi-datadir="/media/debian/UNTITLED/.bitcoin/blocks" --datadir="/home/debian/.armory/" --dbdir="/home/debian/.armory/databases"
(ERROR) ArmoryQt.py:1198 - 8 attempts to load blockchain failed.  Remove mempool.bin.
(ERROR) ArmoryQt.py:1203 - File mempool.bin does not exist. Nothing deleted.
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unexpected fcgi header version
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte

any help would be appreciated.

[goatpig]

Start the DB manually with your custom paths (consider using armorydb.conf for that), then run the client.

[alomar]

is it true that i can simply scan a BCH encumbered private key into a BCH enabled wallet, like Electron Cash, to claim my BCH even after i've sent the BTC away?

if true, wouldn't that be a simpler method to claim BCH than fiddling with all the truncated blockchain tricks?

[goatpig]

is it true that i can simply scan a BCH encumbered private key into a BCH enabled wallet, like Electron Cash, to claim my BCH even after i've sent the BTC away?

if true, wouldn't that be a simpler method to claim BCH than fiddling with all the truncated blockchain tricks?

If you export private keys, you have to consider the wallet compromised and cycle it. That means your backups are done for too. Choose accordingly.

[alomar]

is it true that i can simply scan a BCH encumbered private key into a BCH enabled wallet, like Electron Cash, to claim my BCH even after i've sent the BTC away?

if true, wouldn't that be a simpler method to claim BCH than fiddling with all the truncated blockchain tricks?

If you export private keys, you have to consider the wallet compromised and cycle it. That means your backups are done for too. Choose accordingly.

let's say the online computer one uses to import the private key containing the BCH has malware.  even if the key is compromised, it doesn't help the attacker derive your other private keys without him also having the chain code, correct?

does this change if one imports several private keys to claim BCH, all of which get compromised, even though they don't have the chain code?  IOW, can the master private key be derived by using correlation?  i wouldn't think so since that's the point of the chain code; to make each deterministic key function like a totally randomized key.

[goatpig]

This is what you need to know to treat your private key exports properly: you can reveal the private root of an Armory wallet with:

1) A chain of public keys tracing back to the public root.
2) The chaincode (that's treated the same as public keys).
3) Any corresponding private key on that public chain.

The most conservative position is to consider the entire wallet compromised if you export even a single private key, and that's the position I hold both personally and officially.