Help -> Rescan Databases

Are you using some really damaged HDD? Or a USB 2.0 external drive? Maybe a network drive over a 100BASE-T? It sounds painfully slow and nothing close to what I have experienced. I built Armory's DB in 4-5 hours on an old HDD (160GB sata 1) a couple months ago. Takes shy of 1h30 on my SSD RAID0 currently.

Glad to hear it went well, although it wasnt database building for that long per say. Most of it was spent downloading the blockchain. Database building is around 1-2h with the current blockchain size.

https://bitcoinarmory.com:8443

Make a ticket, add in your full log.

https://bitcoinarmory.com:8443

Make a ticket and attach your log file (the whole thing)


Thats the gist of it, but it isnt limited to unencrypted private key. Pretty much anything crypto (public keys included) is held in mlock'ed memory. 

Nothing can be done about this. Some of Armory's stack is forced in the RAM through mlock. Hibernation copies the entire RAM into the swap partition. Since that would defeat mlock's purpose, mlock'ed memory is not copied imaged in on hibernation. Armory won't be able to recover from that.

We've received reports of other AVs flagging the blockchain or our DB copy of it over the past few months. All false positives obviously, but this isn't limited to MS' BitDefender.

There is currently no code in Armory core for the user to cherry pick ZC transactions in the backend container. You either wipe the entire container or use it as a whole. Granted it would be very easy to add, Im not sure that would fix your issue.

Bitcoin Core will not let you broadcast a transaction that spends a UTXO already consumed by a ZC transaction. You'd have to restart Bitcoin Core or somehow clear its ZC pool.

Submitting a Tx doesn't guarantee it will be mined, even if the network accepts it as valid. Im not sure the concept of "scrap" is part of Armory. What you should be doing is monitoring the number on confirmations of your broadcasted transactions against ("current top block" - "block the tx was broadcasted at"). This is how you will know whether your txn are getting mined or not.

Armory data files are separate from binaries:

Windows:
datadir: C:\Users\*myusername*\AppData\Roaming\Armory
binaries: C:\Program Files (x86)\Armory

Linux:
datadir: ~/.armory
binaries: /usr/lib/armory

The Armory installer affects binaries only.

Regardless, whether you plan to install, reinstall or not, you should secure backups of your wallets.

As for your direct question, you can simply run the new installer over an existing installation.

https://bitcoinarmory.com:8443

Make a ticket, include your log files.

Start in offline mode, do a Help -> Rebuild and Rescan Database, then restart in online mode.


That's the idea

Make a ticket, add in your log files.

Only coinbase transactions are subject to an enforced confirmation delay (100 or 120, not so sure anymore). Armory depends on BitcoinQt so it bends by its rules. You can even spend 0 confirmation transactions with Armory, unless you force it to ignore ZC.

While transactions will require a depth of 6 blocks to be displayed as confirmed in the UI, Armory won't prevent you from creating a transactions with low confirmation UTXO. Generally, the coin selection algorithm prefers older UTXO, so unless you have very few available outputs in your wallet, you will most likely never spend off of a low conf transactions.

It isnt necessary turn off bitcoin auto management in Armory as long as you have all your Bitcoin settings set in the bitcoin.conf (as opposed to passing them as command line arguments).

As for traffic, since you're on Windows, you can see what IPs each process connects to through Windows' Resource Monitor, in the Network tab.


Not too sure about this anymore. It's something like the Tor bundle uses 9150 and the Tor daemon uses 9050.

I mean do you chain transactions in a bulk or do you send like one a day?

Alan loves to respond to these types of posts with in-depth answers, including nicely laid out paragraphs, punctuation, proper grammar, bold and underlined key points, COLORS, and sometimes even pictures. So I'm gonna beat him to the bush with a half assed answer just to frustrate him =P

http://en.wikipedia.org/wiki/Elliptic_Curve_DSA

This is the basic math behind the EC signing scheme. Somewhere there, they give you the formula to get a public key from a private key, something like:

dA * G = QA

where dA is the private key, G is the base point of your curve, and QA is the resulting point on the curve. I wont go into the modulo part or the scalar vs curve point part. Im too lazy, and it's funny portraying Alan torn by this dilemma: knowing all of these omissions and inconsistencies are just baits, but being unable to resist his inner smartass.

So, there's some math property which names I forgot that let's you do this:

dA * k * G = k * dA * G

where k is some random number with the same properties as a private key. This means if you have a private key that is something like dZ = dA * dB, you could do something like:

QZ = dZ * G = dA * dB * G

and

dA * G = QA
dB * QA = dB * dA * G = dA * dB * G = QZ

Put in words it means that for a given private/public key pair, you can multiply both the private and public key by the same scalar and achieve a new pair of matching private/public keys. So to create a chain of public and private keys, you only need to create a chain of scalars, multiply your original (root) private key by these scalar, do the same with your (root) public key and get the matching public keys for all those private keys without having to expose them to the online machine.

I hope this reply answered just enough for you to want to know more, and for Alan to get fuming and hissing!

When you get in a state that crashes Armory, try to start it with the --offline switch. If it starts, then what you are experiencing is some sort of recurrent DB corruption. Do you use an anti virus or some sort of system snapshot recovery? What about HDD and RAM health?

Have you set your minimum fee to 0? And how fast do you emit these transactions?