Quote
Armory was saying the minrelaytxfee was supposed to be 200 sat/b
That has nothing to do with the fee estimate code, it is a hardcoded value that serves as a user warning.
Topic: Armory 0.96.4 release (Read 728 times)
That has nothing to do with the fee estimate code, it is a hardcoded value that serves as a user warning.
This is a local thing, your own node is rejecting the tx. Fee logic is quite complicated actually, the age the utxo and the spent value in relation to the tx size as well as a min flat fee per tx all come into play. Lowering the minimum broadcast requirements below default for your node will allow you to push that tx to your node's mempool, but chances are it won't broadcast at all to the network.
These are the 2 settings you can mess with for Core:
These are the 2 settings you can mess with for Core:
Code:
minrelaytxfee
limitfreerelay
ok, here's a great example of the poor fee estimator from the node. as i showed you from the screenshot above, the error window from Armory was saying the minrelaytxfee was supposed to be 200 sat/b. to get around with having to fiddle with changing my bitcoind minrelaytxfee or limitfreerelay i decided to tack another low fee of 1.3 sat/b instead and broadcast the raw hex thru a block explorer. sure enough, i got a confirm in <10m.
This is a local thing, your own node is rejecting the tx. Fee logic is quite complicated actually, the age the utxo and the spent value in relation to the tx size as well as a min flat fee per tx all come into play. Lowering the minimum broadcast requirements below default for your node will allow you to push that tx to your node's mempool, but chances are it won't broadcast at all to the network.
These are the 2 settings you can mess with for Core:
These are the 2 settings you can mess with for Core:
Code:
minrelaytxfee
limitfreerelay
Ah, that's the confusion. RBF means re-spending an output that is the in mempool. This error means you have not met the minimum relay fee of the node your Armory instance is connected to. Therefor the tx you created never made into the node's mempool, hence there is nothing to RBF. You have to recreate the tx from scratch with a better fee.
Yeah, thanks. But why have I never had this problem before? And which bitcoind are we talking about, mine or one of the 8 connected peers? if it's mine, maybe i could set the minfee lower to allow the tx to spread across the network? In the past, I could submit low fee tx's like this and at least they'd get into the mempool but maybe not confirm for hours or days. Has there been some sort of default minfee coded into the more recent versions of Core?
edit: this seems to suggest this is the reason i'm having trouble submitting low fee tx's. and it seems to suggest that the holdup is occurring locally from my instance of bitcoind. is there a way to lower the minfee within bitcoind to allow broadcast for these low fee tx's? the reason i find these restrictions somewhat distressing is that i've found ALL fee estimators to be lacking due to mempool volatility. in the past, i've gotten similar low fee tx's to confirm within a couple of blocks despite estimators predicting way more number of blocks to confirmation:
>== Added ==
- Updated fee estimate query from node to improve estimateSmartFee call introduced in Bitcoin Core 0.15.
- The block confirmation target slider now spans from 2 to 100 blocks (previously 2 to 6).
- You can now pick between 2 fee estimation profiles: conservative and economical. Refer to the estimateRawFee section of
the Core 0.15 changelog for more information. A tooltip has been added to the GUI with a quick description.
- If your node does not support the estimateSmartFee method, the code will fallback to the previous estimateFee method.
Ah, that's the confusion. RBF means re-spending an output that is the in mempool. This error means you have not met the minimum relay fee of the node your Armory instance is connected to. Therefor the tx you created never made into the node's mempool, hence there is nothing to RBF. You have to recreate the tx from scratch with a better fee.
Check the RBF coin control dialog, the output should be in there.
nothing is in there
edit: here's the error window. clearly i submitted with too low a fee. but i see no way to access the enabled RBF function to resubmit: https://imgur.com/a/vFJLUB2
Check the RBF coin control dialog, the output should be in there.
i don't see a turquoise tx in main GUI.
Implies problems. RBF tx's are always colored that way in the Transaction window.
RBF should be default checkbox-ed on the Send Transaction form. In your case maybe not?
Are you using 96.4, or something earlier? (there were bugs in RBF before 96.4)
96.4 linux and it was checked. i left it checked.
probably has to do with error as i mentioned above. it something to the effect that whatever node i'm connected to rejected the tx b/c the fee was too low. at that point there was no other choice than for me to manually construct a brand new tx with a higher fee to try and get it to go thru. but then the fee i chose was still too low and the same thing happened two more times. which is why i asked above how to use RBF to try and make it simpler; but it isn't possible given the lack of the turquoise tx in the GUI.
i don't see a turquoise tx in main GUI.
Implies problems. RBF tx's are always colored that way in the Transaction window.
RBF should be default checkbox-ed on the Send Transaction form. In your case maybe not?
Are you using 96.4, or something earlier? (there were bugs in RBF before 96.4)
Right click the "turquoise" tx in the in main ledger and pick "Bump Fee". You can also see RBF eligible UTXOs in the RBF control dialog that you can access from the Send GUI (the button is right under Coin Control).
couple questions:
i don't see a turquoise tx in main GUI. is this b/c the error window i got when trying to broadcast this offline tx said something about "the node will not relay b/c the fee is below the minimum relay fee"? is that error referring to my full node (one that i can adjust to allow relay) or an outside node that rejects my broadcast and terminates it?
when i open the RBF window, it just says "none". when i click "Accept" the window just disappears with no apparent action. i've sent RBF enabled tx's before but have never had to use it and the tx's cleared just fine. what's going on? i thought all UTXO's were RBF eligible?
Right click the "turquoise" tx in the in main ledger and pick "Bump Fee". You can also see RBF eligible UTXOs in the RBF control dialog that you can access from the Send GUI (the button is right under Coin Control).
What's the proper procedure to actually use the RBF feature to resubmit a failed minfee relay tx with a higher fee?
Copy/Paste your log file using pastebin.com... then post the unique URL that it creates when you save it. That might make it easier to see if anything else is causing the issue.
Looks like you're having a database issue. What were you on before upgrading to 0.96.4?
I was on 0.96.3
At first install attempt of 0.96.4 it couldn't write ArmoryDb.exe (as I recall, or something similar) as if it was still running in the background (I didn't check). Second install attempt didn't complain
hi there,
just updated my BTC and wallet to newest version , core works fine but wallet only goes in offline mode , cant see my balance . since im not a pro with bitcoin software , does anyone has any tips ? i have the armory wallet on expert user ....
thanks in advance
just updated my BTC and wallet to newest version , core works fine but wallet only goes in offline mode , cant see my balance . since im not a pro with bitcoin software , does anyone has any tips ? i have the armory wallet on expert user ....
thanks in advance
Looks like you're having a database issue. What were you on before upgrading to 0.96.4?
Hi,
Upgraded to 0.96.4 on win64
Nothing happens when I click "Send Bitcoins", except the following in my armorylog.txt:
2018-07-22 19:36:18 (ERROR) -- Traceback (most recent call last):
File "ArmoryQt.py", line 3452, in clickSendBitcoins
File "qtdialogs.pyc", line 4593, in __init__
File "ui\TxFrames.pyc", line 150, in __init__
File "ui\WalletFrames.pyc", line 232, in __init__
File "ui\WalletFrames.pyc", line 347, in updateOnWalletChange
File "ui\TxFrames.pyc", line 346, in setWallet
File "ui\TxFrames.pyc", line 395, in setupCoinSelectionInstance
File "CppBlockUtils.pyc", line 4140, in getCoinSelectionInstance
DbErrorMsg: >
(and I don't know how to attach the whole log file here...)
Upgraded to 0.96.4 on win64
Nothing happens when I click "Send Bitcoins", except the following in my armorylog.txt:
2018-07-22 19:36:18 (ERROR) -- Traceback (most recent call last):
File "ArmoryQt.py", line 3452, in clickSendBitcoins
File "qtdialogs.pyc", line 4593, in __init__
File "ui\TxFrames.pyc", line 150, in __init__
File "ui\WalletFrames.pyc", line 232, in __init__
File "ui\WalletFrames.pyc", line 347, in updateOnWalletChange
File "ui\TxFrames.pyc", line 346, in setWallet
File "ui\TxFrames.pyc", line 395, in setupCoinSelectionInstance
File "CppBlockUtils.pyc", line 4140, in getCoinSelectionInstance
DbErrorMsg:
(and I don't know how to attach the whole log file here...)
You mean have args to provide the rpclog/pass in the armory.conf? Reading another .conf than the one your node is started with would not help and introduce a lot of confusion.
Usually I provide the credentials in /home/user/.bitcoin/bitcoin.conf which only contains two lines: rpcuser and rpcpassword. Then a have a global bitcoin.conf in /etc with all the options I need. To enable armory to read my credentials I copied bitcoin.conf (with only rpcuser/password) to satoshi-datadir.I'll just add args to feed the log/pass from armory's own config files
You mean have args to provide the rpclog/pass in the armory.conf? Reading another .conf than the one your node is started with would not help and introduce a lot of confusion.
Usually I provide the credentials in /home/user/.bitcoin/bitcoin.conf which only contains two lines: rpcuser and rpcpassword. Then a have a global bitcoin.conf in /etc with all the options I need. To enable armory to read my credentials I copied bitcoin.conf (with only rpcuser/password) to satoshi-datadir. All right, I was expecting armory to read bitcoin.conf from my home directory but it reads it only from the Bitcoin Home Dir. Now I have everything working great.
Thanks for your help!
Thanks for your help!
You mean have args to provide the rpclog/pass in the armory.conf? Reading another .conf than the one your node is started with would not help and introduce a lot of confusion.
All right, I was expecting armory to read bitcoin.conf from my home directory but it reads it only from the Bitcoin Home Dir. Now I have everything working great.
Thanks for your help!
Thanks for your help!
RPC is configured with rpcuser and rpcpassword and working (at least with bitcoin-cli and lightningd). I see that ArmoryDB is running with "--cookie" but I can't use this as bitcoind is running with its own user with very limited permissions and the cookie file can't be read by other users.
Where can I tell armory the right rpcuser and rpcpassword?
Where can I tell armory the right rpcuser and rpcpassword?
You can't do that, it tries to read it from your bitcoin.conf on its own. You'd have to hardcode your log/pass in code and build it yourself.
RPC is configured with rpcuser and rpcpassword and working (at least with bitcoin-cli and lightningd). I see that ArmoryDB is running with "--cookie" but I can't use this as bitcoind is running with its own user with very limited permissions and the cookie file can't be read by other users.
Where can I tell armory the right rpcuser and rpcpassword?
Where can I tell armory the right rpcuser and rpcpassword?
You have to setup the RPC. Also, post armorylog.txt.
I have a couple of issues:
- Fee estimation is not working, the slider is grayed out and I have to set the fee manually.
- When trying to bump the fee of a RBF transaction, an empty small window pops up.
I am running my own bitcoind (0.16.1), armory succesfully syncs and "Connected (X blocks)" is displayed in purple.
Seeing the changelog I am thinking that I have something wrong in my configuration but no clue what can it be.
- Fee estimation is not working, the slider is grayed out and I have to set the fee manually.
- When trying to bump the fee of a RBF transaction, an empty small window pops up.
I am running my own bitcoind (0.16.1), armory succesfully syncs and "Connected (X blocks)" is displayed in purple.
Seeing the changelog I am thinking that I have something wrong in my configuration but no clue what can it be.
Win64 version still defaults to incorrect install directory...
So having >= 0.96.4 as your offline signing software is necessary if you're using Segwit addresses.
Thnx, it clarifies things. I'm still not using Segwit addresses, but there's no harm in planning ahead, right? Hope all goes well if 0.96.4 will be installed a top of 0.96.3 i.e. without uninstall of previous version.
If you don't intend to use segwit addresses any time soon, then it's probably not worth changing. It sounds as if the transaction signing functionality in Armory will be getting additional capabilities in the next version too (as there will be a new wallet format).
So having >= 0.96.4 as your offline signing software is necessary if you're using Segwit addresses.
Thnx, it clarifies things. I'm still not using Segwit addresses, but there's no harm in planning ahead, right? Hope all goes well if 0.96.4 will be installed a top of 0.96.3 i.e. without uninstall of previous version.
Hi, goatpig, I have upgraded my watch-only wallet to the latest 0.96.4 release. But should I upgrade my cold one (v. 0.96.3) to be on the safe side (or I can leave it as it is)?
leave it
I think 0.96.4 is needed to fix a tx signing bug when spending segwit outputs:
changelog:
Quote
[snip]
== Fixed ==
- Fixed creating offline transactions that mix P2SH and P2PKH UTXOs.
- Fixed importing wallets progress report and scan resolution in the GUI.
- Fixed SegWit sighash data serialization with scripts of length > 256 bytes.
[snip]
== Fixed ==
- Fixed creating offline transactions that mix P2SH and P2PKH UTXOs.
- Fixed importing wallets progress report and scan resolution in the GUI.
- Fixed SegWit sighash data serialization with scripts of length > 256 bytes.
[snip]
So having >= 0.96.4 as your offline signing software is necessary if you're using Segwit addresses.
I suspect that has more to do with Qt 4 than anything else. Qt 4 is unsupported at this point and is basically held together with gum as operating systems upgrade. Fingers crossed that this will be the year when Armory jumps from Python 2 and Qt4 to Python 3 and Qt 5. (The two are basically interconnected for Armory's purposes.) Work is ongoing but there aren't enough people helping out, unfortunately.
Hi, goatpig, I have upgraded my watch-only wallet to the latest 0.96.4 release. But should I upgrade my cold one (v. 0.96.3) to be on the safe side (or I can leave it as it is)?
leave it
Hi, goatpig, I have upgraded my watch-only wallet to the latest 0.96.4 release. But should I upgrade my cold one (v. 0.96.3) to be on the safe side (or I can leave it as it is)?
RBF gets much further than it used to, but I still can't RBF a transaction from a Watch-only wallet.
I get to the Sending from Wallet: / Enter Recipients: screen, and I can enter my details and click Continue, click Yes on the Insufficient Fee warning, and nothing happens - I'm back at the Wallet/Recipients screen, when I think I should be looking at the Review Offline Transaction screen to save it to my USB flash drive...
If I enter a huge fee to skip the Insufficient Fee warning, the Continue button just doesn't do anything - I can click it all day long.
I get to the Sending from Wallet: / Enter Recipients: screen, and I can enter my details and click Continue, click Yes on the Insufficient Fee warning, and nothing happens - I'm back at the Wallet/Recipients screen, when I think I should be looking at the Review Offline Transaction screen to save it to my USB flash drive...
If I enter a huge fee to skip the Insufficient Fee warning, the Continue button just doesn't do anything - I can click it all day long.
Need to see your armorylog.txt
RBF gets much further than it used to, but I still can't RBF a transaction from a Watch-only wallet.
I get to the Sending from Wallet: / Enter Recipients: screen, and I can enter my details and click Continue, click Yes on the Insufficient Fee warning, and nothing happens - I'm back at the Wallet/Recipients screen, when I think I should be looking at the Review Offline Transaction screen to save it to my USB flash drive...
If I enter a huge fee to skip the Insufficient Fee warning, the Continue button just doesn't do anything - I can click it all day long.
I get to the Sending from Wallet: / Enter Recipients: screen, and I can enter my details and click Continue, click Yes on the Insufficient Fee warning, and nothing happens - I'm back at the Wallet/Recipients screen, when I think I should be looking at the Review Offline Transaction screen to save it to my USB flash drive...
If I enter a huge fee to skip the Insufficient Fee warning, the Continue button just doesn't do anything - I can click it all day long.
Hi, I am intended to buy Lefger Nano S. Is Armory backward compatible with that wallet? In other words, will Armory's private+public keys be equal to those of Ledger if I put into Armory the seed from Lefger Nano S?
No
Hi, I am intended to buy Lefger Nano S. Is Armory backward compatible with that wallet? In other words, will Armory's private+public keys be equal to those of Ledger if I put into Armory the seed from Lefger Nano S?
Any news on 0.97? (features, not ETA 
)
)Bunch of stuff going on in the dev branch.
A lot of these changes are a result of a partnership I hold with an upcoming exchange. The most significant parts are:
1) Optimizing the DB to operate a c10k capable supernode (basically a chain explorer service).
2) In that same vain, swapping the server interface from FCGI to websockets.
3) Since I don't like the CA model SSL hinges upon, I'm having droark implement BIP151 for the client/server encryption layer. This is done in consultation with Core, and we're hoping the code will be accepted into Core when they're ready to work on this layer.
From the user perspective, these changes mostly result in better stability. BIP151 and websockets will improve privacy and quality of life for the few users who use remote DBs. For the stuff that's more immediately relevant to individual users there's:
1) new wallet format
2) BIP32 support
3) bech32 support
For .1-2, I also intent to swap out cryptopp in full for Jonas Schnelli's libbtc, which operates as a wrapper around the Core crypto libraries in Armory's use case.
There will be some work needed to accomodate the new wallet features in the GUI. I'd also like to use this opportunity to introduce an advanced filter feature for ledgers (some sort of pseudo regex), so that people can customize their ledgers without me having to hardcode a filter GUI for each scenario.
I would also like to leverage the new wallet code and its flexibility with meta data to introduce a new privacy feature, in which you can create and manage a list of vendors and voluntarily flag your payments to that vendor, to improve coin selection privacy.
As an example, assume you use BitPay vendors. You would add BitPay as a vendor to your wallet, and flag the addresses of theirs that you use while construction payment tx. This would allow the coin selection to prioritize change addresses you used with BitPay in the past, and warn you when you have to introduce an unrelated UTXO to meet your payment. I've noticed through my own usage that I often end up moving coins to the same handful of services, and the code is lacking the meta data that would otherwise minimize my coins exposure to these services.
There are other big items on the list, like hardware wallet support, blocks over p2p, common export formats like BIP39, py3/qt5, but these will most likely be for 0.98.
I also have a couple contacts at Lightning Labs and am looking to interface Armory with their daemon so that people can at least create, close and revoke LN channels in the future, with the understanding that most of the heavy lifting will be offloaded to their code. This would be either 0.98 or 0.99, and obviously optional.
Very happy with how well 0.96.4 is working, can't fault it after testing it out for a few days.
Any news on 0.97? (features, not ETA)
Any news on 0.97? (features, not ETA
) 
quick question. if i want to build from source in Ubuntu, which one of these do i download:
Source code (tar.gz)
armory_0.96.4_src.tar
Source code (zip)
Downlaod armory_0.96.4_src.tar. The other ones are automatically generated by Github and do not have all of the necessary components. Source code (tar.gz)
armory_0.96.4_src.tar
Source code (zip)
quick question. if i want to build from source in Ubuntu, which one of these do i download:
Source code (tar.gz)
armory_0.96.4_src.tar
Source code (zip)
Source code (tar.gz)
armory_0.96.4_src.tar
Source code (zip)
Use the gcc4.7 one then.
Cannot install. There's a new libstdc++ >=7 dependancy and my system still uses version 6.
Nice 
Got 0.96.4 working well over here, massive thanks to droark and the mighty goatpig.
Got 0.96.4 working well over here, massive thanks to droark and the mighty goatpig.
links:
https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.4
https://btcarmory.com/0.96.4-release/
changelog:
https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.4
https://btcarmory.com/0.96.4-release/
changelog:
Quote
== Added ==
- Updated fee estimate query from node to improve estimateSmartFee call introduced in Bitcoin Core 0.15.
- The block confirmation target slider now spans from 2 to 100 blocks (previously 2 to 6).
- You can now pick between 2 fee estimation profiles: conservative and economical. Refer to the estimateRawFee section of
the Core 0.15 changelog for more information. A tooltip has been added to the GUI with a quick description.
- If your node does not support the estimateSmartFee method, the code will fallback to the previous estimateFee method.
- SegWit lockbox creation.
- BCH lockbox spending.
- Coin selection will now limit itself to change outputs when spending to external addresses you've spent to in the past.
- You will receive a warning about privacy loss if coin selection fails to satisfy the previous condition.
- Added the following CLI args:
- Client side:
--force-enable-segwit: when paired with --offline, allows the creation of SegWit types recipient addresses.
--force-fcgi: forces the client to use FCGI socketing when connecting to a remote DB IP.
- Server side:
--listen-all: FCGI server will listen on :80 instead of 127.0.0.1:80
== Fixed ==
- Fixed creating offline transactions that mix P2SH and P2PKH UTXOs.
- Fixed importing wallets progress report and scan resolution in the GUI.
- Fixed SegWit sighash data serialization with scripts of length > 256 bytes.
- Fixed multiple RBF transaction bumping issues.
- Fixed ledger based fee bumping.
- Fixed RBF control dialog spawning.
- Fixed node sync progress bar.
- Fixed node status notification flicker during node sync.
- Fixed fragment ID generation mismatching the fragment on backup when restoring non deterministic fragments. This fix only
applies to fragments generated with versions 0.96.4 and later.
- When in offline mode, the default signer option will now pick the proper signer for SegWit transactions.
- Fixed --ram-usage control. --ram-usage=1 will no longer hang the DB during bootstrap scans.
- As a result, --ram-usage defaults to 50 no instead of 4.
- Fixed fee calculation when checking "MAX" with SegWit UTXOs
- The Coin control dialog will no longer spawn invisible
- When creating a fragmented backup, fragments will no longer be cycled unecessarily
- Fixed imported address rendering in the Address Book dialog
- The Transaction Info dialog will now display address comments in the comment field if there is no comment
attached to the transaction itself
- The Transaction Info dialog will now properly display fee/byte fee for unconfirmed transactions
- The main transaction ledger will now display comments attached to outgoing addresses for each relevant transaction
- Fixed selecting an arbitrary wallet file in the Recovery Tool dialog.
== Removed ==
- You cannot sign messages with P2SH addresses. This functionality never existed in Armory to begin with, as it
did not produce single sig P2SH addresses prior to 0.96. It will be introduced in 0.97
== Minor ==
- You can now resize the Transaction Info dialog.
- Updated fee estimate query from node to improve estimateSmartFee call introduced in Bitcoin Core 0.15.
- The block confirmation target slider now spans from 2 to 100 blocks (previously 2 to 6).
- You can now pick between 2 fee estimation profiles: conservative and economical. Refer to the estimateRawFee section of
the Core 0.15 changelog for more information. A tooltip has been added to the GUI with a quick description.
- If your node does not support the estimateSmartFee method, the code will fallback to the previous estimateFee method.
- SegWit lockbox creation.
- BCH lockbox spending.
- Coin selection will now limit itself to change outputs when spending to external addresses you've spent to in the past.
- You will receive a warning about privacy loss if coin selection fails to satisfy the previous condition.
- Added the following CLI args:
- Client side:
--force-enable-segwit: when paired with --offline, allows the creation of SegWit types recipient addresses.
--force-fcgi: forces the client to use FCGI socketing when connecting to a remote DB IP.
- Server side:
--listen-all: FCGI server will listen on :80 instead of 127.0.0.1:80
== Fixed ==
- Fixed creating offline transactions that mix P2SH and P2PKH UTXOs.
- Fixed importing wallets progress report and scan resolution in the GUI.
- Fixed SegWit sighash data serialization with scripts of length > 256 bytes.
- Fixed multiple RBF transaction bumping issues.
- Fixed ledger based fee bumping.
- Fixed RBF control dialog spawning.
- Fixed node sync progress bar.
- Fixed node status notification flicker during node sync.
- Fixed fragment ID generation mismatching the fragment on backup when restoring non deterministic fragments. This fix only
applies to fragments generated with versions 0.96.4 and later.
- When in offline mode, the default signer option will now pick the proper signer for SegWit transactions.
- Fixed --ram-usage control. --ram-usage=1 will no longer hang the DB during bootstrap scans.
- As a result, --ram-usage defaults to 50 no instead of 4.
- Fixed fee calculation when checking "MAX" with SegWit UTXOs
- The Coin control dialog will no longer spawn invisible
- When creating a fragmented backup, fragments will no longer be cycled unecessarily
- Fixed imported address rendering in the Address Book dialog
- The Transaction Info dialog will now display address comments in the comment field if there is no comment
attached to the transaction itself
- The Transaction Info dialog will now properly display fee/byte fee for unconfirmed transactions
- The main transaction ledger will now display comments attached to outgoing addresses for each relevant transaction
- Fixed selecting an arbitrary wallet file in the Recovery Tool dialog.
== Removed ==
- You cannot sign messages with P2SH addresses. This functionality never existed in Armory to begin with, as it
did not produce single sig P2SH addresses prior to 0.96. It will be introduced in 0.97
== Minor ==
- You can now resize the Transaction Info dialog.
Jump to: