In your case, you'll have to wait for 0.96

Grab the raw tx from Armory and broadcast from Core to get better verbose. Otherwise, wait for 0.96 testing binaries.

It appears cavirtex never sent you the coins.

What verbose did you get from Core on broadcasting the raw tx?

It does, whether the RPC works or not. The particular issue with the messed up cookie file is due to how the config file works with the testnet. When running against the testnet, Core still uses the .conf in the mainnet datadir to init, but will create the cookie file in the testnet datadir.

I can't reproduce the server=1 issue, can someone lay out the exact steps?

There are 2 separate code paths for this:

1) Requesting payment addresses. This defaults to P2PKH. I did not add an option to change the default in the settings dialog, I'll have to deal with it eventually.

2) Change addresses. If left on auto, the code will try to match the spend script type. If all spend scripts are P2PKH, it will create a P2PKH change output and vice versa. When pay script types are mixed, auto will favor nested change types. In case of a SW tx, it will favor nested SW, otherwise nested P2PK.

This helps privacy at the cost of converting to compressed keys (or eventually SW) by default. You can however force the change type default to whatever you want in the setting dialog. You will receive a warning about reduced privacy if your change type differs from the pay script type however.

The drawbacks are 2 fold:

You cannot sign for nested types with pre 0.96 signers, and you can't expect to see your funds by simply importing the private keys in another wallet software and expect to see the balance of the nested scripts. These probably don't scan for these P2SH variations. I will most likely mitigate that by offering disgruntled users an opportunity to scan their wallets against my DB on demand, to create a tx and move their coins out in one sweep.


This doesn't trigger the Qt signal for hitting the end of the list until after you release the bar. I'm not sure where to get the signal for that event (if there's even one). I was aware of that limitation when I wrote this code but the cost of just figuring out how to get a signal off of the scroll bar is too high to bother as it is. It may appear lazy, but I settled for the model's signal, which won't trigger until after user input is completed. Hence is works by releasing the scroll bar, just using the arrows, or rolling the mouse scroller.


I will eventually report the RPC status in the bottom right corner tooltip overlay. I don't intent to leave the bug there to begin with, it shouldn't prevent the DB from setting up.

This is still (imo) the FCGI lib taking a while to shutdown. Again, you can try to profile that stuff. Here is a list of all the threads that need end for the process to exit gracefully:


This list assumes you got out of the initial scan. Otherwise, it gets a lot more complicated. Just exiting the main thread should be enough to kill the process, although that alone won't guarantee a gracious shutdown. The most important thing to do during shutdown is to properly close the LMDB objects.


Sorry, busy IRL, will get to it sometimes before the Sunday.

Code just needs fixed to not nuke everything else on failure. As for the automated bitcoin.conf modification, that introduces the credential issues from before that I don't want to deal with at all.

I don't mind that the RPC may fail to setup, I mind that it takes the entire ship on its way down.

cookie error means you aren't running your node with server=1. Maybe that has something to do with the whole process? That's the only new code somehow related to this (it uses the same notification pipeline).

The error in your code snippet is the scan process failing to grab valid block data (it's failing the merkle hash check in basically every thread).


Is the promise failing to signal the future or the code leading to set the promise failing? This is surprising, that code didn't change at all from 0.95 to 0.96. Have you considered building with XCode 8?

FINISH_LOAD_BLOCKCHAIN_ACTION is triggered by CBO_BDM_Ready.


On the DB side, the signal is emitted here:

https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/BDM_Server.cpp#L1420

There is a lot of code running before it gets to this point. This is the point at which the signal is being prepared to be sent over the socket. My intuition tells me the issue is taking place after that event. A simple print statement should determine that the code always gets past this point (or just looking at the DB log, if it gets past "enabling zero conf", the scan was successful)

If the issue is happening before this, I'll lay out the details of the code behind that signal for you to observe.

Assuming it gets past this point, my first and foremost culprit would be packet mangling over the socket. The code will not choke over a bad packet, it will simply ignore it. The first thing you should do is log the packets you get from the DB.

https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/SwigClient.cpp#L987

retval is a string, you can either output it to stdout or save it to a file. Let the code run and show me the packet log for analysis.

EDIT:

Here is my packet log for comparison:


The last packet is the BDM_ready signal. This 42444d5f5265616479 stands for BDM_Ready in hexits, the last part is a 4bytes integer with its header (02).

You should build and try 0.96 in the dev branch.

It won't. Armory simply pushes the tx to its supporting node, the node propagates it to the rest of the network. There is no P2P command to dismiss a transaction from the mempool, that would be a massive DoS vector. In other words, once the tx is in the wild, you can only really hope it gets mined, if you aren't going to replace it.

Armory will not drop unconfirmed transactions from its DB until they either mine or are replaced. As the user, you can force Armory to wipe a 0 confirmation tx from your db. It won't dismiss it from mempools, as this can't be done.

Clearing up the zeroconf DB in Armory let's you pick the output for spending again, but there is no guarantee the new tx will propagate since it double spends the first one. Armory does not create RBF inputs to allow for the smooth double spending of 0-conf transactions.

The upcoming version (0.96) supports CPFP to help you "pull" transactions in. RBF support is planned for a later version.

bitcoind is not starting and the DB is crashing. You need to address both these issues. If you want to backup your wallet before dealing with this stuff, start ArmoryQt in offline mode and go through the backup process.

Then turn off auto bitcoind, start BitcoinQt manually, then try to start Armory in online mode and report here if you still have issues. Make sure to post armorylog.txt and dbLog.txt if you do.

Post armorylog.txt

Use some print statements in the client side callback thread, figure out what signal is not going through:

https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/SwigClient.cpp#L894

It should receive one case of CBO_BDM_Ready after the scan is complete. Before that, it should be all CBO_progress packets. If it gets those properly, then something is chocking in this scope:

https://github.com/goatpig/BitcoinArmory/blob/master/ArmoryQt.py#L5834

Both nested script types have been tested on the testnet. I cross compiled 0.96 for my RPi yesterday and will test the nested compressed key script on the mainnet with my own coins sometimes before I post the first testing builds.

sipa has a proposal:

https://gist.github.com/sipa/c291da162f6ef8cc770bfc7f015c6c49

It will be discussed at the s3nd meet among other topics:

https://s3nd.org/berlin2017

I can't tell whether this will be ready for 0.97, but I expect it will be by 0.98.

No, there is support for that yet.


If you use anything but P2PKH, you will have to use 0.96. After 0.97 will come out, the signer shouldn't change for the foreseeable future


The main change is that the former coin selection code had to run on a flat fee. The new code is built to operate on just a fee/byte hint, so it outperforms the original code just by design alone (had to add a lot of code to predict tx size). It performs better with flat fee inputs as well since it evaluates its fee/byte effect.

The coin-age mechanic does not reflect tx priority anymore, its impact on the coin selection calculation has been greatly reduced. This was the primary metric that allowed the former code to consolidate utxos. The conditions for that consolidation were very restrictive too.

Since the new code can predict tx size and adjust fee/byte if necessary, the conditions for consolidations are much laxer. Basically, as long as it can maintain the best privacy score, the code will actively try to consume more utxos than it creates. Utxo consolidation is a long term improvement on privacy. You won't see a benefit from it unless you wallet is highly fragmented.

The other changes are around change output obfuscation.

The rework around fee/byte support and size prediction is more flexible than the previous code. While the previous code did try to pick outputs that obfuscated the change value, this code has an option ("Adjust Fee") that will pick outputs and adapt the fee to align the decimal point between spend value and change value when using fee/byte. While this change has no effect on flat fees, it is particularly efficient with fee/byte.

Since the mirror wallets can handle 2 new P2SH types, it can also match change script type with spend script type. The previous code forced all outputs to P2PKH (the only type it could make sense of). With the new code, in auto change mode (you can modify that in the settings dialog), it will match the change script type with the spend script type. If you don't set it on auto (you can choose to force a specific change script type, say if you want all change to be SW), it will warn you when it differs from the spend script type.

Lastly, all these changes properly apply to explicit utxo sets created through coin control.

Some of the new code may inflate your fee to improve privacy. The fee inflation is currently hard coded to not increase your fee/byte by more than 10%. I may add an option in the future to modify that margin.


The format defines how the wallet is handled on disk, error checking and encryption parameters, as well as which cryptographic asset it manages and how. The derivation scheme only defines how cryptographic assets are derived from the seed. In this particular case, Armory 1.35c should be compared to BIP32/44, and the Python wallets (which are unversioned) should be compared to the C++ wallets.


Don't want to potentially split the user base by forcing a new wallet code on the community. There are people out there still using 0.93 for whatever reason. At any rate, SegWit is opt-in, so the code around it should be opt-in too. This doesn't apply to coin selection though, that stuff needed reworked around fee/byte.