Try with the testing builds.

Got what I need.

Start BitcoinQt on its own, make sure it's running against your custom datadir and that it's fully synced.

Upgrade Armory to the latest testing builds, delete your DB folder (C:\Users\user\AppData\Roaming\Armory\databases) and boostrap the DB.

You can learn how to path for Armory here:

https://btcarmory.com/docs/pathing

Double check your setup against this for the good measure.

rebuild & rescan.

Update to the testing builds.

Post all your logs using pastebin

I'd have to look into it.

Post your logs, in full.

That's technical debt inherited from the Python code base. I don't really want to dedicate time to this since there is the fallback of the wallet recovery code. The issue lies with the wallet code itself, not locales per se. Custom text fields in the Python wallets have a hard coded size for these, and while they check for the size, non ASCII chars can count as more than a byte, therefor the deserialization can fail.

My way of dealing with this is the new C++ wallets which simply won't have any such limitations to begin with, and have a whole lot more test coverage. I only have so much appetite for modifying mission critical Python code.

Update to this:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.0.4

Post armorylog.txt as well.


You should use the receive button, guarantees you don't reuse addresses.

Post your logs.

Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue.

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.

1) Yes, that does it.

2) The less RAM/threads you got, the longer it takes for the DB to build. As for how little RAM you can get away with, you're looking at:

a) Core eats around 3GB RAM. Most of its memory use to maintain the UTXO set, the bigger that gets (and it ought to with SW), the higher that requirement will go.

b) ArmoryDB needs ~1GB RAM tops to just run maintain itself and run the client, but it will be looking at ~2.5-3GB by default to bootstrap. There are cli args to reduce the resource cost of the bootstrapping part if you are running on a tight budget. You can also split the setup where you let Core bootstrap first, shut it down, let ArmoryDB bootstrap then run the whole stack to avoid concurrent costs.

c) Core needs space for blockchain data and its DB. 200GB should get you an extra year from August 1st maybe?

d) Armory's DB is fairly lean. Currently it's <1GB. 5GB should last you at least till 2020.

e) Assuming you have lots of swapping space, you could get away wtih 2GB RAM on a very lean setup. 4GB is better, 8 is what I would recommend.

3) Right now you want client and server in lock step. Once this stuff congeals (it came out in 0.95, we're at 0.96, so maybe another version or 2?), the requirement should loosen.

4) It would hold the address script hashes you register with it from your clients. That's WO data only, no chaincode.

5) This is the network stack:

a) Node talks to other nodes over the WAN.

b) DB tries to talk a node on localhost only (hardcoded), through 2 different ports, one for P2P layer, one for RPC. RPC is not mandatory but preferable.

c) DB listens on localhost (hardcoded again) as a FCGI service. Local clients connect directly through that interface, remote obviously clients can't, therefor you need you put a web daemon in front of that FCGI service (since it's works over HTTP) to allow for clients to connect to a remote DB.

d) Client connects to the DB/port you give it. By default it looks on localhost. There is currently no encryption of the client to DB layer, that stuff is for a future release. If you want to use TOR on top of the HTTP daemon, you would need to turn your daemon into a hidden service, run Tor on the client machine and somehow tunnel the daemon over localhost:port for the client to figure that out. Or you can VPN into the server VM. If the VM is a guest on your machine, you can just connect to the DB over whatever IP:port the VM makes itself visible as.

Neither the client nor the DB use nor need the WAN. All phone home code has been removed since 0.94. All possible operations that would open a browser to an external link (that's only to show you your tx on a blockchain explorer) come with a warning message box (in case you miss click it).

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.

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.

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.