Nostr Web Client

You are holding HTLCs open on all nodes along the route. HTLCs are a limited resource and those nodes are not being compensated for the use of this resource or for the increased risk of force closures.

You make a valid point that they can change this setting but this brings unrelated externalities. HTLC delta was included in the protocol to allow a grace period for node runners to reconcile failed payments on chain. Your use of this resource for economic purposes muddies the waters. I can understand why routing nodes are upset about this. It externalizes costs to the entire network.

A different design would resolve this conflict. What if both parties could use some sort of bearer asset that represented a potential lightning transaction? This asset could be issued by an always-online service, locked to the recipient, transmitted via any data channel, and redeemed when the recipient comes online, at which time they issue a LN tx to convert it to self-custodied sats. Sort of like a paper claim to some bitcoin. Like physical cash but electronic. Electronic cash! We can workshop the name. But what if it had even better privacy properties than lightning? I think we would really be on to something! What do you think??

Super Testnet 2y ago

> You are holding HTLCs open on all nodes along the route

Yes

> HTLCs are a limited resource and those nodes are not being compensated for the use of this resource or for the increased risk of force closures

That is their choice. They choose what fees to charge for the use of their htlc slots. If the fees they charge aren't covering their costs they can raise their fees. If they are unwilling to do so they will be priced out by nodes who are more willing to charge market rates for the use of those slots.

> You make a valid point that they can change this setting but this brings unrelated externalities

Charge money for them. If someone said, "I didn't want to have to think about my htlc slots being held in a pending state for an extended period," I think that is a perfectly valid reason to stop running a routing node. Other people will step in who *did* think about that and decided to charge money accordingly.

> HTLC delta was included in the protocol to allow a grace period for node runners to reconcile failed payments on chain

They have a variable-length grace period for more than one reason. Other protocols, like submarine swaps, have been around since pretty much the beginning, and they use hodl invoices too. Part of the reason that grace period exists is for use in swaps that take a few blocks to complete. I'm doing that too, just with a 24 hour grace period, which is well within the standard parameters.

> Your use of this resource for economic purposes muddies the waters

I think it brings clarity. Routing nodes have a better idea now of what they signed up for. Robosats and boltz exchange already showed them that invoices can be held for days at a time, now lightning addresses are doing it too.

> I can understand why routing nodes are upset about this. It externalizes costs to the entire network.

It puts the cost on routing nodes, who explicitly charge a publicly-advertised fee to cover costs that they *also* publicly advertise, namely, their max-cltv-limit. That's not "externalizing" a cost. It's saying "I agree with your terms."

> What if both parties could use some sort of bearer asset that represented a potential lightning transaction?

Then the sender would have to be online when the recipient finally decides to use the bearer asset. It's a cool product, but not what I'm looking for. I wanted to make async payments, where the sender and the recipient don't have to be online at the same time.

Reply to this note

Please Login to reply.

Discussion

vnprc 2y ago

If hodl invoices achieve wide adoption it will have an outsized impact on the network. A lot of things will change but let's keep it simple: it will push the entire network toward a reputation based system. This is bad for a permissionless network. Ideally, I should be able to spin up a new node, commit capital, and send payments with a high success rate. But now everyone is suspicious of unknown nodes. They're tracking your invoices to see how long they stay open. People run block lists and maintain a database of surveillance data. We already see this happening with channel probing. Maybe it is inevitable, idk. But I certainly don't agree that we should run toward this outcome. ¯\_(ツ)_/¯

In my previous reply I was facetiously describing ecash, which IMO is a categorical improvement for the async payments model. The sender does not need to be online for the recipient to receive payment. This is the role of the central server or "mint". It's just wheeling and dealing lightning payment promises all day, blind to the identity of its users. With the advent of DLEQ proofs, you can even trustlessly transfer ecash offline as long as the recipient knows the public key of the mint. People complain that the mint can rug you but is this really different than when a hodl invoice expires and you get a channel force close? I contend that it is not. This design adds a central party to facility async payments, improves privacy, and doesn't push negative externalities onto the network at large. The only downside is that you can't yet hack something together in a weekend. Or maybe you can...the gap is closing fast!

vnprc 2y ago

Well, not the only downside. Wen edit button?

The mint could go down. This is why people will form a social reputation layer around which mints are trustworthy. I think this is a better scaling solution than a lightning based reputation layer.

Super Testnet 2y ago

With regard to ecash, it's certainly a cool product, but I think it's a pale imitation of an asynchronous payment. Let's say Alice wants to send money to Bob. If Alice uses Carol's service to create an ecash token for Bob, it might seem asynchronous because Alice may go offline. But Alice isn't really the sender anymore. She gave her money to Carol and got her to promise *she* will send it to Bob. (Or rather, whoever comes first to claim it with something that is essentially a promissory note.) When that happens, the real sender is not Alice, it's Carol, and in order for it work Carol (the sender) must be online when Bob wants the money.

I don't have anything against that, I think it's cool. But I don't think it's *as* cool as a true asynchronous payment. With zaplocker, Carol never has your money. Carol is essentially a routing node between Alice and Bob, and routing nodes don't have custody of funds that use them as part of a path. I think that's cooler than a custodial model like ecash. Instead of depositing *money* with Carol, Alice routes a payment *through* Carol in such a way that Carol can only cancel it or forward it, not keep it. But after that it's largely the same: Alice may go offline, and Bob may come collect his money at his leisure. With ecash, Bob doesn't have a time limit, which is cool, but I think that's an acceptable tradeoff since the gain is self custody.

j 2y ago

Until we have drivechains, this obsession with making everything non-custodial just seems silly (arguably it's silly in a drivechains world too if you consider funds in the drivechains under the "custody" of the miners).

The fact is that custody scales payments. For small transactions, like zaps, it's probably fine to have a custodian. Obviously it would better to just run a lightning node, but I think custody is better than stuck htlcs.

just my 2 sats

vnprc 2y ago

You make a compelling argument about charging for the use of HTLCs. There's definitely some protocol work to enable this use case more widely.

I think with the rising price of bitcoin the value of payments on LN will increase and there will be a use for non-custodial async payments. It is super niche today but will become more necessary in time. So thank you for pushing the tech forward. I also think there will always be demand for custodial payments that have to make less engineering trade-offs and can deliver a better UX. This is a much much bigger market IMO.

What *I* find cool is imagining how to scale up privacy tech to the rest of humanity who are (let's be honest) never gonna give a shit about the cypherpunk ideals of bitcoin. I want to offboard enough people from fiat to degrade and destroy that system and move the whole world to a better system. I think ecash is perhaps the most promising new tech in this regard. I am keenly watching the development of covenants and payment pool proposals. If that effort goes well it could obsolete a lot of what we're talking about in this thread.

Super Testnet 2y ago

Let me try to answer your main concern by way of an analogy.

Suppose a little old woman opened up a street business where she will give you a quick massage. For $5, you can sit in her chair for up to five minutes and she will massage you and talk soothingly to you in a grandmotherly way. Her business is quite successful, and people love to sit in her chair, but she notices something: people rarely stay for the full 5 minutes. They typically only stay for 1 minute. Considering this, she drops her price, but keeps the sign the same otherwise: for $1, you may sit in her chair for up to 5 minutes and be pampered.

In this situation, I think it would be silly if she got mad at someone who occupied the whole 5 minutes, or close to it. The little old woman is under no obligation to offer the cheaper rate or expect every sitter to only sit for 1 minute. As long as her sign says you may sit 5 minutes for $1, any sitter should feel perfectly at ease sitting 5 minutes for $1. If the little old woman doesn't like it, she can raise her fee or lower the time limit. The silliest thing she can do is scream at customers to stop staying for 5 minutes when her own sign says they may, or tell them they are ruining her business, or making her mad. The sitters are only accepting the terms she advertises, over which she has complete control.

To me, it's the exact same with hodl invoices and lightning. If, for some reason, a node operator doesn't like the rates my users pay to use an htlc slot for something slightly closer to its maximum length than is typical, they have two options: reduce the time limit, or raise the rates. If they don't do that they have no one to blame but themselves. All my users are doing is paying the advertised rate for the advertised time limit. I don't think it's wise to blame them or me. If you're a node operator, and you don't like what my users are paying, change your sign. Be the change you want to see in the world -- don't harp on my users to stop using your node in the way you are publicly advertising they may use it.

vnprc 2y ago

Except you're not just sitting on this little old woman's chair. You are also sitting in half a dozen other people's chairs taking up space. The 5 minute limit has to be negotiated by all chair owners. Also, if you sit in the chair too long a portal to the underworld opens up and swallows the chair and also some cash from the little old lady's purse and one or more of the other unlucky chair owners. It's not a cut and dry analogy any more.

Super Testnet 2y ago

> You are also sitting in half a dozen other people's chairs taking up space

I'm paying the rates they advertise and staying within the time limits they advertise. If they don't like it, they can change their limits or raise their rates

> The 5 minute limit has to be negotiated by all chair owners

It is. If my payment didn't abide by their advertised limits I couldn't use them in my route.

> Also, if you sit in the chair too long a portal to the underworld opens up

I think you mean mean if I stay in the chair for their advertised limit, a portal to the underworld opens up. And if that's the case they should obviously lower their limit. Don't tell me I can stay for five minutes if that destroys your business