send to address method in details

[ayza_aa]

Hi guys
I want to know details about sendtoaddress method in bitcoin core. especially the usage of arguments like:

replaceable

conf_target

estimate_mode

if estimate_mode is unset, how fee calculated?

[ranochigo]

replaceable

If the transaction is signalling opt-in Replace by Fee.

conf_target

estimate_mode

if estimate_mode is unset, how fee calculated?

Both of the arguments are for Core's fees estimation. Core collects data and builds a set for which it would provide a certain degree of confidence whether it will be confirmed within the conf_target. This is dependent on your estimate_mode, conservative results in a higher fee while economical is vice versa. Unset allows Bitcoin Core to automatically choose either of them.

[mocacinno]

The only thing i wanted to add to ranochigo's answer is:

An estimate_mode argument has been added. This argument takes one of the following strings: CONSERVATIVE, ECONOMICAL or UNSET (which defaults to CONSERVATIVE).

source: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.15.0.md

This answers your last question (if estimate_mode is unset, how fee calculated?)

I think that's the last time there were changes in this call. Whenever i use the call, i usually do add either economical or conservative estimation...

[ayza_aa]

Both of the arguments are for Core's fees estimation. Core collects data and builds a set for which it would provide a certain degree of confidence whether it will be confirmed within the conf_target. This is dependent on your estimate_mode, conservative results in a higher fee while economical is vice versa. Unset allows Bitcoin Core to automatically choose either of them.

i didn't understand this paragraph, can you explain more, please?

[mocacinno]

--snip--
i didn't understand this paragraph, can you explain more, please?

Any wallet you use has an algorithm (or multiple algorithms) for estimating the transaction fee.
These algorithms usually look at the current mempool (and sometimes the most recent blocks): how many transactions are in there, what is the type of transaction and what is it's fee (in sat/vbyte). Based on this information, the algorithm proposes a fee that, to a certain degree of certainty, has a decent chance of getting your transaction confirmed within a certain couple of (future) blocks.

It all boils down to the fact that a miner can only fit 1 Mb of transaction data (disregarding the witness data) into any block they're trying to solve. Since there is a space constraint, the miner usually picks the unconfirmed transactions from it's mempool that have the highest fee per virtual byte of data. What a wallet is doing is trying to get your transaction into the top x Mb of transactions in most mempools (your transaction doesn't HAVE to be in the top 1Mb if you indicate you're willing to wait, let's say, 30 blocks). This isn't an exact science, since the wallet has no idear how many new transactions will be broadcasted the next couple of hours, and what their fee will be... The only thing a wallet can do is make an educated guess based on the recent history and the current state of the mempool.

[ranochigo]

The only thing i wanted to add to ranochigo's answer is:

An estimate_mode argument has been added. This argument takes one of the following strings: CONSERVATIVE, ECONOMICAL or UNSET (which defaults to CONSERVATIVE).

I think there is actually certain criteria and it changes according to the kind of transactions that is being created. If I remember correctly, signalling RBF actually defaults to an economical estimation instead of conservative. I can't check this right now so perhaps someone can chime in if I'm wrong.