|
This log shows the DB running fine. What issues are you experiencing?
|
|
|
|
Another point release with some bug fixes and the ability to spend to bech32 addresses. Most likely the last update before 0.97, sometimes for Q2 2019. Changelog== Added ==
- You can now set the database path from the Settings menu.
- You can now spend to bech32 addresses.
- Added support for satoshi-port CLI argument in ArmoryDB.
- Break backwards compatibility for unsigned transactions carrying bech32 outputs.
Older versions cannot make sense of bech32 addresses, therefor they shouldn't
be able to sign the tx at all.
== Fixes ==
- Improved bitcoind path detection.
- Properly carry thread-count and ram-usage command line arguments from client to automated db process.
- Custom paths set in the GUI will now properly overrule custom paths from armoryqt.conf.
- Fixed spending from lockboxes.
- Fixed deleting lockboxes.
- Fixed Simulfund promisory note creation and signing.
- Fixed preview dialog for unconfirmed transactions.
- Fixed previewing unsigned transactions in offline mode.
- Properly detect output script type when filtering UTXOs.
- Use relevant config files with testnet/regtest modes.
- Properly display bech32 address strings in transaction system tray notification.
- Fix signing transactions with OP_RETURN outputs.
- Fix passing satoshi-port argument through ArmoryQt to auto-managed ArmoryDB.
- Fixed SecurePrint decryption on Windows.
- Recent updates to the MSVC compiler resulted in invalid decryption of AES-CBC packets. This issue only
affects the decryption of SecurePrint encrypted backups. Encryption still operates as expected, no
SecurePrint backups created with the incriminated builds are faulty. Wallets are not concerned, as they
use AES-CFB.
The solution was to turn off all optimizations in MSVC when buidling CryptoPP. This may impact DB boostrapping
performance.
This issue affects all Windows builds of 0.96.4.
== Misc ==
- Use blockstream.info instead of blockchain.info as the external block explorer link.
Binarieshttps://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.5Happy holidays! |
|
|
|
|
It's easiest to use a wallet that looks like your dad/uncle/grand mother would be able to use rather than expect they will figure their way out of an Armory install. You could consider phone wallets too, as long as you can generate paper backup out of them.
|
|
|
|
|
Is ArmoryDB running? Can you post dbLog.txt?
|
|
|
|
|
Is there a file named .cookie_ in your Armory datadir (where the wallets and .conf are)? If so, delete it.
|
|
|
|
1) Make sure you are using the right version of Armory. armoryd as found in the repo ( https://github.com/goatpig/armoryd) is meant to be paired with Armory as found in the master branch of the BitcoinArmory repo ( https://github.com/goatpig/BitcoinArmory) 2) Start your Bitcoin node. 3) Start ArmoryDB. This is the blockchain processing service that interfaces between the Bitcoin network (your node) and clients (ArmoryQt/armoryd). ArmoryQt automates the node and db for you, but armoryd does not, as it expects you are savvy enough to manage the software stack yourself. 4) At this point you should be able to run armoryd (python armoryd.py) |
|
|
|
|
1) Pick the wallet software you expect the gift recipients are most likely to use (assess user experience vs security).
2) Make sure the software can natively create paper backups. The kind that comes with the instructions to restore funds from the backup written all over it.
3) Create a wallet with that software, send coins to, back it up to paper and gift that.
Alternatively there are services out there that sell some variations of physical wallets (posters/cards/bank notes look-alike with a private key hidden on it). Some of these come unfunded so that you can put whatever amount you want in them.
These are more "gift like" but don't come with the same security as creating the wallet backup yourself, nor do they have dedicated instructions on how to claim the coins with the software of your choice.
|
|
|
|
|
armoryd is a separate repo, I'll look into that after this release.
|
|
|
|
|
There are some minor pieces of code in place to try and improve privacy, and I have more ideas for that, but the crux of the argument is the full node vs remote service model.
A typical wallet is just a GUI with no blockchain processing capacity. That task is serviced by a remote server operated (99% of the time) by the wallet provider. This creates a situation where a 3rd party (whoever is running that server) knows of all your transaction history past, present and future, for all operations you perform with that wallet software.
Armory does not provide such remote service. Instead, the software package comes with a local service for all things blockchain, and requires that you operate your own Bitcoin node, which is its interface with the Bitcoin network.
Therefor all your Bitcoin operations are contained within your own hardware and software stack, and Armory has no phone home/eavesdropping code, therefor there is no way, short of an adversary infiltrating your system, for anyone (devs included) to know what you're doing with your coins but you.
There's also the non negligible advantage that you get to choose which Bitcoin node code you want to run, which itself has some minor privacy implications.
|
|
|
|
Fixed all the stuff reported for RC1, this should be the final RC for this version. Changes - Break backwards compatibility for unsigned transactions carrying bech32 outputs.
Older versions cannot make sense of bech32 addresses, therefor they shouldn't
be able to sign the tx at all.
- Properly detect output script type when filtering UTXOs.
- Use relevant config files with testnet/regtest modes.
- Properly display bech32 address strings in transaction system tray notification.
- Fix signing transactions with OP_RETURN outputs.
- Fix passing satoshi-port argument through ArmoryQt to auto-managed ArmoryDB.
- Use blockstream.info instead of blockchain.info as the external block explorer link.
|
|
|
|
|
You'd have to make sure your setup is fine to begin with. For what it's worth, I haven't seen anything in 0.17.0.1 that disrupts Armory's connection. You're better off updating regardless.
|
|
|
|
One extra step I needed to take was update libstdc++6 (I installed gcc++-8, I'm guessing I could've gotten away with just the lib)
That's surprising, I built the .deb on Ubuntu 16.04. My gcc says 7.2.0 |
|
|
|
|
Looks like I botched the source file. You'd have to setup through git if you want to build this version.
|
|
|
|
|
Is /cppForSwig/fcgi empty?
|
|
|
|
|
After testing this, it turns out signing a tx with a bech32 recipient using 0.96.4 will result in 0.96.4 extracting the pubkey from the script and paying to it using a standard p2pkh script. Obvioulsy cannot have that. I'll have to add versioning to the unsigned tx packet to stop previous versions from doing anything with these specific transactions.
|
|
|
|
not sure, didn't actually check (never used armoryd). Preview in online 96.4.99 shows a P2PKH address in place of bech32 address and script type as PKH, but only if signed using 96.4.0. If bech32 is signed using 96.4.99, address and it's script type is bech32 as expected. Well, it actually says P2SH segwit for the script type, but I assumed that's just cosmetic.
I haven't tried signing with an older version, I'll look into it. |
|
|
|
Signing to bech32 addresses with 0.96.4.0 succeeds, but the transaction it signs substitutes P2PKH for the intended bech32. Presumably this can't be worked around, as you can't force 0.96.4 to understand it's doing something wrong. I'm assuming the result won't be what the user wanted.
Are you saying the output script is P2PKH instead of P2WPKH? |
|
|
|
|
I'm looking at your PR and it makes me wonder how was the port ever passed before? I need to investigate this before doing anything with the PR. I'll let you know on the github page.
|
|
|
|
I was going to submit a PR about the port thing and this involved building against the dev branch. This doesn't seem to be possible using Ubuntu 18.04 apt-get to get dependencies. In addition to the packages in the linux build instructions, I used the following. sudo apt-get install libprotobuf-dev protobuf-compiler python-websocket libwebsockets-dev libevent-dev
However, the libwebsockets-dev package in 18.04 (and 18.10) is not sufficiently advanced. I get an error that "lws_fop_fd_t" due to not in the include file. This typedef doesn't appear in the libwebsockets.h include file until version 2.2.0. In Ubuntu-18.04, apt-get uses version 2.0.3-3build1. Even in Ubuntu-18.10, apt-get still uses version 2.0.3-3build1. I realize that this is the dev branch and things aren't stable yet, but I thought I would flag this. Being able to build from source is an important feature for Armory. If websockets 2.2 functionality is required, would it be directly included in the repo, like some of the other dependencies? Dev is 0.97, if you gonna PR you should do it against the testing branch, with 0.96.5. If you want to build dev, you need to clone the libwebsockets repo, checkout v3.0.0 or higher, build it, then give that path to the configure script in this fashion: ./configure --with-own-lws=/my/path/to/lws
P.S: The client in dev cannot speak to db, I have not updated that part yet. Considering dropping swig and moving to CFFI to ease to migration to py3. |
|
|
|
This change would make pruning less efficient too.
And possibly reorg speed? The revXXXXX.dat files hold the snapshot for the utxo changeset per block. Is it in sync with block alignment in blk files? |
|
|
|
|
Show Posts
