0 sats \ 10 replies \ @k00b OP 10 May \ parent \ on: Atomic Split Lightning Payments, Hold Invoices, and Blinded Paths bitcoin
HTLCs aren't split in either the hold invoice or bolt12 case. Both are just forwards.
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.
Atomicity is justification enough for me.
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?
reply
No. I'm not sure why you think I want to scam anyone, even regulators, or why you would think I'd believe this is a good scam. You could be trying to troll, in which case "ha," or you think I'm dumb, dishonest, or both, in which case you'll probably want to answer your question yourself.
reply
Maybe it's because of my comment
reply
Yea, I didn't coin this phrase and don't mean to imply it's nefarious.
I'm not using it as a pejorative, cat and mouse with regulators is necessary.
Indulge me as I'm trying to understand what property is being preferred so that I can be sure my solution possess that property.
reply