Code Monkey home page Code Monkey logo

Comments (7)

nothingmuch avatar nothingmuch commented on August 16, 2024 1

Some notes following today's call:

  • Fee amount and output registration amounts must be accounted separately in order to ensure that conversion is one way. This means there are both per-round fee credentials and long term fee credentials (lasting more than a just the duration of a round). Long term fee credentials and input amount credentials are convertible to per-round fee credentials, used to pay for the. Per-round fee credentials can be converted to long term fee credential claims (this is required so that the coordinator can know when the transaction is balanced and output registration has concluded).
  • To avoid fingerprinting of users of fee credentials, per-round fee credential presentation and requests should be made mandatory, and null per-round fee credentials issued during connection confirmation similar to input amount credentials. All the coordinator will know is that either no users used fee credentials or some users used fee credentials, which it can infer based on the collected fees anyway, so long term fee credential presentation does not need to be mandatory.
  • Long term fee credentials are issued after round termination. After tx confirmation of a successful round claims can be converted to long term fee credentials. After a failed round, long fee credentials need to be refunded. By including an input and signing last or waiting for a confirmed spend of one of the inputs the coordinator can be sure that the last user can't broadcast the transaction for a failed round after the fact after claiming a refund.
  • Fee credentials could either be opt-out with a preconfigured total limit that is roughly the same as the current dust limit (where dust change outputs are omitted and distributed among base denomination outputs) or opt-in given the trust requirement.
  • The coordinator can provide an additional discount on mining fees for users of fee credentials in order to incentivize rounder amounts and less UTXO set bloat.
  • Clients may require multiple per-round fee credentials in order to make parallel requests, but generally need only one long term fee credential.
  • Server state for long term fee credentials can be kept bounded by having several epochs, each with its own key, and pruning the nullifiers sets of expired epochs. Note that this requires credentials to be reissued into a new epoch before expiring. To avoid denial of service fee credential reissuance can incur a small cost (balance proof requiring a a small negative number of sats).
  • Fee credentials can be made recoverable from the wallet seed if the t scalar in the MAC is given as a hash of an arbitrary preimage provided by the client, and this as well as the the randomness in the credential attribute (and hence serial number) are both deterministically generated from the wallet seed. Clients can obtain the last valid credential when recovering from seed by retrieving a bloom filter or Golomb coded set of used serial numbers, searching backwards from the first positive result (which may be a false positive). The server would need to save copies of previously issued MACs for all unexpired credential epochs. The client must then brute force the amount in order to find out the outstanding balance. Only non-zero fee credentials require deterministic randomness in the serial number commitments, since there is no point in discovering.
  • If the coordinator sets a hard limit on the total amount per fee credential custodial risk can be limited and smaller range proofs required (primarily reducing the computational overhead, bandwidth difference is negligible).

from wabisabi.

nothingmuch avatar nothingmuch commented on August 16, 2024

with the more interesting building blocks we've been exploring it should be possible to realize this similar to or more simply than what i suggested in my first original draft: i think a reasonable way is to just have output registration require a pair of amounts, user output, and fees, and have long lived fee tokens only count towards the latter, whereas input credit tokens can count towards both

i suspect it'll be a while until we get there but i'm definitely already thinking about it

from wabisabi.

nopara73 avatar nopara73 commented on August 16, 2024

I think the coordinator fee should not be part of this research at all. That should be a concern for implementations.

from wabisabi.

MaxHillebrand avatar MaxHillebrand commented on August 16, 2024

yes @nothingmuch this seems to be what I'm talking about.

I agree with both of you that it is not pressing and part of the current priorities - however, I do think that we should keep the fees in mind, because they have to be in the implementation, and if the crypto magic does not work for them, then the protocol fails.

I just had a couple ideas that I wanted to note down here, it is more for future reference.

from wabisabi.

nopara73 avatar nopara73 commented on August 16, 2024

How do you know the implementor will want to charge fees?

from wabisabi.

nothingmuch avatar nothingmuch commented on August 16, 2024

For this to be viable, we might need stronger security proofs for the unfogeability of MACs (perhaps we could consider Anonymous Credentials Light scheme as a drop in replacement, where if I'm not mistaken unforgeability is the same as regular Abe-Ohkubo-Suzuki ring signatures), see #96

When unforgeability only underpins denial of service protection, a break can be detected immediately and the consequences are not very serious. With long term credentials for prepaid fees, this is a much bigger risk for the coordinator, and the only way to detect a successful forgery is when the coordinator realizes it is insolvent, and the attacker already had their fees paid for by other users, which would be catastrophic.

from wabisabi.

nothingmuch avatar nothingmuch commented on August 16, 2024

In order for the coordinator to know the total outstanding prepaid fee token amounts, conversions between different long lived credential epochs need to have cleartext amounts. This matters both for pruning nullifier sets, and for being able to validate/prove solvency.

However, it's noteworthy that the same need not apply for conversions between long lived fee credentials (only those of the most recent epoch) and per round fee credentials - if those balances are proven in zero knowledge and such a conversion is always done as part of obtaining null credentials (possibly with a 0) the coordinator only learns the total fee amount that was paid by redeeming prepaid fee credentials at the end of the round, which is beneficial for privacy. Note that this requires inputs to signal readyness to sign in order to transition to the signing phase, as the termination can't be inferred based on the outstanding credential balance in the round.

from wabisabi.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.