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.
4
No, you shouldn't need to sign the transaction until it's completely crafted. Bitcoin core can handle this for you!
An easier flow when creating a transaction is
Create raw transaction. Don't add any inputs yet.
Fund raw transaction. This will select inputs for you. Add subtractFeeFromOutputs of the output you want to subtract the final fee from. The docs ...
3
Yes, if it has a mempool (no -blocksonly).
No matter the number of blocks stored, what matters is how many blocks it has been watching (ie received at the time of generation, with transactions that were part of its mempool).
3
First, even if you find the transaction with the lowest effective fee rate in a block, that will not necessarily mean that the mempool cleared to that level. In their recent paper "On Blockchain Commit Times: An analysis of how miners choose Bitcoin transactions", Messias et al observe deviations in the block composition from the expected norm (...
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
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 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?
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
If by "flat rate" you mean that each opcode costs the same amount in transaction fees, then yes, Bitcoin does have a "flat rate". Opcodes don't have a direct fee themselves, the fee is based on the size of the transaction, and since each opcode is one byte, they have the same cost.
It is unnecessary to have an opcode cost scheme like ...
2
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.
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 ...
2
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 ...
2
All fee calculators rely on statistical modelling of the mempool. There is no assumption that future transaction producer behavior is identical to what was observed in the past, but it's the best data available to produce an estimate with.
2
Bitcoin transaction fees are usually calculated based on the size (in bytes) that the transaction takes up. This is a number known as 'fee rate', usually written as 'satoshis per byte', and the idea is that you are bidding for space within a block, where most miners will select transactions with the highest sat/byte fee to prioritize for confirmation. The ...
1
TLDR: You can find some OLD 2019 DATA comparing their accuracy for one-hour estimations here: https://bitpost.co/evaluations
I asked myself this question about two years ago and wasn't able to find an answer. I then set out to build an app that measured how accurate fee estimations from various sources were. Below are the design choices and some OUTDATED ...
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
You need to take a look at how fee_estimates.dat is written and interpreted. It is a binary file 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 (...
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
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".
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
