Skip to content

Abstract cost function - #15

Open
yuval-block wants to merge 1 commit into
mainfrom
cost-function-abstract
Open

Abstract cost function#15
yuval-block wants to merge 1 commit into
mainfrom
cost-function-abstract

Conversation

@yuval-block

Copy link
Copy Markdown
Collaborator

This document describes the overall approach to the cost function without going into specific/concrete terms

@bc1cindy bc1cindy left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"

Comment thread cost_function.md

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whose subjective value is at least $x - b_1$ and at most $x - y$

shouldn't this be $x - b_0$? (= nominal minus remaining budget, $(x - y) - b_1$)

as written, $x - b_1$ can exceed the upper bound $x - y$ whenever $y > b_0/2$

e.g. receive 100 sats with a 1 sat budget, coinjoin costs 0.6, so the bounds give [99.6, 99.4], while $x - b_0$ gives [99, 99.4]

Comment thread cost_function.md

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants