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.
