Topic: Bitcoin Cash (BCC) and Armory (Read 6484 times)

Come on guys, it's been stickied since the 6th...

Yes, this would be vitally convenient. Tip if you do so!

So there will be an option to send the BCC straight from armory, saving me the hassle of individually exporting private keys, and importing them to some BCC wallet? That would be really sweet :-). Thanks in advance goatpig. Will certainly make a donation for that new feature.

Thanks goatpig, looking forward for the bitcoin cash armory

Make a new wallet in Armory and move BTC before the split to it.
After the split move BTC to your normal wallet again.
Then export the key from the tmp wallet and move BCC.
Thats how i do it.
Once done the tmp wallet will be deleted.

Remember to empty your entire Armory wallet of BTC before you export private keys to something less secure.  I am 95% sure that if somebody gets two private keys from the Armory chain, then he has them all.   And if somebody has just one private key, and the chaincode which is unencrypted in the watch-only wallet, then all following private keys are compromized.

I'll just move btc after the split to a new address and then export the keys of the then empty btc addresses.
Import into bitcoinABC and send with their wallet.
As long you've the private keys you can handle it how ever you want.
Just make sure you don't use the addresses where you exported the keys and imported to online wallets.
If you want to be sure you could create a tmp new armory wallet. Move BTC before the split to it.
After the split move them back to your normal wallet and then export the key(s) from the tmp wallet and import them into an ABC supporting wallet.
If you don't plan to spend them you could also just name your tmp wallet "ABC" and keep the coins there.
Even if you can't spend them (yet) with armory they would be secure in Armory.

99% chance that stuff won't go anywhere. Just wait and see. If it looks like it's gonna last more than 2 weeks and there's demand to move coins on that chain, I'll update the signer to work with their replay protection.

So what is the advice for Armory users post Aug 1st hard fork?

You can check your balance on their chain, you can't spend unless I implement their sighash change. Won't bother unless their coin survives the initial 2 weeks.

Not anymore. BitcoinABC has now strong replay protection.

I don't know if this changes the compatibility with Armory.

As long as you deliver the split coins at some point... The issue is having a tainted operational stash to work with in the mean time. You may want to buy a coinbase UTXO once they mature. They should be widely available 1-2 days in.

I'll just monitor and wait a few hours or days to do the split.
A pure blocksize increase HF would've been easier with big mining/community support.
The real difficult part is now splitting and not the fork it self.
But guess nothing we can do at all. If someone decide to split off and gets some mining support then users want coins on that split also.
Even if that split it self would be pointless...

Somehow not surprised about this. No matter, RBF still works to taint. Either anything but a 0xFFFFFFFF input sequence is invalid on their chain and you are guaranteed to create unreplayable tx on the main chain by virtue of that change, or they simply made RBF non standard (just won't broadcast the double spend), which makes the move even easier, as you can double spend the tx on the main chain without waiting for a conf on the split! This change basically guarantees a taint in a single hop with RBF.


I wish they did, but they have not been in touch with me at all, nor other people that have approached me about this. Not to make myself seem important but Armory is one of the few fullnode wallets out there, therefor one of the easiest to support a split with. You'd imagine they at least approach me for support, since it is infinitely less work for me to implement support than it is for the likes of Coinbase (who outright turned them down) or Electrum.


That wasn't a criticism of any one service in particular, rather making a case that a 1 year activation period is actually sane and desirable for an opt in feature, let alone a HF. But naaaah, changing a 1 to a 2 is so simple, what could go wrong?


I would still push on ABC first then Core. If ABC gets miners, it will be hashing power lost from the main chain which will slow down, whereas ABC intents on retargeting the difficulty manually for their HF. With that, their 2 MB block size (plus the 8MB default EB lmao) and the most likely meek adoption, fees on the split should be dirt cheap whereas they will spike on the main chain at least until the next retarget.

And if they effectively don't support RBF (I'm guessing they using the BU change that won't broadcast the 2nd RBF), then it's painfully easy to taint with that, regardless of fee rate or throughput.

I agree about the rushing part.
Lot work for me as well to make sure users can access their coins on all possible chains.
Atm i run 4 different nodes with armory on top where it seems that only 2 will be needed in the end.
They run on 4 different machines as well so no mixing between data directories.
RBF is removed on ABC...

I think they should have contact the major wallet developers and exchanges with their plans and offer help.
It would be in their interest to have most wallets and services working with the split.

For BTCPOP SW isn't ready either. I'm prepared but didn't spent much time before on it when chances was big it would never happen.
As Legacy transactions on the legacy chain will still work there is also no need to rush things in.
Guess for the split of coins easiest for me would be to create 2 new wallets. One called ABC and one Core.
Send on Core chain coins to the Core wallet. Wait for 1 conf.
Send same inputs to ABC wallet with higher fee.

Can't really do that on such a short notice, with no testing. It's just not safe, somehow the HF happy crowd does not realize the world isn't about them and the ecosystem needs time to upgrade. In perspective, consider SW has been in its signaling period for over 9 months and still some service providers have not updated yet.

If their fork survives the first 2 weeks and they finally decide on a sensible way to provide replay protection, then I'd consider adding it. If you want to taint to short, it's on you to be proactive with existing tools to jump on the opportunity.

Armory will work the ABC/BCC/whatever node as long as it respects on disk block format and uses the same P2P layer (although that can vary to an extent, Armory uses maybe 30% of the P2P layer messages).

That's for node compatibility. Replay protection is another thing.

The issue with this kind of rushed forks is that their standard has not even congealed in their heads, let alone on paper/code. I'd suggest you ignore their replay protection proposals and just taint the regular way, i.e. get a tx on one chain, double spend the utxo on the other.

The way to do this is to send a utxo back yourself over and over again until you hit the condition to double spend on the other chain. You have 2 ways around this:

1) If the 2 chains have a consistently different block heights:

Achow's LockTime method is the simplest. You would do it like this:

With 0.96.1, Armory conforms to Core's LockTime guidelines, where it set the LockTime of a Tx to the current top block height. This means the tx can't be mined until the chain hits this height (this is originally to prevent aggressive fee stealing orphan attacks between miners). Post split, you want to use this method on the longest fork first. The locktime guarantees the shorter fork can't mine the tx for a while. Once the tx gets on chain A, you can double spend that utxo on chain B, then taint your coins with the resulting output accordingly.

To do this, you need both nodes for both sides of the fork, pick an output with coin selection, spend it on the longest chain, swap back to the other node, create another tx with the utxo and spend it. You don't need to bother with the locktime field, as Armory sets it to the top block on the chain it is being run against. The only thing you really need to pay attention to is making sure you don't mix and match DB's and chain folders or you'll probably nuke your DB, and you're in for a rebuild & rescan.

Once you have the 2 tx (one on each chain) with a different txid, you're good to go. Use the output newly created with the coin selection GUI to taint your other coins as you see fit.

Note: the locktime feature was introduced in 0.96, but a bug in the in legacy txsigcollect message (the blob of text spit out to pass in between online and offline instances) makes it that the locktime is always forced back to 0 by the signer. Therefor, you need 0.96.1 to do this properly (0.96.0.4-testing has the fix). You need to update both signer and online machine for this work.

2) If the 2 chains have a narrow chain length gap but different transaction throughput:

Use my RBF trick: Create a RBF tx that has a fee low enough that it won't get mined anytime soon on the chain with the low throughput, but will get mined quickly on the chain with high throughput. Once it gets mined there, use the RBF GUI to double spend the utxo in another tx, this time with a large fee so that it gets into the low throughput chain quickly (again the goal is to get 2 tx with different txids on each chain).

You need an online 0.96 to RBF, the offline signer can be as old as 0.92.x. If you are using the script types, you'll need to upgrade your signer however.

In both cases, you are just sending coins back to yourself until you get your condition to double spend on the other chain. This is low risk (you're paying fees over and over at worst) and even with very similar chance, you have a good chance of pulling either method off if you persevere.

Still a risky thing what could need several attempts.
1. TX on the main chain with low fee what would confirm on the main chain but not on the ABC chain.
2. Once TX confirmed on the main chain, double spent on the ABC chain with high fee.

That was my plan for possible splits without replay protection.


I would assume that they include transactions made before the split but not accepting new ones with old TX format.
On the other side I think users who care about the split should make sure to not send BTC what wont confirm till the split is done.
I agree that we should wait till the split is done.
Still would be nice to have the TX format with replay protection in Armory then.
I would assume that many armory users want access to the ABC coins as well and if its only to dump them as fast as possible on some exchange. ( Without the need of double spending to split them)

Assuming that they don't change the transaction format or make it impossible to make legacy transactions (i.e. transactions that you make now), then Armory should work just fine. It would be very stupid of them to not accept legacy transactions since it would mean breaking all unconfirmed and timelocked transactions at the time of activation.

Considering that they are still trying to figure out what they want to do, I suggest that you wait until after they fork off before figuring out what you can do to avoid transaction replay.

Either way, Armory does have some replay protection built in, in the form of the transaction lock time. Armory will set the transaction's locktime to be that of the block height at the time the transaction is created. This means that the transaction can only be included in blocks which have a height greater than or equal to the specified locktime. When Bitcoin ABC forks, they will almost definitely have a minority hashrate so their blockchain will grow more slowly (although they do have a difficulty adjustment thing), so their blockchain will be at a lower height for a while. So while their blockchain is at a lower height, you can make a transaction on the main chain and it will have a locktime block height greater than that of the ABC's chain height. Once that transaction confirms, you just move to the ABC chain and make the same transaction there, but without the locktime. The second transaction would be a double spend on the main chain, and it should confirm before the first transaction is able to on the ABC chain. Once both transactions are confirmed, your coins are split.

So Armory should just work with BitcoinABC as node?
I just read on their reddit:
"We are currently considering accepting only such protected transactions (currently it is still possible, by opting for it, to get non-SIGHASH-FORKID transactions relayed and mined).
Interested parties are encouraged to read REQ-6-1 , REQ-6-2 and REQ-6-3 of the UAHF specification."

Transactions without the SIGHASH-FORKID would be broadcasted also on the Bitcoin chain and would be terrible/impossible/hard to handle.

My plan was to move the BitcoinABC coins after the split but not my Bitcoins.
Another security aspect is that the signed TX would probably be valid for both chains?
That would mean I would need to move my Bitcoins as well when moving on the BitcoinABC chain?

Armory does not verify on chain tx. It does not process scripts unless it's for its own signing purposes. No amount of new op codes would make a difference. The only thing that matters is block serialization on disk and the P2P layer.

What i've read chances exists that they wont be included in blocks on that chain but not sure on that one.

Their transaction replay protection is all opt-in. Transactions on Bitcoin ABC are still in the current transaction format.

BCC will use another TX version as replay protection.
I think Armory can't send coins per default on that chain after the split.


"How is transaction replay being handled between the new and the old blockchain?
Bitcoin Cash transactions use a new flag SIGHASH_FORKID, which is non standard to the legacy blockchain.  This prevents Bitcoin Cash transactions from being replayed on the Bitcoin blockchain and vice versa."
https://www.bitcoincash.org/

Run the node you want.

What's the situation regarding that matter?