Yes, a reasonable viewpoint. We've yet to see a full fledged success in ecash tokens, though. I'm still skeptical about that.
Very interesting conversation about chain surveillance with Peter Todd and the Roman Stirlingov lawyers.
You spotted my sleight of hand :)
I really don't know. It would be crazy if it rose to above credit card fees for typical consumer transactions, but I wouldn't rule anything out - it's a free market.
Your numbers seem reasonable for normal situations.
Not a popular take probably but:
I believe Lightning will continue trending in the direction of higher fees, and I believe that's a good thing.
When it works properly, it's a payment network of spectacularly high quality. As fast or faster than a card payment, perfectly location neutral, no fraud risk and no TTP/censorship risk. Given this excellence, it can bear higher fees.
And its UX is *extremely* good, everything except 'make the payment' can be hidden; the only difficulty is the non-LN (onchain) part.
It needs high fees because when it's basically free, the DOS/jamming risk is huge, and people aren't incented to maintain the infrastructure needed. To be clear, channel jamming doesn't magically disappear with higher fees, but I think they might be a necessary *part* of the defence.
I do think L3s will emerge (or have) that will keep the ultra low or nearly free payments, with slight tradeoffs
It was about a month ago but KRAZAM absolutely knocked it out of the park once again with this one:
Wow, didn't expect to see the South China Morning Post cover Nostr today, mentioning NIPs, Fiatjaf, nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9 nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p and nostr:npub1ejxswthae3nkljavznmv66p9ahp4wmj4adux525htmsrff4qym9sz2t3tv
Cue CCP targetting relays in 3,2,1..
It's cool that you can compile bitcoin core to support fiat transfers:
`./configure --enable-usdt`
;)
https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-0345.mediawiki
My initial bias on hearing about OP_VAULT was 'meh, not only "yet another covenant op code" but also something trying to be ultra-specific (vaults only) instead of properly general'. But having spent a few hours studying it (neans: just understanding the basic idea!), I now have a very positive impression.
First, it now folds in CTV as part of the mechanism. CTV is a very pure and rigid implementation of 'constrain the spending transaction' and plays the role of building block in higher level protocols well. OP_VAULT is using it as a sub step and making generalised vaulting controls practical.
I feel like if there is a problem, it's that OP_VAULT is very flexible - tapleaf updating a la TLUV.
Properly trustless offline payments without trusted hardware is a problem that was never solved in digital cash systems.
Interesting paper, their suggestion to minimize risk of offline payments has merit, slightly surprising it was never implemented. But only slightly.
Yeah joined splices will be nice, but batching/time coordination...
Zero spender privacy *with phoenix*, yes - that's the tradeoff.
Re: swaps, has that definitely changed? I recently did a splice in and looked at the 'tech details'. There is definitely still a swap, and looking at the tx I didn't see an atomic swap style witness ... are they still fully custodial for that even now? Big chance I misunderstood it, though.
Well, not only blixt; this was the default for LN wallets to begin with and i guess several still support it (electrum springs to mind), but, as you say, it's problematic.
LN payments have become part of my everyday life here in ES, so i have gravitated to the most reliable option where I still have control of my money and, today, that's Phoenix, but I'm certainly interested to hear others' experiences.
Have you tried nostr:npub1xnf02f60r9v0e5kty33a404dm79zr7z2eepyrk5gsq3m7pwvsz2sazlpr5 embedded node w/ Olympus LSP?
No, seems interesting.
Phoenix has become the go-to wallet for me and many others. The new splicing feature makes things a lot easier to manage, but i am a little concerned that 'only one channel ever' may result in a much bigger privacy risk.
Lightning as-is does have better sender privacy than receiver privacy, but, in this one channel model, if a snooper finds it once, they'll unambiguously (pre-taproot) be able to keep track of it through splices.
The more basic point is not dependent on splicing: Phoenix being your only channel counterparty is another big privacy tradeoff.
The market will sort this out. There will be higher quality paid options (still pretty damn cheap) and lower quality "0-cost" options where you pay with your analytics/time (think youtube ads e.g.).
Did it forget that this trick is possible, you mean? It usually does forget things like that :)
I had the same thought, especially about nostr. It might push these schemes a bit beyond their acceptable limit.
Sorry for late reply, only now getting the feed properly stable.
Well of course. Question though, is that supported in bitcoinqt gui?
TIL Electrum lets you set locktimes on transactions. Just one more example of how feature rich it is, been using it for a decade and it has always been so good.