Building Intuition for the Cashu Blind Signature Scheme

Another fungibility hit here is that each token is that it has no information attached to it other than the fact that it presumably exists. What this means is, suppose you use an ecash scheme where you have tokens represent 1 satoshi of value. To transfer 10mBTC, you need 1 million tokens, each ~65 bytes (or 64 if you do the X-only point trick) or ~64Mb.

To lower the cost of transferring, practical mints using the BDHKE scheme need to issue multiple denominations of tokens. For example, tokens of value 1, 2, 4, 8, 16,…powers of 2 satoshi each, and have operations to split/combine tokens. This allows for O(log N) tokens to be transferred to transfer a specific value, instead of O(n). The problem is that for BDHKE each denomination requires its own minting key. This effectively reduces the anonymity set drastically, since each denomination is technically its own token, and you may be using denominations that just so happen to be rarely used by others.

An improvement is to use anonymous credential schemes. A credential can commit to one or more scalar values, and some credential schemes also can commit to one or more point values. The scheme used in WabiSabi, for example, commits to a point, and that point is a Pedersen commitment to an amount in satoshis. Each credential therefore hides its own amount and does not represent a single fixed amount like in BDHKE. While each token has its own possibly-unique denomination, we can make this a fungibility non-problem by designing mints so that they provide semantics similar to MimbleWimble, specifically: the ability to present multiple Pedersen commitments as inputs, then present multiple Pedersen commitments as outputs, and then let it be publicly-verifiable that sum of inputs == sum of outputs + delta blinding factors and a signature of the delta blinding factors. This allows every denomination to be fungible with every other denomination. The WabiSabi implementation I believe has a generic 2-input 2-output operation, as well as free minting of credentials that provably commit to a 0-valued amount to allow the same generic 2-input 2-output operation to split a single credential (you get your current credential with a specific amount, then ask for a freebie 0-value credential, as the 2 inputs, then get out 2 outputs that have the split you want).

Anonymous credentials do need a zk-proof that the amount lies within a range, which is generally implemented by proving that you either have an amount 0 or an amount equal to a power of 2, then have log N such proofs to prove that you have a total amount that is between 0 to N-1. This means that transferring of value still requires O(log N) data, but with better privacy (each denomination IS unique but are also all interfungible with each other, instead of the multi-denomination BDHKE token case where every denomination is not directly fungible with other denominations).


Finally: ALL ecash mints have rugpull capability. A mint has the private key to construct a token / credential, and the mint can issue itself (or a secret conspirator) a token/credential that contains an amount it did not receive as a deposit or in exchange for an existing token/credential. This can then be publicly shown and publicly withdrawn from the mint in the backing system (onchain or Lightning) as if it were just another withdrawal, and then at some point the mint has no backing for tokens it already issued to non-conspirators.

In theory a proof-of-reserves can be built, but in an anonymous credential system, it would be difficult to associate a credential with some amount that the mint knows and therefore can build a proof-of-reserve for. With multi-denomination BDHKE tokens, the mint can claim that it currrently has in circulation some number of tokens of a specific denomination as well as a list of the blinded tokens it issued and a list of unblinded tokens it already invalidated (the difference in length of both lists must then be equal to the claimed number of tokens of that denomination issued), and a client can check the proof-of-reserves by checking that the blinded forms of its held tokens are in the list of issued blinded tokens and its unblinded form is not in the list of unblinded tokens it invalidated, as well as that all the claimed issued tokens times denominations sum up to the proven reserves of the mint. But see the above issue with privacy vs multi-denomination BDHKE as used in Cashu ---- the reason the mint can make proof-of-reserves is precisely due to the lower privacy.

Proof-of-reserves can also be worked around by the above technique of overprinting tokens and then not including the secret overprinted tokens in the proof-of-reserve, thus allowing a rugpull to be done at any later time after the proof-of-reserve snapshot is taken.

1 Like