18 sats \ 0 replies \ @btcschellingpnt 13 May \ on: Thinking through Cashu bitcoin
Great write-up and equally keen to continue playing with this as it evolves and see where it goes. Certainly the pace of development and change is astounding.
I value the privacy and the interoperability and that it requires no L1 softfork of any kind.
The three key points I'm thinking about at the moment with eCash:
-
Unilateral exit: Redeem-ability .. at any point you choose, you can send all your eCash to any lightning invoice, node, address you control. Super important feature, and imo, one which places eCash as a Layer 3 and not some type of quasi-L2 (sorry @PeteFedi we're going to agree to disagree on this point). So this means you're never a hostage .. except that ..
-
Fast RugRisk - mints by definition are custodial As with lightning, you can run your own mint, or mitigate the risk of a rug-pull by concurrently using multiple mints. But typically you'll be trusting someone else who is operating a mint. The concurrent use of multiple mints is a different way of achieving a similar risk mitigation that Fedi achieves by having a quorum of custodians for each mint. Bottom line though is that the mint operator can just take the underlying bitcoin and shut the mint at any point. That's the big fast rugpull .. whereas the other rugpull is the ..
-
Slow RugRisk The mint operator could fork the open source code and start slowly debasing the eCash that's initially 1:1 matched by sats. There are a few proposals about how this could be checked (comparing sats held in the mint vs eCash tokens issued) .. but at it's core this is probably an unsolvable risk, prima facie
Potential mitigations
Part of the way to mitigate these risks, to varying extents, is to consider operating mints with a defined lifespan, and in the absence of action, to provide an address/invoice/eCash mint where your eCash is redeemed on shutdown. This forces the mint operator to deliver on the tokens issued, and validates for all users, that the sats are (were) there. A final fail-fallback in that circumstance (eg: provided LN URL no longer exists) could be to send to bitcoin charitable entities like OpenSats, Brink, HRF etc