Conversation
nothingmuch
force-pushed
the
cost-function-abstract
branch
from
ec8385b to
762f565
Compare
Add concrete cost function metrics & discussion
nothingmuch
force-pushed
the
cost-function-abstract
branch
from
762f565 to
1e95ed1
Compare
|
|
||
| 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.
| 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. | |
| 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 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. |
|
|
||
| ### Payment urgency | ||
|
|
||
| As described in abstract terms above, a per intent deadline or confirmation target similar to the standard user experience for determining feerates can be used to control the time sensitivity of specific actions. Although imagining the cost function outputs a function of time has mathematical appeal, in practice to simplify things we can model these as piecewise linear scaling of cost function terms which are computed independently of time. |
There was a problem hiding this comment.
The last sentence is confusing me. Specifically "independent of time". Bc the next paragraph discusses a cost term interms of a deadline. What is this last sentence conveying?
There was a problem hiding this comment.
it's meant to convey the idea of computing the metrics based on the data in the transaction graph extended by the decision space (which is a set of constraints on the evolution of the transaction graph) separately from computing how wallclock time affects the evaluation
instead of needing to have a set of branches for each alternatives for each point in time instead it's a set of alternatives plus a way of comparing them at every moment in time
|
|
||
| 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. | ||
|
|
||
| While specific future feerates are inherently unpredictable, if at some point in time it's clear that a low feerate is sufficient for timely confirmation, then it is possible to reliably predict that at any point in the future feerate is likely to be higher. When this is the case it makes sense to spend a larger set of potentially smaller outputs, consolidating their values, because although the total blockspace required to spend a set of outputs is fixed regardless of when each output is spent, the cost can be minimized if more of this blockspace is consumed at lower feerates. |
There was a problem hiding this comment.
Rather than "it's clear ..." here, I think the frame of a subject making a bet rather than objective clairvoyance is closer to reality and more legible. And then follow that the claim for batching a large set of smaller outputs is is a leveraged bet. Basically: Like you say, the accepted feerate is a natural and unpredictable market phenomenon, if YOU dear reader (or "one," less-dear-but-concrete subject) FEEL(s) a low feerate is sufficient then batching essentially lets you apply leverage to your bet for more upside and lower costs, especially the cost of downside for slow conf of a particular batch is not expensive because the subject is relatively less time sensitive.
There was a problem hiding this comment.
what this is trying to say is that since fees have a floor, it's easier to say whether or not fees are low right now rather than will they be low again in the future ("can only go up from here")
| ### Utility of payments | ||
|
|
||
| For the purposes of this document a *payment* will mean a net transfer of funds between two parties. Transactions are a way of realizing payments, but a single transaction can perform multiple payments or even net settlement for multiparty transactions. |
There was a problem hiding this comment.
I overwhelmingly prefer and have been promoting "transfer" as the precise vocabulary for this utility over "payment." Especially because transfer from A to A', the same party with different spending conditions is harder to reason about as a payment than a mere transfer, and transfer is even in your definition.
Payment is discharge of an obligation. Transfer is just moving from one location/set of rules to another.
The confusion that follows "output creation intents will be assumed to correspond to payments but that isn't necessarily the case (for example funding a lightning channel)." is fixed by this vocab preference.
There was a problem hiding this comment.
the intent here is specifically to discuss the utility of discharging that obligation, the same argument also applies to transfers but this section is specifically to justify why a net decrease in nominal/objective balance (not just the fees, but the funds over which control is relinquished) is still an increase in utility
|
|
||
| On-chain privacy techniques in Bitcoin come in two flavors: overt, or covert. Overt techniques add ambiguity in a way that is apparent, and therefore can be identified as privacy enhanced transactions (e.g. CoinJoin). Contrast this with covert techniques (e.g. CoinSwap), which aren't easily identifiable. | ||
|
|
||
| Both overt and covert techniques carry censorship risk. For overt techniques this is inherent, as the use of the technique is self-evident, and exchanges that may regard this as a compliance risk (which incidentally is more often the case for fraudulent exchanges) are more likely to reject or even confiscate deposits that are linkable to such techniques. For covert techniques, although the technique itself doesn't flag a deposit, it may result in counterfactual linking of the deposit funds to coins that are deemed tainted. |
There was a problem hiding this comment.
This section is kind of politically hot and could be cooled without mentioning exchanges or compliance or what you think about the character of those exchanges. The core message that it opens a surface for censorship based on an opinion of an overt technique is sufficient to get the point across and doesn't carry the same alienation / adversarial risks the current framing does.
|
|
||
| Reliably confirming transactions at the lowest possible feerate before the deadline of any payments it realizes is not feasible, because predicting future feerates is a market prediction problem. Attempting to confirm as close to the deadline as possible can incur additional costs due to the variability of fees, or risk missing the deadline. If payment deadlines are missed, the utility obtained from making the payments may be diminished. Some risk of missing the deadline or overpaying fees is always inherent. | ||
|
|
||
| This perspective suggests that the same action performed at different times is in fact not the same action, but two different ones, which will have different costs. However, to keep things simple we will not consider actions-at-a-point-in-time separately, but rather each action's cost evaluation will output not just a single numerical value, but a function of time, and different actions can be compared across all of time. |
There was a problem hiding this comment.
In "Utility of payments," the move from scalar costs to cost-as-a-function-of-time:
each action's cost evaluation will output not just a single numerical value, but a function of time, and different actions can be compared across all of time.
I think it's worth exploring what "compared across all of time" requires concretely. When one action's cost curve is strictly below another's everywhere, the comparison is trivial. But when curves cross, for example consolidating inputs costs is cheaper at low fees but defers nothing, while minimal coin selection is the cheaper move at high fees and defers consolidation to a future fee rate, the cheaper todo depends on beliefs about future fees. You need something extra to decide like some fee prediction.
Even a brief note on what mechanism resolves crossing curves would help ground the abstraction. e.g. an expectation over a distribution of confirmation times, as sketched in "Internalizing expectation of future costs"
Or is this included somewhere that I missed? Seems like prediction / deviation / distribution of future fees informs many many decisions this cost function is concerned with.
There was a problem hiding this comment.
in the concrete cost function discussion, and in the code this is modeled as a piecewise linear decomposition which makes time based comparisons easy
the tacit assumption is that a qualitative judgement (e.g. how much absorber entropy or subset sum density has been quantified) doesn't depend on time, which may prove incorrect if we find a counterexample
|
|
||
| ## Use in multiparty protocols | ||
|
|
||
| In the context of a multiparty transaction construction, a fixed overhead of 10.5-12.5 vB per transaction incurs a cost can be shared with others. Since this is substantially smaller than a typical input, the savings are arguably negligible. If a cross input signature aggregation soft fork is enabled then instead of a fixed overhead, a per input overhead can additionally be shared among participants, providing a much stronger incentive than the fast diminishing fixed overhead's savings. Such savings are limited, ultimately by consensus block size limits, and practically by policy, which limits transactions to 100KvB (though this limit can be overcome by use of multisig and pre-signed transaction trees). |
There was a problem hiding this comment.
yes ~all the savings in multiparty protocols are in net-settlement before CISA. I think if overhead is worth mentioning at all then net-settlement or NOT producing inputs when otherwise using the blockchain as a communication mechanism instead of a side channel is producing excessive inputs should be too. https://payjoin.org/docs/how-payjoin-saves/
3 participants
This probably could use some diagrams and more examples.
Another pull request with the concrete cost function being proposed (i.e. specific privacy metrics) will follow shortly