0 sats \ 15 replies \ @justin_shocknet 9 May \ on: Atomic Split Lightning Payments, Hold Invoices, and Blinded Paths bitcoin
Not sure I'm following, are you suggesting chained wrapped invoices? Sn->bob->carol?
The wrapped invoices thing is theater, at least prisms are honest about about the trust level
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.
at least prisms are honest about about the trust level
What's dishonest about a wrapped invoice's trust level?
reply
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?)
reply
So why doesn't Bob just run a prism?
Because prisms aren't atomic and without an api enabled wallet, multiple QR codes need to be scanned.
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?)
I'm doing it for atomicity and for receiver privacy.
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?
I'd pay $1000/mo for something that provided atomicity if the alternative is no atomicity for free. I can't calculate the costs without trying to do it first.
If 50% of payments fail, is that acceptable when the alternative is 90% success?
No.
We've discussed doing a combination of wrapped invoices when we display QR codes and prism like many-invoices-for-many-recipients when they have a api enabled wallet attached, and it's very likely we'll do that. But I lack the foresight to know what's right before things have actually been attempted. I value my predictions of the future, and anyone else's, absent actual data, at near zero.
reply
Because prisms aren't atomic and without an api enabled wallet, multiple QR codes need to be scanned.
Atomic isn't a feature, it's a means to an end. No special wallet is needed with a prism, Bob's serving a normal invoice as is Carol. If anything the wrapping coordination takes API enabled wallet more than a prism.
I can't believe you have me making pro-prism arguments btw...
I'm doing it for atomicity and for receiver privacy.
Atomicity is not a feature. Carol is no more private than she would be with a Prism.
No.
So atomicity isn't the goal, getting payments from Alice to Carol while taking a piece is. You'd buy regulator insurance for $1000/mo over Atomicity given the option? So atomicity is another name for scamming the regulator.
I value my predictions of the future, and anyone else's, absent actual data, at near zero.
Sure if we conclude that predicting the future is an effort in futility, then why predict atomicity will sufficiently scam the regulator? We have no data to support that it will, could make the case for the opposite.
reply
I'm not making the case for anything succeeding. I'm making a case that I would like for something to work because I like it's properties more than the opposite's. The opposite may work better. I never said the opposite doesn't work, only that it doesn't have the properties that my ideal solution would have.
Thanks so much for the conversation. I really did not appreciate this:
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.
reply
My pleasure, happy to have elucidated that.
Just for my edification while I build out our solution, the preferred property referenced is the regulator scammability property?
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.
reply
You can run a lightning node not as a router
Point remains, it's not trust-less, it works poorly relative to prisms, and appeals to scamming the regulator, while valid, are not real solutions
reply