Post armorylog.txt and dbLog.txt

That file is basically empty from the looks of it. If the repair tool couldn't pick anything and the header is all 0s, this is my current conclusion. Do you have other backups (that were not on the device you saved these files on?)


Restoring from a paper backup creates a 1000 address lookup. Regular wallets start with a 100 address lookup, and rarely do users go over that. It is highly unlikely 1000 address won't cover your entire history. At any rate, you can create 10k addresses just to make sure.


MAX_PATH on Windows is 32768. Length is probably not the issue. Look out for non ascii characters in the path instead.


You saying trying to run the repair tool with no wallet loaded hangs?


Refer to the first comment.

Are you sure this wallet is for Bitcoin mainnet? You should run it through the wallet repair tool and post the output log here.

let's see armorylog.txt

I suggest you don't automate bitcoind until after your system is stable. If you automate bitcoind, let the client automate the DB as well, ie just start the client and shut it all down by just closing the client.

The client always needs a DB to operate. If it fails to find one, it will spawn on one automatically. As such, if you want to manage the DB yourself, you have to start it first. It does not matter which order you start the DB and the node, but it's always preferable to start the node first and let it catch up with the network.

If you run BitcoinQt manually, you can shut it down whenever you want, it runs independently of the DB and the client. If the client automates your bitcoind instance, close the client and let it handle the rest.

As for the DB, if the client spawned it for you, just close the client. If you are running the DB manually, you can shut it down whenever you want. It's still preferable to shutdown the client first if there is one running against that DB, but that won't damage the data set one way or another.

In Files -> Settings, either force the path to the binary, or turn off auto bitcoind entirely and run BitcoinQt manually.

The address has everything he needs. If he uses that addresses, it will result in a nested SW output on the network.

That's way off, current top block is in the 440k. You need to let Core sync first before doing any of this. The DB only taxes your system on initial build. It shouldn't do a thing when it's idling. But since you are short on blocks, chances are it is scanning as Core is grabbing blocks off of the network.

You can control the DB's CPU load with --thread-count.

How would he be doing this?

You at least need to know the public keys of your recipient to craft the output yourself. Neither P2PKH nor P2SH output scripts give you that information. Same with the native SW outputs. The only way you got to do this is by lifting the public keys of your recipients known addresses from the blockchain.

There is no mechanic in the bitcoin protocol to prevent someone from spending coins to whatever script they want, but that's basically the same as black-holing coins at this point. If you are afraid your wallet will do this with your coins, that's not how it's supposed to work at all.

You need to understand how bitcoin outputs are constructed and how they are redeemed, particularly P2SH. The whole point of P2SH is to let the recipient determine the redeem script.

Armory wallets predate BIP32. The format is not compatible.

You don't have to tell them anything.

No, if it works, you don't have to

1) Delete your db (/Users/lykle/Library/Application Support/Armory/databases)

2) Delete dbLog.txt (/Users/lykle/Library/Application Support/Armory/dbLog.txt)

3) Run Armory, let it build & scan, then post dbLog.txt in here.

At first glance, your blockchain data is damaged around block 340k

Yep, gonna need to see dbLog.txt too.

Log files.

If the P2SH is a nested SW script, that's the idea.

I'm not sure what the behavior in armoryd is supposed to be. This is one part of the code base I've not worked on directly, and it has been neglected since I've taken over. What you are describing sounds like a bug, I would have to look at it specifically to tell you what's what. Sadly, I will only have time for that until after 0.96 goes into testing.

What branch are you using?