pull down to refresh

This is not a hard fork. Also you can "fork yourself" and you have money in both branches, so no risk for you actually (you can wait as long as you want and see who wins).
Ligntning network itself has the "you need money to receive money" problem. Incoming channels aren't free. And the first amount you receive is usually very small thay ecxludes 0 confirmation channels also.
I would use it just to see it works, but where I live nobody accepts it.
Also most logocal yhing i hear is that at first it is a store of value. Then it becomes a medium of exchange (prices are in local fiat currency but paent is in bitcoin of equal value). Then it becomes unit of account (the prices are set and displayed in bitcoin) when the local currency collapses.
You send them lightning invoice each month and they pay it. Why would you need specific technology for that?
I have the zombie channels even immediately after resetting the graph. Zero zombie channels may not be achievable, but is 40000 normal? And if it is, then why does Zeus itself warn me about it? It warns me, suggests I clear the graph, I clear the graph and it warns me again :)
Zeus reports around 40000 zombie channels, no matter how many times I reset the graph.
Related, is it normal that Zeus (embeded) reports high zombie channel count? It suggests clearing express graph data, but this doesn't help.
While self custofy will never be as user friendly as delegated custody, some people here are strangely hostile to usibility improvements in self custodial wallets, that are actually within the capabilities of the current bitcoin protocol.
I remember in the university many years ago we had an exercise where we tinkered with electrical meters. The mechanical one did turn both ways depending on the direction if the power flow. But that was more of a side effect of how the device worked, not some design decision.
The digital one from that time did measure positive usage in both directions. I am not sure whether this was design decision... We only tinkered with the mechanical one, but we did test the digital one in both directions.
I don't understand... There is no way as far as I know for the coordinator node to destinguish hodl from normal invoice. And my app was running in the foreground during this time. This was the message:
unknown hash, invalid amount or invalid final CLTV delta
Is this really caused by hodl invoices? What exactly in the invoice throws it off?
I know you guys like Zeus, but I have had various problems from time to time (which I have written about here). My last problem was that somehow robosats rejected my wrapped invoice. I don't know whether this specifically was a problem with zeus, but it was yet another problem I experienced while using this wallet.
This is nit what I ment. The examples here are payment to keep active seeders. What I want is a way for client to negotiate payment for traffic. For example if one client downloads 13 KiB from another, i want a way for the second client to say 100 microsat per byte, and if the second client agrees, it starts sending sats and the second client starts sending bytes. After the 13 KiB is ttansferred, the total amount of sats paid to the second client should be 13000*0.0001=1.3 sats.
Is this possible or complitely impossible on the lightning network? (I am talking whether the lightning network can do that. I am perfectly aware that there is not torrent client that does that.)
The problem is that if the large suppliers need to be paid in fiat, the merchants will not be able to keep the prices denominated in bitcoin stable. Their expences will be dependent on the fiat price of bitcoin, since the large supppliers need to be paid in fiat.
I am wondering something. If the mining pool coordinators are the ones setting the block template, are they the ones determining the signaling bits, not the clients?