> 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. 



> 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. 

k00b

> 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?)



justin_shocknet

bitcoin

Atomic Split Lightning Payments, Hold Invoices, and Blinded Paths

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.