pull down to refresh
@06bc1a977d
You raise good points here:
- Lightning has a channel delta that each peer sets, and a 1 tx enforcement to execute the cheater
- Ark has a forwarding timeout that the operator sets, and a n tx tree enforcement to claim funds before the cheater
- Spark has decrementing timelocks, and no protection against a cheating operator
No I'm not involved in resolving anything myself. I shared this as a mere interesting project that needs more visibility and definitely embraces Bitcoin and Nostr ethos. See it as a Wasabi and its coinjoin coordinators, or as you said, Robosats and its trades' operators. These tools need a decentralized infrastructure, and this is one of those projects that allows it to happen.
I that fiat passes through bank accounts in this case too; if you are asking about stablecoins exchange, I've no idea.
v1.2.1 is out!
https://github.com/WoompaLoompa/btcpay-clink/releases#release-v1.2.1
What's Changed
- AsyncLocal mandate binding —
ResolveBtcpayInvoiceAsyncno longer queries by OrderId. The invoice controller setsLightningLikePaymentHandler.CurrentBtcpayInvoiceId(anAsyncLocal<string>) before callingCreatePaymentPrompts. The resolution method reads the AsyncLocal and looks up the invoice viaInvoiceRepository.GetInvoice(id), verifyingStoreIdmatch. - Relay session immediate resubscribe —
RelaySession.Extend()signals when new#pkeys arrive;RunAsync()resubscribes immediately instead of waiting for the 30-second tick. - Preimage-less same-node gate —
ClinkReceiptMonitorrejects preimage-less{"res":"ok"}receipts when the ndebit node differs from the merchant noffer node; accepts only when same-node.
I've been playing around with LNbits, I guess I'll need to play more with it!
NWC is annoying. Any chance of implementing ~lightning payments via CLINK?