`effective_value` does not take segwit/legacy into account about rust-bitcoin

[tcharding]

Lets leave it as a function though, no need to bikeshed this.

[tcharding]

I used this blog post to learn about this stuff: https://bitcoin.stackexchange.com/questions/103654/calculating-fee-based-on-fee-rate-for-bitcoin-transaction#103661

[Kixunil]

Reading previous discussions should answer your questions but briefly:

does not consider weather we are adding this input to a legacy or segwit transaction

The caller is responsible for setting the correct satisfaction weight based on this

What is satisfaction_weight?

Total weight of witness + script_sig when the input is fully signed

Why is this not a method on TxIn

Because TxIn doesn't contain amount. And you will soon see a potential solution I'm about to push, just checking some things...

or on Transaction

Because Transaction has multiple inputs and outputs.

on tx it would solve the segwit thing

It wouldn't because of P2SH-P2WPKH where you're unable to tell whether it's segwit or not just from looking at the transaction alone.

The function is a minimal primitive used for coin selection. Among other things it can determine whether spending a particular output is worth it.

[apoelstra]

• How can it be correct if it does not consider weather we are adding this input to a legacy or segwit transaction?

The satisfaction weight will take this into account.

• What is satisfaction_weight? Why the term "satisfaction" - I thought we used this term already to satisfy a script.

Yes, and satisfying a script requires a certain amount of weight. Note that rust-bitcoin doesn't have any real facilities for script satisfaction; either you use a fixed template and manually construct witnesses, or you can use rust-miniscript or similar.

• Why is this not a method on TxIn or on Transaction (on tx it would solve the segwit thing, on txin it kind of makes sense even though it doesn't use self).

Logically speaking it belongs on TxIn ... but as you say, it doesn't actually use any part of the TxIn and therefore works as a standalone method. Maybe it should be a static method?

[tcharding]

Ok, thanks for the explanations, probably took more of your time than I should have. I"ll add docs to the satisfaction_weight argument to explain all that. Are we definitely happy with the term "satisfaction"?

[Kixunil]

Logically speaking it belongs on TxIn

I'd say TxOut - it's operating on UTXOs where O means output.

Maybe it should be a static method?

Then we enter a huge flamewar whether it should be on TxOut or TxIn. :D

Are we definitely happy with the term "satisfaction"?

Do you have an alternative? I can't come up with any.

[tcharding]

We are calculating the weight of adding a TxIn type (and we use weight of OutPoint and Sequence), sure Amount comes from a UTXO but this is the same problem we always have with the nomenclature of input/output - one transactions ouput is the next ones input.

[Kixunil]

We could just implement it on ExtendedTxIn from #2347 :D

But really, if we can come up with good Extra that can represent known satisfaction weights we can have it as a method that doesn't require other arguments than self.

[yancyribbens]

@tcharding thanks for the questions and suggestions to improve this. Reading the comments on the PR #2230 may also help with some of your earlier questions. In particular:

The effective_value is used to calculate how much a particular output contributes to a target spend amount. Therefore, the effective_value returns the net amount, that is, the output amount minus the overhead to spend the output. The overhead to spend the output is the fee. In order to calculate the fee, the size of the input which consumes the output is calculated as the input base_weight plus the size of the output once the spending conditions are satisfied (the satisfaction_weight) multiplied by a fee_rate. Lastly, subtract the fee from the output value to find the effective_value.

Happy to discuss any other questions or additions.

[Kixunil]

@yancyribbens while you're here, check out the ExtendedTxIn type in #2230 It could represent a UTXO.