Anywhere between 3h to a week depending on your machine.


This isn't the official page since like 2 years. Get your releases from btcarmory.com or from the release page of the repo (https://github.com/goatpig/BitcoinArmory/releases). Make sure to verify the signature on whatever your download

Using Armory, move your coins in nested P2PK scripts to P2PKH.

You have too little RAM, maybe the DB is hitting the oom manager.

For now you should:

1) Delete the content of your DB folder (C:\\Users\\Jaye\\AppData\\Roaming\\Armory\\databases)

2) Make sure auto bitcoind is turned off in File -> Settings (the first option group). It looks turned off but verify that for the good measure.

3) Without starting your node manually, start Armory and let it build its DB. Monitor your RAM while it's doing this. If it get oom killed, you'll have to change some settings to reduce the RAM usage.

Show me your armorylog.txt

Turn off RBF. Blockdozer is just bad like that.

What OS are you using? Otherwise grab the condensed log from the File menu from within Armory.

Coinmi most likely does not support the script types. There are quite a few steps to go from a private key to an on chain script. You have stupidly tried to import private keys as is, which has now completely exposed your wallet. You need to move your coins out of that wallet asap. Sync your node and db and move the coins out the regular way.

Yes you do, Armory is a fullnode wallet. Just let it run its course.

Post armorylog.txt and armorydb.txt. Use pastebin.


You can export the private keys out using backup center in the wallet properties dialog. Start in offline mode if you're going down that path.

You failed to do your due diligence and shifted the burden onto others. This isn't a matter of offense, more like a matter of taking your own responsibilities.

Update.

Are you trying to force my hand at writing a guide? This is all over the place.

I'm assuming B2X is the chain with the least blocks for the entirety of this post, makes like simpler. I'm also assuming BTC and B2X maintain the same median block rate (i.e. they both add a block every ~10min or so).

--- Setup ---

4.c) The use of auto bitcoind is asking to get shot in the foot. Take the extra minute to run the relevant node manually. Auto bitcoind is just too unstable for this purpose, and you'd need to monitor processes to make sure it shuts down in between swaps, which eats into the convenience benefit. If you're gonna bother explaining how to swap around between chains, you should explain how to run b2x and core concurrently on 2 separate VM/computers instead.

4.g) You are complicating things with one script ruling them all. If you want to switch instances around, have 2 scripts/shortcuts, one per side of the chain, and have them each summon the node as well as Armory. Easier to tell them apart, you get a node GUI and you don't risk mixing up manually spawned nodes with the wrong Armory instance. Also easier to confirm the node has shut down.

4.k) Don't know where you are going with this. Just create and backup a wallet that is exclusively meant to receive your B2X. Load your BTC and B2X wallets on the B2X Armory instance. Load only your BTC wallets on your BTC instance. More on that later.

4.m) You don't need those. This is potentially a privacy leak if the explorer service logs your IP against your searches.


--- Tainting ---

5) You don't care for hash rate, you only care for block height and median block rate. Again, we assume BTC has a higher block height than B2X.

6.c-d) Start your BTC Armory instance. Go to the Send dialog. Pick your BTC wallet as the sender. For recipients, pick your BTC wallet as well. This will grab a fresh address in your BTC wallet. Open the Coin Control dialogue a pick a single UTXO. Check "MAX" on the recipient entry, next to the value field. Manually input a fee above average. Sign and broadcast.

This makes sure of a couple things:

First, you are sending these coins to yourself with no change. You don't need change for this, you are sending back to yourself after all. Second, you are moving a single, whole UTXO. This is the only way to protect your privacy, by moving your UTXOs one at a time without change. Lastly, you want a big fee because you want to get mined in the next BTC block.

6.g) Once you have 1 conf on the BTC chain, shutdown the BTC instance and start the B2X instance. Here you will perform the exact same spend but send to your B2X wallet instead of your BTC wallet. Obviously pick the same UTXO as with the BTC transaction. You are trying to send to a different address on the B2X chain. That's the whole point of tainting, to get an output on one chain that does not exists on the other.

Do not forget to spike the fee even higher than with the BTC transaction. You want to get in the next B2X block and you want this tx to have a highest fee of the 2 if it fails to mine quickly.

Once you've got your confirmation on the B2X chain, you have a tainted UTXO. Rinse and repeat with each of your UTXOs. If you have trouble keeping track of which UTXO needs tainted on your BTC wallet, either keep track of it through the B2X instance or use a fresh wallet on the BTC side to receive the post fork coins.

7) DO NOT DO ANY OF THE STEPS IN SECTION 7 OF THE ORIGINAL POST. You will forever link your coins together and erode all the privacy you ever had. You can attempt to obfuscate your coins later but that requires using 3rd parties or coin-joining with other users. It's lengthy, potentially risky and onerous. And it doesn't change the fact that there is an IMMUTABLE AND PUBLIC EVENT linking all your coins together. Be diligent and taint your UTXOs one at a time. Also let's be real here, if you won't take to move your UTXOs one a time, would deploy the larger effort that is to tumble your coins once you're tainted?

Lastly, keep in mind that both chains can erode your privacy. Don't go around lopping all your coins together on one chain post taint thinking that you're now safe. It will shit all over your privacy all the same. Treat both side of the chain with equal diligence when it comes to your privacy, regardless of what you dump.

--- How does it work ---

There is no such thing as a replay attack in this split. B2X uses the same tx format, same signature and same port as BTC. When you push a transaction on the network post split, not only your intention cannot be told apart (was the tx meant for BTC or B2X?), but both chains will see it as valid. Do not imagine there are nefarious actors out there making a point of replicating the BTC mempool in B2X and vice versa just for the sake of disruption, this is built in B2X! Makes you wonder who the nefarious actors actually are...

Anyways, the method I outlined works thanks to the tx locktime. Armory will set the locktime of its transactions to current top height. This is a measure that was introduced in Core to dampen selfish mining attacks scenarios. What the locktime field does is to signify the block height starting which the transaction is valid.

The idea was to reduce the incentive where a miner tries to steal transaction fees from other miners by orphaning their blocks and stuffing his with the juiciest fees from blocks he orphaned, since he'd have to mine at least as high as the current block height to steal the most recent fees. Otherwise there are scenarios where a large miner would profit from orphaning consecutive blocks from small miners.

In our case the locktime is useful because the 2 chains will eventually diverge in block height. This means the tx you create on the highest chain will be invalid on the lowest chain, irreverent of hash rate or difficultly, as long as the shortest chain has not caught up to the height your tx is locked for. To give an example (rounding numbers for simplicity):

BTC is at block #500,000
B2X is at block #499,990

The tx Armory creates on the BTC chain will be invalid on the B2X chain until the B2X chain grows to height #500,000, i.e you have 10 blocks worth of time where you know your tx can't be replayed on the B2X chain.

This is the window you want to exploit to taint your coins. This is why you want to get mined asap on the BTC chain to begin with, since that keeps the window as wide as possible. Assuming in the previous example that your tx gets mined in the first block, i.e. #500.001, that puts B2X at block #499,991 and you have 9 blocks till your BTC tx is mineable on the B2X chain. That should be ample time to RBF on the B2X side.

Basically, as long as the height difference between the 2 chains is significant enough (as low as 5 blocks could do), you are guaranteed a comfortable window to RBF your tx on the shortest chain. You make a point of bumping the fee on the B2X chain just to make sure that if you don't get mined on the B2X chain in the locktime window, your B2X tx still will take priority over your BTC tx after B2X catches up.

--- But but, doing it this way increases my cost in fees to taint! ---

Marginally. You still have to pay a baseline sat/B to move all your coins, whether you do it one UTXO at a time, or taint a single UTXO and crunch all of your coins together into privacy purgatory. Also consider that you stand to make much more from dumping the shitcoin (I'll let you decide which one it is to you, though I sure know which one I'll drop like a diseased crack whore) that what you will pay in fee to make the shitcoin spendable in the first place.

Ok ima clarify this hopefully once and for all. If I say update, it means update Armory. You're on the Armory forums, aren't you?



To a version from April. At least do the effort of reading the sticky on this forum before posting. You are not encouraging me to help you.

Update.

There is no signer support to add.

0.96.3.99 is 0.96.4 RC1

You're not supposed to click "Done", you're supposed to click "Sign".

SegWit is off by default. Activation is detected by the node it is running against. Therefor an offline instance cannot detect SegWit activation, which is why you need to manually enable it.


Some event increased the address chain without registering the new addresses. On the next run, they have to be scanned.

Delete your DB folder, try again. "latest version" doesn't mean anything, name the versions in full.

When reviewing the transaction, does it flag the inputs as belonging to your wallets? They should be identified through the walletID next to them. Also, is Armory warning you that the tx is not for your wallets?