This guy gets it ๐
What do you think ofย https://github.com/nostr-protocol/nips/issues/236?
Maybe it is time for a backwards-compatible general cleanup on the Nostr spec? But it will only work if developers are onboard.
I'm not sure what to think myself.
Unified nostr theory incoming
On my BTCPayServer a tip of 293 sats or fewer is limited to lightnng payment options.
Is this normal?
Yes, it depends on what is considered dust onchain
I'll let you know at the next header council meeting.
Thanks! If you look at the initial commit, you can see I had some different variants of how to achieve this, but opted for one approach for now (nprofile/npub) .
The previous ones (nevent, naddr) allowed reducing the number of interactions by one, as the lnurl Json parameters would be publicly available. The naddr approach even allowed these parameters would be updateable with the same lnurl.
This means it wouldn't work for sensitive stuff such as lnurl withdraw or for dynamic purposes. BUT, one could easily add tags to these public lnurls to categorize them and create a freaking decentralized marketplace directly on nostr (cc Ben arc). Even cooler every btcpay/lnbits/etc could post these events and a marketplace aggregator would form naturally.
Anyways, just some feature creep thoughts. Nothing to do with the mission of that protocol proposal l, which is making lnurl great even for mobile noncustodial wallets.
So...don't use coinjoins?
I would rather keep the base specification of lightning simpler, as that makes it more likely for more implementations in the future. Having it baked in the base spec also makes it hard to expand on it incrementally.
BOLT12 and LNURL are very similar in nature, both boil down to a communications layer for negotiating invoice creation. Bolt 12 comes with stronger guarantees on privacy, but we can probably achieve decent privacy with nostr with clever tricks.
FUUUU ๐ i got sidetracked with https://github.com/lnurl/luds/pull/203
LNURL Over Nostr
Looking for feedback and helpful suggestions on getting this to a polished state:
https://github.com/lnurl/luds/pull/203
Lets make lnurl work even without an http server!
https://void.cat/d/TSrMYYo7V3ZTvz3amxctbW.webp
Today, I'm announcing the beta release of the Coinjoin plugin for @BtcpayServer. After many months of hard but exciting work, this opt-in plugin makes BTCPay Server one of the most extensive privacy-oriented Bitcoin tools around.
With just 2 clicks, your BTCPay Server can start coinjoining using the WabiSabi protocol, where you no longer have toxic change or amount-specific pools. Unfairly private!
But beyond those clicks lie some serious power tools to fight financial surveillance from those that want to oppress you.
Send to other wallets, cautious coinjoin entry, cross-mixing, continuous coinjoin mode, coinjoin label filtering, you name it - we got it.
But the most exciting one (so far) is payment batching directly in a coinjoin. The best postmix tool is the mix itself!
The weakest link in these coinjoin protocols is the centralized coordinator aspect, and so have opted to support multiple coordinators, in parallel, from the get-go.
"Be the change you want to see in the world". With this plugin, you can now run your own coordinator easily on your own terms.
By default, the coordinator runner is configured to donate its generated fees to @HRF and @opensats.
And with the integration of #Nostr, you'll have access to a free market of discoverable coordinators, creating an alternative to the built-in options to coinjoin.
This is still a beta release, and I welcome all constructive feedback. Please try it out and let me know what you think! Simply go to your BTCPay Server (1.7.12+) => Plugins => Coinjoin => Install.
i have an endpoint on my relay to quickly query subscriptions filters over HTTP.