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.

They were so far ahead of the competition, it was amazing

Yes

I usually upload images to imgbb.com

I've never tried files other than images

I don't store files on nostr. I usually upload files to a central server and then link to them on nostr.

Yes

the spec thankfully uses json, which is extensible. Services can start passing that extra data with confidence that wallets who don't understand the extra data will ignore it, and wallets that do understand it will act accordingly

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

if there is no lnurl call then where you do get the invoice from? Someone must have queried the lnurl callback at some point -- can that person pass the hodl_invoice flag (if present) to the payer's device?

Also worth noting: wallets can detect zaplocker style invoices because the lnurl callback endpoint has a key value pair that says, "hodl_invoice":true

So you could look for that flag and then alert the user that this is not safe to do on a usually-off wallet like mutiny

036b4f68dbc23c111decb1512511c9a69ca18d8295899e1b36c3dfce2d8c3ad3cc

Mutiny might already be the best lightning wallet available and it just keeps getting better

nostr:nevent1qqs92hdnqr9cush332u9j3g8tkn5tl33kwsav9h95vlmvfxz0qxczuqpzamhxue69uhkummnw3ezuendwsh8w6t69e3xj7szyr03wvnhrqhnz4wn0vesyyd6rhj2s9gqcqk3jh5kf7gmua6we9nssqcyqqqqqqgg3wzdv

I endorse this solution. There is nothing wrong with the "long" lightning network being (mostly) separate from the regular lightning network. There can even be nodes that offer a bridge between them, for a fee. To help you make this a reality, here is my node pubkey for easy blocking: 036b4f68dbc23c111decb1512511c9a69ca18d8295899e1b36c3dfce2d8c3ad3cc

The cltv timelocks were meant for one thing but are useful for another. My users are willing to pay my node to hold htlcs for them for 24 hours, and I charge them accordingly for this service. So no, I don't do this with "no concern for others." I'm concerned with offering my users a service that they are happy to pay for. Moreover, other nodes can easily charge extra fees for providing this service, just like I am doing. If you don't like how my users are using your node, change the parameters of your node. Or charge extra. It's your choice -- freedom and optionality matter.

I can see how that can happen. Seems like it can be at least partly solved via push notifications.

I found a way to do it: run two nodes. The first has a short max-cltv-expiry and charges low fees. The second has a long max-cltv-expiry and charges high fees. Voila, your charging extra for longer-held htlcs.

They aren't there to hold it "forever" but they are there to say "I will hold these htlcs for up to this amount of time"

I think it is fine to increase cltvs because nodes not only consent to it, they charge fees for it. If you're not making enough money from doing this, raise your fees.

It's fine to use long-duration htlcs with nodes that *want* to. My node intentionally charges extra for long-duration htlcs, precisely to provide this service. If you don't want yours to do this, you can lower your max-cltv-expiry in LND's config file.

https://twitter.com/TheBlueMatt/status/1716848494554595526

Correct, my comfortably sheltered friend. When it's not winter I live in a tent at a campsite in Austin Texas. When it *is* winter I live in hostels in South America. Neither one is conducive to running a pi.

There are better reasons to use BitVM than low costs. I don't think that makes my reasoning bad. For example, I personally cannot use a $5 raspberry pi for smart contracts because I have nowhere to run it. I could use AWS but that is not an option for everyone.

If your only options are to run cool software on your own PC or AWS, that excludes people who don't have or can't afford an always-on device. A more detailed answer is linked below.

https://iris.to/note1ecus38seazsyjf93dwrcf0ewc7x24r5fgfyyzuq4t8dr7xk5fd4qtvzwrd

I made a todo list of things bitvm needs -- contributions are appreciated by anyone! Know of any WIP bitvm apps? Implementations of the virtual machine? Documentation or how to make bitvm apps? Educational videos/text-tutorials for developers? Share them!

https://github.com/supertestnet/things-bitvm-needs

Well I'm happy to report the tests were successful so today I hope to make a little chessboard so people can play knights only chess

Silly games like this help onboard developers so they learn the skills & build the tools they need to build actually useful programs. Chess is better played elsewhere. But you know what you need to make chess? Functions! And you know what BitVM lacks right now? Functions! So it's a huge help

Latest updates on bitvm: we're working on Bitcoin Chess!

Developer PenguinKing used python to write a bitvm program to check if a Knight's move is valid: https://github.com/mcbagz/LogicGates/blob/main/HorseMove.py

He exported it in a format that bitvm can understand: https://github.com/mcbagz/LogicGates/blob/main/HorseMove.txt

Now I'm testing it!

Funny line from Politico in 2017: "Over the next decade, the Congressional Budget Office projects the gross national debt to rise to roughly $31 trillion."

😬

Only six years later we're at $34 trillion. Talk about "under budget and ahead of schedule!"

https://www.politico.com/story/2017/10/22/us-national-debt-tops-1-trillion-oct-22-1981-243966