btcschellingpt on Nostr: Hey calle 👁️⚡👁️ .. enjoying experimenting with Cashu 🔥 Been thinking ...
Hey
calle 👁️⚡👁️ (npub12rv…85vg) .. enjoying experimenting with Cashu 🔥
Been thinking about the idea of periodically shutting mints down to force redemption of ecash tokens .. helps mitigate a number of risks .. two thoughts:
1. Mint lifespan
By defining a mint lifespan on inception, all mint users would be aware of that lifespan, and not operate on the assumption that the lifespan is forever (Laura); clients could interrogate any mint for lifespan remaining and show it in the "Mints" section <x days remaining>. Key is that the lifespan is transparent;
2. User redemption fallback
Each new mint user could provide a fall-back 'location' for redemption of their ecash on closure - or possibly define that once in their eCash client? This redemption location could be on ⚡ or eCash (in its many and emerging addressability mechanisms). Clients could (automatically?) redeem all eCash tokens from an about-to expire mint to the defined fallback location
If achievable, this makes running a mint a whole lot less onerous. I've been responsible for other people's money and it is NOT in the FUN THINGS category. And the worst outcome is that you shut your mint with unredeemed sats belonging to unknown people.
Thinking further, a mint could itself have a redemption fallback.
If funds are remaining on shutdown that have not been redeemed, then they are automatically sent to a nominated place. Like the mint lifespan, this should be transparent. The mint operator chooses this but obvious candidates would be OpenSats, Brink, HRF, Bitcoin Moon Fund and other Bitcoin, Lightning, Nostr and eCash adjacent nurturing organisations.
For Cashu, if this is possible then to my mind, it makes much larger volumes of shorter lifespan mints (say 30-90 days?) viable.
Thanks for your work and all those who contribute!
Published at
2024-05-14 02:20:48Event JSON
{
"id": "8cad325ec47372e6017ebcf35ab36816809c077d4bba2c676e966b2c0c3087da",
"pubkey": "9b12847f3d28bf8850ebc03f8d495a1ae8f9a2c86dbda295c90556619a3ee831",
"created_at": 1715646048,
"kind": 1,
"tags": [
[
"p",
"50d94fc2d8580c682b071a542f8b1e31a200b0508bab95a33bef0855df281d63",
"",
"mention"
]
],
"content": "Hey nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg .. enjoying experimenting with Cashu 🔥 \n\nBeen thinking about the idea of periodically shutting mints down to force redemption of ecash tokens .. helps mitigate a number of risks .. two thoughts:\n\n1. Mint lifespan\nBy defining a mint lifespan on inception, all mint users would be aware of that lifespan, and not operate on the assumption that the lifespan is forever (Laura); clients could interrogate any mint for lifespan remaining and show it in the \"Mints\" section \u003cx days remaining\u003e. Key is that the lifespan is transparent;\n\n2. User redemption fallback\nEach new mint user could provide a fall-back 'location' for redemption of their ecash on closure - or possibly define that once in their eCash client? This redemption location could be on ⚡ or eCash (in its many and emerging addressability mechanisms). Clients could (automatically?) redeem all eCash tokens from an about-to expire mint to the defined fallback location\n\nIf achievable, this makes running a mint a whole lot less onerous. I've been responsible for other people's money and it is NOT in the FUN THINGS category. And the worst outcome is that you shut your mint with unredeemed sats belonging to unknown people.\n\nThinking further, a mint could itself have a redemption fallback. \n\nIf funds are remaining on shutdown that have not been redeemed, then they are automatically sent to a nominated place. Like the mint lifespan, this should be transparent. The mint operator chooses this but obvious candidates would be OpenSats, Brink, HRF, Bitcoin Moon Fund and other Bitcoin, Lightning, Nostr and eCash adjacent nurturing organisations.\n\nFor Cashu, if this is possible then to my mind, it makes much larger volumes of shorter lifespan mints (say 30-90 days?) viable.\n\nThanks for your work and all those who contribute! ",
"sig": "54d6d7930b8225522f65442c08b2bae00f2f1f0968c30efb58ba0ae9a8d4a895cd6df8bedc179b56b5f199aa4a89938ae54de188eae0432e6cbe74ff856c532d"
}