Skip to content

Instantly share code, notes, and snippets.

@callebtc
Created April 21, 2023 21:29
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save callebtc/7b60506343a7a3dc796e03144f0ed6f6 to your computer and use it in GitHub Desktop.
Save callebtc/7b60506343a7a3dc796e03144f0ed6f6 to your computer and use it in GitHub Desktop.

Dear Eric, thanks for the review, I really appreciate the time you took looking into this. I've addressed your comments one by one in the following. Best Calle

The key rotation concept will keep database size limited but I’m not precisely clear on why it is necessary for the mint reporting. Why isn’t it possible for such proofs to be produced without place an expiry on eCash notes?

Rotating the keys has two main effects:

  • If forces an "arrow of time" onto the token dynamics which is ultimately enforced by the users themselves. User wallets refuse to accept and tokens from an older keyset, either from a mint or from other users. That way, we can force all tokens from old epochs that ever move into the newest keyset.
  • At the same time, it forces the mint to publicly commit that it won't add any more mint proofs to its report (which can be publicly checked). At first glance, the mint would not be incentivized to do so anyway, since mint proofs increase its liabilities and thus the open balance it reports. However, a cheating mint could still choose to add fake mint proofs to the list when the open balance shrinks too much and it risks being caught by its users. Limiting the issuance of mint proofs makes sure that the open balance of an old epoch can only shrink and never grow, which means that the risk of a cheating mint getting caught monotonically increases over time.

In summary, rotating epochs simulates a periodic "bank run" which allows users to observe past epochs and determine whether the mint has manipulated the reports.

I'm very happy that you asked this question (which is, I think, the most important question to ask) because I wasn't able to spell it out in this clarity before you asked and I thought about how to answer. I will add this to the document.

Because a user must sacrifice privacy to call out an under-issuance-reporting mint may be a hindrance on adoption of voluntary reporting

I should add here that sacrificing privacy in the context of the ecash mint is still a lot better than for an account-based system. In this specific case, it means that a mint proof can now be publicly linked to your burn proof. In the worst case that would mean that the mint would be able to know which Lighting payment (peg-in) was linked to the mint and burn proof pair but luckily, Lightning sender privacy is so good that the mint could basically never figure it out. In the more common case, the mint & burn proof pair you reveal for contesting a cheating mint are recycled ecash tokens that have no trace to the initial peg-in transaction anymore. I should add these nuances to the text, thank you.

-   Anonymity as a weapon of consumer protection
-   I’m not sure of the idea that we could depend on voluntary participation in such a system by users because (1) it is voluntary, (2) they have to reveal identity to prove a cheating mint, and (3) there are technical resource constraints.

Yes. However, I imagine this would be feature of an app you'd use. Users would simply see a "green dot" on the mint when the last report checked out. They don't have to reveal their identity (as explained above) but only sacrifice the previous unlinkability of their mint and burn proof.

-   What’s novel about anonymity in this system is the ability for “consumer protection” groups to participate within mints anonymously
-   What I expect is there to be consumer protection services (with profit motives) to emerge that are setting up wallets and constantly checking mints for any sort of malicious/negligent action and actively reporting. Rather than mint participants leveraging technology to bear the burden of checking solvency, a centralized provider could economize on this function and provide a standard check of approval for good-standing mints. EG, proof-of-X companies like Hoseki could evolve to serve such a function.
-   Basically, if mints are restaurants then there will be Michelin star reviewers that are constantly eating at them without their knowledge and deciding whether or not they get a Michelin star.

I'll have to think about this. I also thought about this but I'm still not sure how effective it would be to withhold a large balance from rotating. What I'm confident about is that the chance of getting caught by an individual user increases as the outstanding balance decreases.

-   Time is your friend
-   I might be missing something here but for a mint to set up a wallet and create fake burn proofs wouldn’t it also have to create fake issuance ex-ante and thus the net reduction towards the mint’s liability would be zero?

Indeed, however adding entries to both lists does not shrink the outstanding balance. Still, due to the finitude of the epoch, a mint commits to not to add any more mint proofs for old epochs. I've addressed this in the answer to your first question.

-   This writing is done very well but this particular section I had a harder time following. If you plan to revise happy to walk through and perhaps simplify or create a bit of cohesion here.

I will incorporate the points above to make it more clear. Happy to get your feedback on the revised parts!

-   The separation of Custody and Minting
-   This is a really compelling concept. I think it could fundamentally be considered a “best practice”. Obviously necessary in Cashu but also for Fedimints.
-   This dynamic creates a natural check on the system whereby guardians are providing much of the “due diligence” on various mints. Also, mints would only want to use guardians that they trust not to be taking on out-of-band liabilities.

Happy you see it also that way!

-   Would be interesting to tease out more detail around the efficiency of a single-sig mint vs. a multi-sig mint

Unfortunately, my knowledge about the performance of federated mints is only limited and I don't know of any systematic performance measures under different conditions. From what I hear, the performance of federated setups is greatly impacted by network delay (because of how consensus algorithms work) and that's an issue a single-sig mint doesn't have to deal with.

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