Using Armory on the BCH chain

[Rothbart]

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.

Are all 3 of the above required to compromise the private root?

Are you safe from the above if you sign the BCH transactions offline, and just broadcast the transactions using a block explorer?

[1715172642]

1715172642

[1715172642]

1715172642

[1715172642]

1715172642

[1715172642]

1715172642

[1715172642]

1715172642

[1715172642]

1715172642

[Ente]

Are all 3 of the above required to compromise the private root?

AFAIK no, any of those should be considered a compromise.

Are you safe from the above if you sign the BCH transactions offline, and just broadcast the transactions using a block explorer?

Yes. That's what several here did, me included.
Or broadcast with your own bcash node, if you have one.

Ente

[Rothbart]

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.

So if you dumped the BCH from all of your public keys on a single exchange, they could derive your private root from that info?

[achow101]

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.

So if you dumped the BCH from all of your public keys on a single exchange, they could derive your private root from that info?

No, did you not read the posts above yours? The private keys cannot be determined from the public keys, and you need the chaincode with the private keys in order to derive any other private keys in your wallet.

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.

[Rothbart]

Got it - thanks!

[alomar]

how does one correlate block height with blockfile.dat?

[goatpig]

how does one correlate block height with blockfile.dat?

Since headers first (Core 0.10), crap shoot.

[alomar]

as a suggested UX improvement, please give us the option to Uncheck All selected UTXO's in Coin Control.   currently, by default, all UTXO's are checked; this can be a major pain if we want to use only a couple of UTXO's specifically for a tx while holding thousands of UTXO's in a particular wallet.  this forces us to manually uncheck those thousands of boxes down to the couple we want to specifically use.

[goatpig]

Uncheck the parent section.

[alomar]

Uncheck the parent section.

haha.  good one.

[alomar]

since i'm in the cycle of asking stupid questions, is there a way to order the UTXO's by address in Coin Control?

[goatpig]

There is no sorting feature atm.

[alomar]

how do you deal with miner fees and change when claiming BCH?

let's say your wallet pre fork has ten UTXO's with 1BTC/BCH each.  post fork, you perform a 1BTC tx to buy something and your wallet automatically pulls the miner fee from one of the other nine UTXO's and dumps the change into a new address.  weeks later, you go to claim the BCH via Coin Control.  how do you set this tx up using the blockchain truncating Trick?

i assume you select both UTXO's that were in the original BTC tx pre fork.  i would assume you could also set a much lower miner fee than what was necessary in the original BTC tx since BCH miner fees are cheaper.  do you have to worry where the BCH change goes, or doesn't it matter?  will Armory actually dump it into the same change address created from the original BTC tx?

edit:  now that i think about it, i'm getting more confused.  i'm actually trying to claim 2BCH, right, since two BCH containing UTXO's were consumed?  so do i try to send 2BCH as an amount to the receiving BCH address, minus a BCH miner fee, despite the original BTC tx sending 1BTC as the amount?  if so, where does Armory pull the BCH miner fee from?

[goatpig]

how do you deal with miner fees and change when claiming BCH?

let's say your wallet pre fork has ten UTXO's with 1BTC/BCH each.  post fork, you perform a 1BTC tx to buy something and your wallet automatically pulls the miner fee from one of the other nine UTXO's and dumps the change into a new address.  weeks later, you go to claim the BCH via Coin Control.  how do you set this tx up using the blockchain truncating Trick?

You don't, that UTXO does not exist on the backtracked copy of the chain you have.

will Armory actually dump it into the same change address created from the original BTC tx?

No there's no guarantee of that. If you use the same wallet file, you will get a fresh address every time, otherwise, who knows.

You're doing it wrong with the fees. Go into coin control, pick the outputs you want to spend, then in the recipient frame, click "MAX". This will guarantee it will move all the coins it can to the target address without leaving anything for change. That's how you want to go about moving that stuff.

[alomar]

it's been years since i've updated the offline signer.  can you link me to the download version for BCH signing?

edit:  nvm, i got it:  0.96.2, i think.

[gangtraet]

There is now a 0.96.3, you probably want that one, at least if you ever plan on creating a fragmented backup.

[alomar]

There is now a 0.96.3, you probably want that one, at least if you ever plan on creating a fragmented backup.

why don't i see any specific "offline bundles" on it's Release page?   https://btcarmory.com/0.96.3-release/

[alomar]

ok, got it to work with latest release.  nice tool.

mentioned some issues in RC1 thread.

[Begru]

Now with BTC on the Hot Wallet its working fine with the BCH signer on BCH chain.
My question now is about the Cold Wallet, is there any possibility to do the same?
I dont want to get my cold wallet change in a hot wallet.....

[Carsten83FFM]

Quick Q: Is the BCH signer supported for multi-sig transactions (lockboxes)? Is there a way to select BCH Signer for when creating a multi sig transaction? If not, is this a particularly easy thing to add - ability to select BCH Signer in Lockbox mode - or there are no plans to include this?

Background:
I finally got the Bitcoin ABC & Bch Signer working in a VMWare Ubuntu instance.
I'm able to see my BCH balances correctly both on regular wallets and my multi-signature (lockbox) wallets.

But, I can only select the BCH Signer for when doing transactions using regular wallets. I can't get it working with the multi-signature/lockbox wallets.

Is there any way I can at least just get the BCH out of there by somehow manually crafting the BCH signer multi-sig-transaction? (I don't mind even just sweeping private keys, but these funds are sitting in a multi-signature wallet, so I don't believe key swiping/export would work there, I don't know).

EDIT: I'm in the process of going through Bitcoin ABC node and seeing if I can manually do a multi sig transaction that way by importing private keys.

Image of when doing a Multi-sig/Lockbox transaction, error returned:
non-mandatory-script-verify-flag (Signature must use SIGHASH_FORKID)

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

I'm in a similar situation. I understand that currently Armory does not allow to sign such transactions using the BCH code. Do you know of some other way I can access the BCH stored in lockboxes? Some crude export/raw hex/import/CLI magic would be a great workaround.