Yes. All ecash mints need to rotate their signing keys to prevent the spent ecash database from growing indefinitely.
Also, yes, that's the whole idea of a federation. It's like a hundred times harder to build than a single key system but worth it because fedimint allows you to distribute trust. As Satoshi taught us: "The root problem with conventional currency is all the trust that's required to make it work."
no can do, gonna let it run
surely this can't be the only way nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg

ugh, does it work with a fake email?
just now in work chat
new steed 😁
#m=image%2Fjpeg&dim=1920x1446&blurhash=%23jF%3FR_M%5ERhoes%3BogjroLofBHslaxWBbIbIaxaya%23XpWFjYWWj%5Bj%5BayaxWBNLbdt7j%5DWBaej%5Dj%3FoJi_t8fkkCWBaej%5Dj%5BjYoIbJWCa%23ogj%5Bayj%3FaxWVWCj%5DWCbIkCj%5BWBax&x=d84cd57272a09be01f6d4bcb4013894a180b09b89d5266b70efe2267c48b9f15
Being a reply guy works fairly well.
CLN was the first to support bolt12. It was invented at Blockstream.
With the mullet this hairdo is just
nostr:npub1sezgmhk40mk5znnqse5jz4mjx40vszz45zwqnf7wyxqvdz0t8wnq9mnhp3
#negr0art
#m=image%2Fjpeg&dim=1024x1024&blurhash=UWFY_stR%3FwozXokCM%7Cj%5DIuRQRjRjXAadRjae&x=43f8737b2188e37430d9597f673441f9f8c8d4ce2c0b91784642b41847284398
DOOM WAS IMMINENT
Those who think they do, don't know him
No different than a squad of birds ready to blow him
Sorry Charlie, get back up on your Harley
Win, lose or draw, plus beat you at Atari
Drop they ass deep in some far-off Safari
And prob'ly even got the answer to, "Who the hell are we?"
Metal Face squadrone, tell the real ones, "Shalom"
In a calm tone, bomb thrown
Ecash mints need to periodically rotate the private keys they use to sign ecash so every ecash opendime would have an expiration date. Also, consider you are loading custodial bitcoin IOUs onto hardware, so there's no guarantee it will still be valid when you go to spend. There is also no way to audit the ecash on the device, so you have to spend it to validate it. I think the tech is just not suited for this use case. Better to load bitcoin onto physical hardware: it never expires, is trustless, non-custodial, easily audited.
Further reading: https://gist.github.com/callebtc/ed5228d1d8cbaade0104db5d1cf63939
Great question!
Ecash mints need to periodically rotate the private keys they use to sign ecash so every ecash opendime would have an expiration date. Also, consider you are loading custodial bitcoin IOUs onto hardware, so there's no guarantee it will still be valid when you go to spend. There is also no way to audit the ecash on the device, so you have to spend it to validate it. I think the tech is just not suited for this use case. Better to load bitcoin onto physical hardware: it never expires, is trustless, non-custodial, easily audited.
Further reading: https://gist.github.com/callebtc/ed5228d1d8cbaade0104db5d1cf63939
We can wait another 10 years for a potentially better proposal. In the mean time we will need to scale bitcoin using custodial solutions, locking out most of the world from self-sovereign bitcoin store of value. And after a decade we might find out that actually CTV was the best option, or that it is too late to ever soft fork again and we missed our window.
This wouldn't be the worst outcome, but I think the risk of doing nothing is greater than the risk from activating CTV.
nostr:npub16vzjeglr653mrmyqvu0trwaq29az753wr9th3hyrm5p63kz2zu8qzumhgd
#negr0art
#m=image%2Fjpeg&dim=1024x1024&blurhash=UFH.QlWYWYa%23M%5EjYM%7Ba%23ThoJWBj%5BI8oLt6a%7C&x=1efaeda880532b71077f7c8dc06e1c7760a6094a96d70f9519df35553daab081
NOICE
One thing that is unclear to me is how do you commit to a TXID but then later spend those funds in a different way. This is a missing puzzle piece in my mental model.
Do you use a keypath spend? What about for non-taproot addresses? Do you use a different script branch? If so, how does someone really know their funds are safu on chain without monitoring the CTV UTXO to ensure it hasn't been spent out from under them using this other script path?
I think a simple script example would go a long way towards building understanding, definitely for me, hopefully for others as well.

The band is crazy. It's two guys: bassist and drummer. The bassist uses heavy distortion to mimic a guitar sound.
I don't have a single work that explains fully why CTV is the best covenant proposal. I came to this opinion slowly after many years of studying bitcoin and lightning technical design and watching the debate play out.
I think the most convincing argument today is that many builders working on different problems have converged on the same, simple tool that enables or amplifies what they can build.
James O'Bierne has been working on vaults for years. First he designed a protocol using only CTV, then leveled it up into a distinct opcode, OP_VAULT, that did not use CTV. After incorporating feedback and improving his proposal he brought CTV back in because it was the best tool for the job. Now, OP_VAULT depends on CTV as an underlying primitive. I can't think of a stronger endorsement.
https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-0345.mediawiki
Ruben Somsen and Lloyd Fournier showed that CTV improves DLC efficiency by ~30x in the worst case.
https://mailmanlists.org/pipermail/dlc-dev/2022-January/000102.html
Greg Sanders built an LN-symmetry proof of concept and, in the process, found that using CTV simplified the protocol, removing round trips and improving payment times.
https://delvingbitcoin.org/t/ln-symmetry-project-recap/359
I haven't looked into Salvatore Ingala's MATT proposal but apparently he's planning to include CTV also. Maybe nostr:npub1775tuvua6h9mkmlqm3ragxpv3z3eegahhshydj36u2xq72vve9lsq29jcw can elaborate on this one.
The other thing that gives me conviction is the simplicity of CTV's design. Saint-Exupéry said that perfection is only achieved when there is nothing left to take away. I think it's clear that BIP119 embodies this principle. It's as simple as it can be to achieve its design goals. There is nothing left to take away.
#m=image%2Fjpeg&dim=1214x1280&blurhash=%7CbI4q%2BIoEzwf%252Nas%3BoLkC%25%7E%252%24*NabHoLj%5BWVof_NRk%24*j%5BR*oLbGaya%7C%7EWWBNajGs%3AWVoLj%5Baz%25gayoLWVbHjtj%5Bf6j%5BW%3Bf6ofj%5BoLayWVoLj%5BWAWVoMayWVjtoLWVazM%7Bj%40j%5BaybHWVoLoLa%7CMxj%5BWVfPoLj%5BWVayoL&x=1fa6a95d43aab6490a010e8e092547ce433eeb058b881f616d0c280150679702
