While the old code uses a random r, new code in the dev branch uses RFC6979 meaning the sigs will always be same (if generated from Armory for the same message and address). IDK whether other wallets us that or not. I know Core does.

Then it's a DB corruption issue. You need to rebuild & rescan the DB to fix the issue.

Need to see the full log. This error can be a false positive, if it's trying to fetch the hash for the tx you are creating.

This means you're having an issue with loading the Python interpreter, before the Armory code even gets to run. I'd suggest you update Armory first, try as is on your system and see from there. Logs may be useful, don't know yet.

If you're signing older type of addresses, you don't need to. It's still preferable to update the offline instance.

Post your logs.

It's failing to find your blockchain data. You need to post logs.

What Carlton said. You can try and give the dev branch a spin once in a while if you're adventurous. That aside, you'd have to guess from the commit description or ask me directly. I can't really give you ETAs, I don't work on Armory all day. It's hard to predict how much time I have to work on it atm.

it mostly runs in py3 atm, have to clean some stuff up and do the qt5 conversion

WIP (tm)

Not exactly. While Core only does plain read/write operations to the drive, Armory maps the files for access. This means it tells the OS to treat specific areas of the drive as part of the RAM. The OS then balances that stuff in and out of the RAM according to access patterns for significantly better performances. The caveat is that stuff like NFS won't work. Physically connected drives will however, through USB or internally.



That's not necessarely true. NVMe drives are fast because they connect directly through PCIe. USB 3 is slow not because of the transport capabilities but because it typically goes through the southbridge. I think some manufacturers connect some USB-C ports to PCIe directly but that really depends on your mobo. If you straight up buy a PCIe USB-C adapter card however, you can get blazing fast speeds with a USB-C to m.2 connector.

That's not particularly relevant for a HDD, which is limited to ~100MB/s sequential I/O cause of the physical constraints, but you can get near native speeds with an NVMe drive plugged through USB-C that way. USB-C can carry 4K@60fps video for what its worth.

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

It runs this check on port 9001 instead of your custom one. Possibly the value hasn't been reflect in ArmoryQt.py cause it's hardcoded in ArmoryUtils.py and the compiler is that dumb?

1) Check port 15000 isn't in use.

2) Check ArmoryQt is actually trying to connect to localhost:15000

3) Start ArmoryDB manually if you have to, give it the proper port.

Try to rescan the db.

Well then there's a final trick, but it's worth trying. I'm going to guess you're on Windows, which is the only OS on which changing the Python code files is tricky.

As I said it's tricky but not impossible. Python code isn't compiled per se, it's interpreted. In the windows package, Armory bundles the Python interpreter along with the binary source for each python code file. This is so that Windows users can just run one executable. This executable starts the Python interpreter, and then points it to the Python code files in a zip archive: library.zip.

If you change a code in that library, it should be reflected in your setup. The idea is therefor to change hardcoded port in ArmoryUtils.py and replace that file in the code library zip archive. This would be a text file and not a binary file, so I'm not 100% sure that trick will work, but Python typically converts text files to binary files on the fly at import time so it should work.

You would need to change the port value at this line:

https://github.com/goatpig/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L88

Then copy the modified file in the zip archive (it's in the armoryengine folder), and delete the old file (ArmoryUtils.pyc). Your file is a .py (text), the file you're getting rid of is in binary (.pyc). Python should do the conversion for you next time your run Armory.

It's not much related to the PC's performance. Armory's p2p broadcast code was implemented when Core would push transactions as is once delivered by another peer. Core batches now, so the broadcast detection throws a lot of false negatives. This needs a bit of a technical explanation to make sense:

Early days, before Core was even named Core, the Bitcoin node software did 2 things different: Setting up the JSON-RPC interface required some minor work on the user part, notably adding login and password to a config file. Therefor, Armory could not expect access to the RPC in plug and play setups (95% of users), so it had to rely on something else to broadcast transactions. The RPC returns with an ACK/nACK on broadcasts but if only 5% of users can set it up properly, it was useless to Armory.

Instead etotheipi (the original maintainer) opted to connect to Core through the P2P interface. Armory, still to this day, spoofs a P2P node to your Core instance, for the purpose of pushing transactions and getting new block notifications.

The P2P broadcast interface does not come with an explicit ACK/nACK. It doesn't provide a result at all as a matter of fact, for design reasons. The flow goes like this: advertise the hash of the transaction you want to broadcast to the peer. The peer will then request that transaction by hash. You will return the transaction body to the peer. Broadcast is over. The only way to know if that transaction made it into the peer's mempool is to query that peer for the same transaction. If it returns it to you, it's in. You won't get a reply otherwise.

So basically, Armory sends the transaction to your Core instance and polls it for a few seconds to verify it's been added to the mempool. Eventually core introduced broadcast batching, where it tries to make a better use of the MTU and reduce point of origin timing leaks. Basically your node will now wait some time and try to accumulate a bunch of transactions before announcing them to other peers. This delay also affects entry in the mempool (so that you can't just query the node for specific hashes to know what made it in or not with certainty). As a result, this disrupts the Armory P2P broadcast loop, since the polling may now timeout.

Since then, interfacing with the RPC has become easier so I've added a RPC broadcast fallback when available, which is why you received the message about the RPC.

Have you tried putting the port in quotes?

Try setting the port through armoryqt.conf (for ArmoryQt) and armorydb.conf (for ArmoryDB)

Broadcast timeout doesn't mean the tx didn't make to the mempool, it only means Armory sent the tx to your node but failed to acknowledge delivery in the allotted time (hence the timeout). When that happens, it tries to fallback to the RPC interface to broadcast through that, but since yours isn't set up, you got that message.

Did you try on the testnet? You have to run Core with -server to enable the RPC at any rate.