5
estimatesmartfee requires that bitcoind have been running long enough to gather data about the current fee rates on the network. This can take some time. Try running it again after a few hours, or a day or so, once it has collected data.
4
-1 means "not enough information for an accurate estimation".
Try with a higher confirmation target.
3
The two modes don't just unconditionally return the same thing. They do different calculations and can return different results under certain conditions, particularly when fees are very variable for low confirmation targets. The current fee situation just makes it so that the estimator ends up using the same values for both modes.
3
The maximum size for HTLC's are currently defined by max_htlc_value_in_flight_msat and is roughly 42mBTC. The max_concurrent_htlc that you mention seems to be the max_accepted_htlcs and states how many HTLCs can be within a commitment transaction at the same time. This has nothing to do with the maximum payment size (not transaction size) of a single path. ...
3
Short answer: No.
Explanation: The fees are part of the onion routing package within the HTLCs. So a routing node accepts an incoming HTLCs and forwards it if there is a difference in value that can be collected as fees. The HTLCs are conditional payments on the condition that the preimage is delivered in return. This will only happen after a path of HTLCs ...
3
The advantage of using vsize is that it is a smooth transition from size; every non-witness transaction has vsize equal to size.
All code and infrastructure that used satoshi/byte before, will keep working when substituting size with vsize, and give consistent results. Switching to weight would be confusing - would we be talking about satoshi/weightbyte?
2
With recent versions of bitcoind, you can use sendtoaddress with the optional subtractfeefromamount argument.
sendtoaddress 123abc... 1.055 "" "" true
Creates a transaction with 1.055 BTC of inputs. The destination address will receive a little less than 1.055 BTC, after an appropriate fee is subtracted.
2
If your transaction is from Bitcoin Core's wallet, you can use the bumpfee command. It should do the same thing that the GUI does in order to create a replacement transaction with a higher fee.
2
Fee estimation is mostly progress free, in the same way as waiting for Bitcoin blocks, that is the estimate for how long it will take to get confirmed from now is unrelated to how long you have been waiting. I say mostly, because there are clearly daily and weekly cycles in transaction activity that result in the fact that overnight or over the weekend ...
2
The fee estimation is completely based on how long your node has been running, how many transactions have entered the mempool, and how many of those transactions have been confirmed. It is not (and cannot be) based on the fee information of transactions already included in blocks. So it does not matter whether you are fully synced or not. If you just started ...
2
The minRelayTxFee (which despite the name is a feerate) on BCH is 1000 satoshis per kilobyte or 1 satoshi per byte.
BCH has a blocksize limit of 32 MB and has generally had only a very small portion of the blockspace used. The current 7-day average is 27 kB blocksize. It rarely even peaks to 400 kB.
via fork.lol
Given that BCH is currently using about 0....
2
The node that has been synchronized for only 5 hours and is less well connected seems to be estimating the fee better than the one that has been synchronized for three weeks. Why is the "best" node the one that gives the worst fee?
Just because the fee is lower does not mean it is better.
The fee estimator tries to estimate the fee the balances between ...
2
Adding to Murch's response and comments, Coinomi does have UTXO control where you can set individual UTXOs as "do not spend" and indirectly control which ones will be used on your transaction. Number and type of inputs in a transaction is one parameters that influence the transaction size (and thus the fees) the most.
Unless you change a privacy option in ...
2
Given that you are looking at two different wallets on two different pieces of software, the transactions that the wallets are proposing are different:
they may be using a different count of inputs
one may be using segwit inputs while the other uses non-segwit
one might be a multisig wallet while the other is single-sig
one of them might be able to avoid a ...
1
You need to take a look at how fee_estimates.dat is written and interpreted. Basically it's composed of:
MIN_VERSION
CURRENT_VERSION
CURRENT_TIP
TIP_AT_LAST_START
TIP_AT_LAST_STOP
[ESTIMATES]
[STATS]
With CURRENT being "when writing", i.e. when stopping bitcoind.
Here is the method writing the file, and here is the method reading this file (at startup). I ...
1
It seem like you tried to run fallbackfee in the terminal ? fallbackfee is a configuration option and should be put inside a bitcoin.conf file, if you dont have this file on your bitcoin directory you can create it: https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File
Then add your fallbackfee=someValue (without the -) inside your ...
1
I've listed some public feerate APIs by block explorers and payment processors below. Purposefully leaving out APIs from wallets, since they don't advertise their APIs. I leave out Bitcoin Core's estimatesmartfee RPC, which I don't consider public (as in reachable over the web by everyone).
The list is sorted lexicographically. Disclosure: This Q&A is ...
1
The estimatesmartfee fee estimation algorithm maintains local historical records of two things:
Transaction fees (sat/B) of confirmed transactions
Target Intervals: Blocks between mempool acceptance and confirmation
Based on these records, the algorithm will be able to provide an estimation of the minimum fees required to obtain confirmation within your ...
1
From the doc:
-1 is always returned for nblocks == 1 as it is impossible to calculate a fee that is high enough to get reliably included in the next block
https://bitcoincore.org/en/doc/0.16.0/rpc/util/estimatefee/
1
What getmempoolinfo is returning is not the minimum fee to send a transaction, but the minimum rate per kilobyte to send a transaction. Your bitcoin client will take the configured fee and multiply it by the size of the transaction in kilobytes to calculate the actual transaction fee.
The size of a transaction is somewhat difficult to compute (for a person) ...
1
It appears the node is not fully synced the entire blockchain. If your node is not fully synced, then it hasn't parsed the latest blocks to see what a reasonable tx fee would be for the current market. If it's not fully synced, then it might try to estimate based on old transactions, which you don't want, since they could be much lower (and your tx will ...
1
Fees are not based on the amount being transferred, but instead on the amount of space the transaction occupies.
For a very simple transaction with one input and two outputs, you would occupy a few hundred bytes of space.
Moreover, fees are decided by you (or the exchange/hosted wallet service you make a withdrawal from). The fee paid is simply the ...
1
Fees in Bitcoin are actually a bit simpler than ethereum, you don't have to deal with gas costs, just a fee per byte.
Bitcoin Core includes an estimatesmartfee function. You can call it (estimatesmartfee 2, for example) and it will give you an idea of the fee rate you need to be confirmed in n blocks (2 in my example).
You can then check your tx size, ...
1
In bitcoin core existed embedded tools to estimate fee cost and confirmation time in blocks.
you can read the description with help command
bitcoin-cli help estimatesmartfee
estimatesmartfee conf_target ("estimate_mode")
Estimates the approximate fee per kilobyte needed for a transaction to begin confirmation within conf_target blocks if possible and ...
1
That is one of the purposes of transaction fees.
Since block space is finite, miners will select transactions with the best Feerate or fee/kB ratio. Of course, this is variable based on volume of transactions and the market rates.
See Fee Rates | Transaction fees
1
This feature available on bitcoin-core RPC
bitcoin-cli help estimatesmartfee
estimatesmartfee conf_target ("estimate_mode")
Estimates the approximate fee per kilobyte needed for a transaction to begin
confirmation within conf_target blocks if possible and return the number of blocks
for which the estimate is valid. Uses virtual transaction size as defined
...
1
estimatesmartfee expects the number of blocks you want the tx confirmed in as the parameter, not the amount of BTC you are sending.
Try estimatesmartfee 5 to get an estimate for confirmation in the next 5 blocks, for instance.
1
You can try:
txconfirmtarget=1
If paytxfee is not set, include enough fee so transactions begin confirmation on average within n blocks (default: 6).
So putting it equal to 1 will automatically set the fee to be included in the next block.
Note that this isn't a "fixed amount solution".
Only top voted, non community-wiki answers of a minimum length are eligible
