Also, please double check these wallets on the GUI version.

Are you spending without change?

I haven't tested this broadcasting code directly but it looks valid. You should figure out if the tx is valid at first. I suggest you look at your bitcoin node debug log to identify the error message attached with this tx. Once you have figured if the it's the tx that is off or the broadcasting code, we can figure out the next step.

And he still hasn't provided that level of details. Are the wallets offline or online? How long are the passwords, do they contain easily identifiable tokens? Does he use the password same for each wallet? Has he manipulated his wallets within the week leading to the event and how? What about month? Has he changed encryption on his wallet recently? Does he has cloud storage backups? What password do they use? Does he know of the addresses that received the coins? Has he scanned his online machine for infection? Any logs we can look at?

I've spent enough time on this. Short of some new significant evidence, this is in the hands of the community.

What has bitcoind to do with this? Have you imported your private keys into a Core wallet before this event? Armory wallets are entirely separate from the underlying node. Armory never communicates private nor public keys to the Bitcoin node, nor does it need to.

This is 1/3rd of the story at best.

We are talking about 5BTC, split in 2 wallets, ~2.9 BTC in wallet A, ~2.1 BTC in wallet B.

On May 6th, 3 transactions in block #410492 moved coins from wallets A and B to address 18mhcZ4tdD2GQquSrMda5TPzgRodAEfYeF:

- tx 1&2 move all coins from wallet A. All coins in this wallet were split between 2 addresses. The spending tx each sweep one of these addresses.
- tx 3 moves all coins out of out of 1 address from wallet B, about 0.28 BTC.

In all cases, there was no change and all outputs were spent regardless of how small they were (a few were >0.02 BTC). This pattern is indicative of a private key sweep.

However, all transactions came with small fees. All fees were >0.002BTC. Considering one of these tx spends 10 utxos and another one 7, we're far below the proper fee/kB for quick confirmation. The fact that all 3 tx were confirmed within the same block with such low fees is possibly an indicator that they sat in the mempool for some time.

This to me doesn't characterize theft, rather deliberate private key sweeping. You would expect a thief targeting your private keys would be sophisticated enough to pay a 0.01 total fee on 3 tx stealing some 3 BTC just to get included in the next block.

This accounts for ~3.2 BTC. If the story ended there, and you claimed 3.2 BTC were stolen, then you would have more evidence supporting your claim than otherwise. The fee analysis alone is not strong enough on its own refute theft. However, you are claiming 5 BTC are missing, and the last ~2 BTC leave your wallet in a different fashion.

---------------

About half a day later, in block #410581, 6 transactions move coins from wallet B.

- 5 tx spend to address 1CDyeeCHcReYhfaeTb37Piwq8ZWqLtHU5o
- 1 tx spends to address 12DaNV3b6iSobe5uMwBELYdMkoLJ1V4eto
- 4 out of 6 addresses return change
- As a result of change, wallet B currently has a balance, albeit rather small. Nonetheless, this balance remains larger than some of the smaller utxos that were redeemed among all these transactions.
- The fee/kB density of these 6 transactions is over 2~3 times superior (guesstimate) that that of the first 3 transactions.

---------------

It is also notable that prior to these 9 transactions, you only spent coins once, from wallet B, in November 2015. This implies, in case you use online wallets, that you rarely if ever typed in your password to decrypt your private keys. The point is moot if your wallets are offline. On the other hand, there is not much to discuss if your wallets are online and unencrypted.

This observation narrows down the possible attack vectors. Since you didn't spend any coins for months prior to the event, this couldn't have been an attack on the recipient address (swapping a payment address for the attacker's), nor an adversary process trying to steal your password/encryption key or decrypted private keys in RAM. This also rules out RNG snafu.

Again this point is moot if you toyed around with your password a few hours before the coins moved. This comment in particular and this post in general should be a reminder that you need to provide as much details as possible if you hope to find out what happened to your coins. Your wallets only speak that much.

The only credible attack vector that remains is that someone has access to your encrypted wallets (physical access to your computer, cloud storage backup, infected machine, etc...) and your passwords (possibly brute forced if they are weak, again need more details here). However, this would contradict the sweeping pattern: why sweep private keys if you crack a wallet? Just spend it all in one go.

Still this doesn't explain why the attacker would sweep all keys from one wallet and only ~15% from the other, nor his spending pattern (you'd expect 1:1 spend address to wallet address, or a single address for all wallets), nor why he deemed useful to return change, nor why he paid low fees to steal >60% of your coins and much higher fees for the remainder, and lastly why he did it 12h apart.

There is a set of transactions moving coins from your wallets but again the pattern does not reflect theft, rather deliberate spending. It would make little sense for a thief to steal your coins the way this was done. Without further investigations, I cannot qualify this spending pattern as theft.

To confirm or infirm this case, you would need to present more information and/or enlist the community into helping with the investigation. You would would have to at least divulge the addresses involved, your spending habits, and whether you know the recipient addresses.

I cannot assert if this is theft with what information I have, and so far I remain skeptical.

Your wallets helped me identify and fix 2 GUI bugs, but nothing in there indicates the balances are off.

Most of the wallets funds were moved in some 15 transactions, all spending coins to a same address. Half of them had change, and the pattern does not suggest someone stealing coins or trying to sweep the wallet, rather deliberate, incremental spending. I invite you to look into that, notably that one recipient address.

https://github.com/goatpig/BitcoinArmory/tree/master/PublicKeys

You can find my key here.

Armory uses the same package verification process as Bitcoin Core:

1) Check the sig on sha256sum file vs my public key (https://github.com/goatpig/BitcoinArmory/releases/download/v0.94.1/sha256sum.asc.txt)

2) Hash the package you want to check, verify the hash and file name match what's in the signed sha256sum file

It will use the default folder lacking any specific CLI arg, i.e ~/.armory/databases


ROMix I believe.

Click the receive bitcoin button to reveal addresses once it has been scanned. Also, pick expert mode to see the backup option for printing out private keys.

You shouldn't export private keys though, you should spend from the wallet or just sweep it entirely.

Restore from your paper backup. WO wallets do not carry private keys.

No I meant picking Rebuild & Rescan in Armory's Help menu...

Do a rebuild & rescan

Looks like it happens under certain (yet to be determined) conditions when the sender address is used as the change address. Will let you know when I figure out the bug and fix it.

Restoring from a WO backup is what got you in this situation to begin with. WO wallets do not carry private keys. You need private keys to spend coins.


Yes, you should have done that to begin with.

Somehow you turned your wallet into a watching only copy, which you can't spend from. Find your backup and restore from that.