pull down to refresh
18 sats \ 14 replies \ @k00b OP 9 May \ parent \ on: Atomic Split Lightning Payments, Hold Invoices, and Blinded Paths bitcoin
I'm suggesting chaining bolt12 blinded paths, but chaining n wrapped invoices would allow atomic, non-custodial splits to n participants.
In our case, I mean alice->sn:wrap(carol)->carol.
What's dishonest about a wrapped invoice's trust level?
The blinded paths don't solve for HTLCs being unable to be split, so there's inherently a wrapper doing a partial forward. Obfuscating the path doesn't skirt this limitation.
With wrapped invoices, the payer is getting the invoice from the party doing the wrapping. This is a completely trusted step in the process as the wrapper could wrap anything, or nothing. May as well trust the prism to serve it in which case, as it's better UX, and doesn't create hazardous stuck payments on the network.
Now, it may work for scamming the regulator, but just as easily could not. It's still forwarding a payment.
Given that wrapped invoices have 0 technical justification, it's a fear induced narrative trap and those always end badly.
reply
HTLCs aren't split in either the hold invoice or bolt12 case. Both are just forwards.
With wrapped invoices, the payer is getting the invoice from the party doing the wrapping.
Fair point. This isn't true in the bolt12 case though. For our use, and geyser's, and robosats', this is okay because Alice trusts Bob which is why she requests to pay Carol through them. If we didn't wrap the invoice, Alice would have to trust we are giving her an invoice that goes to Carol anyway.
Given that wrapped invoices have 0 technical justification.
Atomicity is justification enough for me.
reply
Alice trusts Bob
So why doesn't Bob just run a prism?
Alice would have to trust we are giving her an invoice that goes to Carol anyway
That's the actual problem that needs solving, Nostr offers incoming for this purpose.
Atomicity is justification enough for me
Is it really though? What value do you put on it and have you calculated the costs? If so, at what cost is atomicity justified? If 50% of payments fail, is that acceptable when the alternative is 90% success?
Absorbing that cost comes down to a rationale, a fear based rationale that that leads to high time preference decisions to scam the regulator that inevitably backfire (unless you're Tether?)
Now, it may work for scamming the regulator, but just as easily could not. It's still forwarding a payment.
The idea is that it should be as much scamming the regulator as running a lightning routing node is. It's basically a reductionist approach. The only difference is protocol layer vs application layer.