Grab the next unused address in the chain


Scan all 1k addresses in the lookup.

Those are pointing to the dev branch, which is in constant flux. You can look at the code in the master branch:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/EncryptionUtils.cpp#L749


Private key N with the chaincode will let you compute all private keys beyond N. To compute private keys prior to N, you need all public keys preceding N as well. Both chaincode and public keys are considered known data (as they lay on online computers), hence the generalization that revealing a private key within the chain is as good as revealing all private keys in the wallet.

Keep in mind that you shouldn't treat soft derived BIP32 private keys with any less care, as the same property applies:


It is good practice to not reveal your wallet's private keys, regardless of the derivation scheme. Consider the wallet compromised if you did, and move the funds out.

That quote gives you links directly to the code.

Post your logs.

Use a 3rd party specialized in this. Deletion is out of scope for Armory. Note that it's significantly easier to reach "assumed safe" level of deletions with SSDs than with HDDs.

You cannot design a blockchain service that fully indexes your wallet's history against a node that prunes that very history.

A bitcoin transaction is broken down into 2 section.

1) Inputs point to previous outputs, they redeem the entire value of their respective output and make these available to the transcation

2) Outputs assign the available balance to new recipients. Any value that is no assigned is burned as fee.

The "sum of outputs" field informs you about how much BTC was redeemed by the transaction's inputs. The wallet assigns your spend value to the payment address, and the left over back to one of your addresses as change. In the transaction detail dialog you can see the change as greyed out.

You should always compare the sum of outputs value vs what you are paying, and if they differ, make sure your transaction has a change output. These are the baseline steps to verify your transaction before signing, besides double checking the payment address and spend value.


Armory had coin control before Electrum had deterministic wallets.

I'll keep pushing builds for older hardware, no reason to stop doing those.

Based on your OS. gcc4.9 is built on a dedicated offline debian 8 laptop. This is to provide builds for people who use older systems as their signer mostly.


CPU manufacturers add extra silicon on top of the baseline Intel x86 and AMD64 for specific calculations. Stuff like AVX, baked in AES, the old MMX and so on. All that stuff is instruction sets that are not part of the baseline. If you allow your compiler to build against those, you get a performance boon, but older CPUs without the dedicated silicon can't run the software. If you turn off the compiler's access to these instructions, the code will run on anything that's x86/x64 compliant.

The "No ASM" tag signifies that these optimizations are turned off. This is due to how they get enabled the in the first place: GCC will read the C++ code and interpret it into assembly. Assembly code isn't very human readable. The lingo just isn't intuitive, and revolves around registers, which are specific addresses to certain CPU resources.

A simple example: in C/C++ and any other language designed for humans, you perform additions by writing them out as you would on paper. To add a to b and get the result in c you do "c = a + b". In Assembly, you'd have to load a in the first addition register, b in the second addition register, and read the result in the result register. This is why we use compilers, to avoid having to go through that mess.

The extended instruction sets  you see in modern CPUs allow you to perform some operations much faster than just using the plain old x86 stuff. One example is pulling 2 128bit integers and adding or multiplying them in as little as 3 cycles instead of breaking down the operation to multiple 32 or 64 bit operations, each costing a few cycles.

Now don't get the wrong idea, the compiler doesn't interpret your code to use extended instructions on a whim. This typically has to be enabled by humans, and more often than not you gotta get your hands dirty and implement in pure ASM to squeeze performance. In the case of Armory, the crypto library it uses has a bunch of these assembly sections to leverage extended instructions, most notably for AES. In this case, NOASM means "turn off all of these optimizations, just use old x86".

The goal is to allow people to use Armory on older hardware. It goes in line with using gcc4.9, to allow for older machines to be recycled into offline signers for the most part, since the performance cost of offline Armory is negligible even on 20 years old machines. The builds with recent GCC has a all optimizations enabled and is meant for recent machines using online Armory, which is resource intensive.

This feature is long dead and I'll remove all BCH signer code in the next release to boot. Therefor, I'm going to unsticky this thread.

Try the noasm .deb

Update to 0.96.5, delete the DB and start over.

The issue is more PyQt than Mac tbh. Some modules depend on OpenSSL (QtNetwork is the chief culprit), and PyQt includes everything Qt has to offer by default. Using Qt at the C++ level, you could probably avoid that kind of overzealous linkage.

Qt

You should skip these two, they complicate your setup. Let Core handle that pathing for you. Once you're setup properly, they will default to these :


**************************************
Bitcoin Core setup:


This will allow Bitcoin core to use this path for its settings. You need to customize the Core settings for your system:


Start bitcoin-qt from the shortcut and let it download the blockchain.

*******************************
Armory setup:


Same as with Core, this tells Armory where to look for its settings and wallet data. Now for the Armory specific settings:


Once Core is done downloading the chain, start ArmoryQt with the shortcut and you should be good.[/code]

Armory wasn't invoked with any of your command line arguments. I don't know why you're putting spaces everywhere, that will definitely break paths.


This stuff is just insanity. Give me the path for your Armory Data and Bitcoin Core data, I'll tell you how to setup.

ASCII is basically the western alphabet encoding. If you are using "exotic" characters such as Arabic, Chinese, Hebrew and the like, they cannot be encoded with the ASCII standard, you'd have to use UTF to represent them.

The folders you referred to are for the binary installation. The "install" I am talking about is the where on your system the Armory wallet and settings are saved. This is a different folder from the one that holds the binaries.

On Windows, it defaults to:


Where *username* is the name you have given to your user account during the Windows install. If this name uses non ASCII characters, Armory will fail to run.

You need to first confirm this is the issue, then set your Armory user folder to an ASCII only path. For that, you need to create a shortcut of ArmoryQt.exe and add "--datadir=*custompath*" in the target box, where *custompath* is whatever folder you choose.

You can search the web for "ASCII table" for the list of acceptable characters for the custom path.

Do not install Armory in a folder that has non ASCII characters.

Armory is warning that it has to unrelated UTXOs together to meet the value of your desired payment. This erodes your privacy because if you move forward with this transaction, all these UTXOs will now be related.

There is no risk of coin loss, just privacy loss. Financial privacy is significant however, don't damage if you don't need to.

What you can to go around the issue is manually select UTXOs you know are fine to mix/use for that particular payment.

Then he went full Kubernets. Never go full Kubernets!