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.
| ### 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.
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