What does nostr want to know about #fedimint?
Discussion
How do we setup to run over Tor
Good question!!!!
Adding to list of things I should research and answer. I don't think the Fedimint protocol supports it by default but I am certain this is on the "roadmap" (meaning I've heard it mentioned before so know people are tracking it).
I'm planning on wrapping Fedimint for Start9 which uses some fun networking tricks to do TOR for things that don't have it implemented, so perhaps I'll land an answer sooner than later.
What incentives do users have for wanting ecash over lightning ?
eCash is offline capability. It's just a string of data with a client that knows the pubkey of the mint to verify the signature on the eCash is valid.
LN, you have to manage liquidity. eCash on Fedimint, you do not. FM has LN Gateways which are LN node that have their own operators and mange their own liquidity. Similarly, Guardians are already trusted to manage your "system". I would expect similar relationships with LN Gateways.
Can you give more info on how ecash is offline? You cant exchange it offline
#LearnFedimint
You can! :)
each data string of eCash is signed by the #fedimint. On your client, you'll have the pubkey of the fedimint. You can use the pubkey to validate the signed value, X, and other data (need to learn what is encoded!) of the ecash note. Then take the notes to the mint when you're online to redeem them for new ones of the same value X (aka reissue) so now only you know the secret ecash data string for value X.
Since it's just data that can be printed on paper, you only need to verify a signature, which can be done offline with minimal compute requirements (mobile phones).
This does create a race condition with the sender, because if they redeem it first, then the receiver can lose it. I think client reputation and federation moderation will help deter this attack since the tradeoffs for custody would be of proportionate to value transacted or phsyically close enough for "proof of punch".