Repository navigation
Abstract cost function - #15
yuval-block wants to merge 1 commit into
Conversation
bc1cindy
left a comment
bc1cindy
left a comment
There was a problem hiding this comment.
it was a great to read this
some typos:
- l.3 - "describes how score the outcomes" → "how to score"
- l.21 - "one might considering all actions" → "one might consider"
- l.23 - "not account for everything, that may eventually happen," → "everything that may eventually happen"
- l.27 - "the input that will eventually spend it already known" → "is already known"
- l.37 - "at a higher feerate than of the unconfirmed" → "than the unconfirmed"
- l.47 - "the goal of create some output" → "of creating"
- l.49 - "resulting a transaction" → "resulting from a transaction"
- l.57 - "diminishes from the importance" → "diminishes the importance"
- l.59 - "a transaction which underpay fees" → "underpays"
- l.67 - "the total amount involve" → "involved"
- l.85 - "a cost function for a privacy has" → "for privacy"
- l.89 - "Metrics makes it possible" → "Metrics make"
- l.91 - "Although are other aspects" → "Although there are"
- l.95 - "the coins that an honest does not control" → "an honest user"
- l.97 - "If all actions than those of the victim" → "all actions other than"
- l.97 - "then adversary is able" → "then the adversary"
- l.103 - "targetted" → "targeted"
- l.125 - "incurs a cost can be shared" → "incurs a cost that can be shared"
- l.129 - "should at the very least indifferent" → "should at the very least be indifferent"
- l.129 - "the the actions" → "the actions"
- l.131 - "Alice… they need to add" → "she needs"
- l.133 - "we required that" → "we require that"
- l.135 - "to define honest parties' as being" → "honest parties as"
- l.135 - "the cost function … are indeed monotonically decreasing" → "is indeed"
|
|
||
| When coins lack any sufficient privacy (e.g. when known to a counterparty), their value should be discounted by the budget, effectively devaluing non-private wallet states. As progress is made towards satisfying the thresholds on privacy metrics, some coins will be closer to their face value, an increase in subjective value. This simplifies the cost function so it only outputs a satoshi amount, allowing subjective and objective costs to be reduced to a single number, and therefore comparisons can be made between the wallet states predicted to result from taking one action vs. another. | ||
|
|
||
| For example, suppose Alice set her budget to 1%. She receives a coin with value $x$. Her total budget $b_0$ is $0.01x$. The subjective balance of the wallet is $x - b_0 = 0.99x$. The wallet then automatically does a CoinJoin transaction and its subjective cost $y$ is subtracted from the budget, $b_1 = b_0 - y$. This is also deducted from the subjective balance, but due to an improvement in the privacy metrics the subjective balance increases overall (or the transaction wouldn't have been made). The coin with nominal value $x$ and subjective value $x - b_0$ has been destroyed, and replaced with a coin whose nominal value is $x - y$ and whose subjective value is at least $x - b_1$ and at most $x - y$. |
There was a problem hiding this comment.
whose subjective value is at least
$x - b_1$ and at most$x - y$
shouldn't this be
as written,
e.g. receive 100 sats with a 1 sat budget, coinjoin costs 0.6, so the bounds give [99.6, 99.4], while
There was a problem hiding this comment.
@yuval-block @bc1cindy wrote:
shouldn't this be
$x - b_0$ ? (= nominal minus remaining budget,$(x - y) - b_1$ )
At ff3728c this is not reflected and has no reply yet: is it still planned, or can it be dropped?
There was a problem hiding this comment.
no
the replaced coin increases by some subjective quantity that is implied to be greater than y, the objective cost of the replacement via a coinjoin
the destroyed coin is discounted as 0.99x or x-b_0
b_1 is the remaining budget at that point, it is exactly b_0 - y, and x - b_1 is the lower bound, the coin could not be worth less than that or the implied cost of the change is positive, which means it wastes money for no benefit (the cost function provides a negative valuation when the objective cost exceeds the subjective benefits)
x - y is the upper bound because the privacy liability can go to 0, in which case there is no more devaluation of the coin
There was a problem hiding this comment.
nevermind in my head i treated x as time dependent but that doesn't match what was written
|
|
||
| An *intent* is a concrete representation of the goal of create some output (or input, in which case the goal is the destruction of some unspent output) before some deadline. The deadline can refer to the transmission of a signed transaction to the recipient out of band, broadcasting the transaction, or its confirmation in a block. For simplicity, and without loss of generality, output creation intents will be assumed to correspond to payments but that isn't necessarily the case (for example funding a lightning channel). We will assume intents are made known to the wallet some time in advance of the deadline. | ||
|
|
||
| The change in the balance of a wallet resulting a transaction is its *objective cost*. This can be negative, for example for the case of receiving a payment. In contrast, the utility obtained from a transaction confirming may include subjective terms as well. Subjective costs inherently depend on beliefs or preferences, and are the basis for any surplus created from transactions as any redistribution of on chain funds is necessarily zero sum. |
There was a problem hiding this comment.
The change in the balance of a wallet resulting a transaction is its objective cost.
should this be the decrease in the balance? receiving a payment increases the balance, so under "cost = change" it would come out positive
This can be negative, for example for the case of receiving a payment.
this sentence correctly treats it as negative (a benefit)
There was a problem hiding this comment.
@yuval-block @bc1cindy wrote:
should this be the
decreasein the balance? receiving a payment increases the balance, so under "cost = change" it would come out positive
At ff3728c this is not reflected and has no reply yet: is it still planned, or can it be dropped?
There was a problem hiding this comment.
no, change is more general and this could model expected incoming transactions as well, when notified of an interactive payment that will create an intent to receive that payment in an interactive transaction, which must be acted upon (both parties need to join the same session and negotiate the settlement within it)
|
|
||
| ## Payment batching | ||
|
|
||
| Confirming transactions at the earliest possible time (well in advance of the deadline) is sub-optimal as it precludes any possibilities of batching payments. However, before confirmation it is possible to replace transactions by double spending at least one of its output in a transaction which is more attractive to miners (which also diminishes from the importance of introducing any CPFP liability). This is known as replace-by-fee (RBF), and multiple policies for allowing this, some defunct, have existed over the years. |
There was a problem hiding this comment.
RBF replaces an unconfirmed transaction by re-spending one or more of the original's inputs (BIP 125: the replacement "spends one or more of the same inputs"), not by spending its outputs.
The text's "double spending at least one of its output" describes spending unconfirmed outputs, which is a child transaction (CPFP), not a replacement.
There was a problem hiding this comment.
@yuval-block oakagent wrote:
RBFreplaces an unconfirmed transaction by re-spending one or more of the original's inputs (BIP 125: the replacement "spends one or more of the same inputs"), not by spending its outputs.
At ff3728c this is not reflected and has no reply yet: is it still planned, or can it be dropped?
There was a problem hiding this comment.
BIP 125 is no longer relevant
"double spending at least one of its output[s]" is a mistake, it should say "spent outputs" as in the txos used as inputs
|
Typos in what this pull request adds (automated):
|
|
for @arminsabouri to decide if this is ready to be merged |
arminsabouri
left a comment
arminsabouri
left a comment
There was a problem hiding this comment.
This document has always read more like personal notes polished and shared than, for example, the overview #51 (which I believe was produced with a specific audience in mind). There are problems being defined and concrete solutions being presented here
A simplified version of the waste metric ... is to consider some
Breaking up the problem def and the how (concrete ideas) may help the flow of ideas.
The other thing that is missed is the why! A sentence or three in the intro about why this matters. Where other protocols fall short. This really contextualizes things for a reader. Currently it tells the reader: this document is about scoring outcomes and then goes right into "Coin selection with objective costs". Even if its citing the problem def that will be useful.
| @@ -0,0 +1,137 @@ | |||
| # Cost function framework for Bitcoin wallets | |||
|
|
|||
| This document describes how score the outcomes of transacting on Bitcoin, in particular privacy outcomes. This is the basis for automating various decisions delegated by the user to the wallet. | |||
There was a problem hiding this comment.
| This document describes how score the outcomes of transacting on Bitcoin, in particular privacy outcomes. This is the basis for automating various decisions delegated by the user to the wallet. | |
| This document describes how to score the privacy preserving outcomes of transacting on Bitcoin. This is the basis for automating various decisions delegated by the user to the wallet. |
|
|
||
| ### Future cost of spending (Bitcoin Core's waste metric) | ||
|
|
||
| At the time an output is created, the size of the input that will eventually spend it already known (or an expected size in the case of P2TR outputs). This size is independent of whatever else happens in that transaction. Reliably predicting a feerate, on the other hand, is not possible, as that is a market prediction problem. |
There was a problem hiding this comment.
p2tr
Isn't it always an expected size for other script types e.g p2sh. Im not sure what this paranthesis is trying to get across.
There was a problem hiding this comment.
so p2{w,}pkh and generally anything involving ECDSA sigs will have an expected size due to variable length encoding. that is not worth dwelling on IMO we should just model its concrete cost as the worst case or perhaps as a fixed discount for wallets which always grind... so not what i'm referring to
ignoring signature variations, you're right: p2{w,}sh you're right that will still have a variable size due to OP_IF potentially requiring different witnesses or scriptSig pushes, so yes
i was mainly referring to the fact that in p2tr the tap leaf is itself not determined until spend time, which is the same as branching pre-taproot, there are options and one of the options must be taken
anyway the point of this is to brush off this complexity and say it's not our problem here, we just want to thinking about that as a fixed expected cost rather than a decision tree whose leaves have different costs, because theoretically that assumption is without loss of generality, and because practically speaking there isn't a compelling reason to spend complex p2{w,}sh or use non keyspend p2tr paths in the collaborative setting unless that's the only spend path available, we can kind of assume users (honest users, see https://gist.github.com/nothingmuch/a6ce459475a527a0e51f0600e354ef0e) will pick the smallest available one
so all that is to say that we're going to ignore these contingencies in the doc and the cost function implementation and treat the spend path as having a fixed block weight
|
|
||
| Optimizing these costs is the underlying motivation for the [*waste metric*](https://bitcoin.stackexchange.com/questions/113622/what-does-waste-metric-mean-in-the-context-of-coin-selection) used in Bitcoin Core's coin selection. This term in the cost function which governs coin selection internalizes an expected cost of spending a coin to the evaluation of the cost of its output. When the target feerate is lower than this predicted future feerate, this makes the evaluation of spending an input right now lower than this predicted future cost. | ||
|
|
||
| A simplified version of the waste metric (omitting some terms) is to consider some expected future feerate as effectively the zero point, by subtracting it from the target feerate at the time of coin selection. When the target feerate is lower, this will be negative, which makes *larger* transactions seem cheaper than smaller ones. The rationale for rewarding larger transactions is that the total blockspace that will eventually be consumed spending all of coins available in a wallet is essentially fixed, but what matters is simply *when* is that blockspace consumed, and at what feerate. During times of low demand for blockspace (and therefore low target feerates), coin selection will therefore tend to consolidate a fragmented wallet. When demand rises again, if coin selection must be done at the higher target feerate, since there would be fewer, higher value coins available on average, the expected transaction size at these higher target feerates will be lower, which in turn will result in a lower overall spending on fees. |
There was a problem hiding this comment.
target feerate is lower
lower than what? the zero point?
There was a problem hiding this comment.
if you consolidated prior to the increased demand/fees, then you are able to transact at a lower cost than if you hadn't done that
|
|
||
| The worst case for this kind of leakage, in terms of how much information is revealed in a single transaction, is when the entire wallet's balance is spent in a single transaction. This is problematic not just because it links all coins together but also because it reveals the wallet's total balance, potentially aiding in additional analysis (such as correlating this amount to past transactions that aren't unambiguously linked to it). | ||
|
|
||
| Let's momentarily ignore both the severity of the harm of such privacy leaks (assume it's just some fixed penalty), as well as the risk, i.e. the probability that liquidating the entire wallet is necessary (for example when under duress, in response to a security incident, or when needing to make an urgent payment for an amount close to the available balance). What then determines the cost is how much information is leaked. Considering this potential contingency after every wallet state, and then internalizing the cost into the cost of the transaction which results in that state implicitly encodes the implicit goal of privacy enhancing transactions, which is to leave the wallet in a state where the harm of any such liquidation is reduced, because the information leaks are minimized. |
There was a problem hiding this comment.
This information can be conveyed i believe without the first sentence
| Let's momentarily ignore both the severity of the harm of such privacy leaks (assume it's just some fixed penalty), as well as the risk, i.e. the probability that liquidating the entire wallet is necessary (for example when under duress, in response to a security incident, or when needing to make an urgent payment for an amount close to the available balance). What then determines the cost is how much information is leaked. Considering this potential contingency after every wallet state, and then internalizing the cost into the cost of the transaction which results in that state implicitly encodes the implicit goal of privacy enhancing transactions, which is to leave the wallet in a state where the harm of any such liquidation is reduced, because the information leaks are minimized. | |
| What then determines the cost is how much information is leaked. Considering this potential contingency after every wallet state, and then internalizing the cost into the cost of the transaction which results in that state implicitly encodes the implicit goal of privacy enhancing transactions, which is to leave the wallet in a state where the harm of any such liquidation is reduced, because the information leaks are minimized. |
There was a problem hiding this comment.
hmm, yes this reads better but i do think think this kind of thing should be spelled out eventually because thinking of cost/benefit and risk analysis leaves things very abstract, almost to the point of meaninglessness for some people, so at least anecdotally when explaining why a cost function or optimization framework makes sense it helps to tie it back to real world economic harm/injury that people would generally want to protect themselves from
|
shit i forgot to push some major changes to this one from last week, i'll integrate your comments
What do you mean by concrete ideas? Or maybe, how concrete? There's multiple levels of abstract concrete, e.g. this doc was not intended to contain any concrete cost function terms, hence "abstract" but it still has a lot of concrete ideas in it, like how to manage time dependence... The original goal of this document was to document enough to get the cost function work started
yes, what do you think of the way this was briefly summarized in the overview? i can do something similar |
|
@nothingmuch friendly reminder to push update :) |
@nothingmuch @yuval-block ping |
bc1cindy
added
documentation
bc1cindy
added
documentation
…nditions The conditions under "Coalition formation proposal structure" cover consensus fields, the feerate, the vbytes allocation, and input and output types, but say nothing about the values of inputs. Two kinds of value constraint came up in the review of `cost_function.md` (fungi-protocol/docs#15), whose multiparty section lists the constraints parties must agree on before accepting a proposal: - Nominal values: a required multiplicity of each of a set of standard denominations. These must be specified in terms of prevout values, since effective values also depend on the feerate. Checking them involves no search, so they need no certificate. - Effective values: these determine subset sum densities, and satisfying constraints on them involves a search, so they take the form of a challenge for a subset sum density certificate. The challenge is a target interval and a density requirement ρ. The aggregator picks a concrete feerate within the agreed feerate interval, and responds with ρ pairwise disjoint subsets of all the aggregated inputs whose effective values at that feerate each sum to within the interval, which every party can check before signing just by summing. --- - [x] Add per-denomination multiplicity constraints to the conditions - [x] Add subset sum density challenges to the conditions - [x] Specify the certificate: when the aggregator responds, at which feerate effective values are computed (the concrete feerate the aggregator picks), and how parties check it before signing - [x] Decide whether a challenge can leak which outputs belong to the party posing it - [ ] Link from `cost_function.md` once both are merged --- Notes: - Multiplicities fit the existing numerical intervals under intersection: one interval per denomination, counting the inputs whose prevout value equals it. - Challenges combine by union, since every challenge must still be met. Unlike the intervals, an unsatisfiable combination can't be detected when proposals are aggregated, only when the aggregator fails to produce a certificate. - Unlike the range proofs under "Effective value adjustments", which compute minimal effective values at the highest acceptable feerate, certificates use the concrete feerate the aggregator picks. - If a challenge's interval brackets one of the challenger's own outputs, attaching it to the challenger's proposal may tell peers which output is theirs. Avoiding such leaks is up to the cost function, and only randomly placed narrow intervals, which serve as density estimates, are recommended. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This document describes the overall approach to the cost function without going into specific/concrete terms