pull down to refresh

You seem to be missing the fact that the mint doesn't have any kind of sense for who has what token.
If I deposit 32 sats via lightning, the mint gives me an IOU for 32 sats. This IOU is mumble mumble some kind of random string mumble mumble that is signed by the mint but without the mint being able to see the random string. The mint signs it with its 32-sat key. Then I give this token to the merchant and the merchant presents the signed string to the mint and asks for sats to be sent via lightning in exchange (or simply for a new token to be created).
That's not only not true it's pointless, why use a custodian you're worried about being targeted by?
The server can key tweak it use countless other 2nd stage heuristics.. or simply not issue tokens after deposit
If that's your usecase it's pathetic
reply
That's not only not true it's pointless, why use a custodian you're worried about being targeted by?
A government could force an otherwise trustworthy custodian to take action against a user.
[...] or simply not issue tokens after deposit
Fair point. Can anybody familiar with the ecash protocols say whether there's some kind of protection against this?
reply