Yep, that's the idea. You don't give them any special powers, it's just a mutual agreement that is automated. Anyone is free to leave the pool at any time. The channels don't have to get closed either, they just become gateway channels from the perspective of the pool.

For peer swap or channel openings, for example, the node operator will get a notification and some reasonable time frame to complete it. But the moderator can't force the node to do anything.

The other nice thing about this is we don't necessarily need gossip to communicate what is needed between each and every peer. Instead, the moderator can be a lightweight single point of contact.

Perhaps it would be some kind of very limited scope macaroon. I don't know if you could rate limit queries so they can't make more than 1 query per hour.

There is no trust needed for the third party since the moderator only broadcasts "here's my recommendation" and has no power to make any direct changes. The nodes would have to voluntarily make any changes.

Or maybe I don't understand what is being entrusted when you say trusted third party.

You're certainly not trusting access to any funds, or allowing access to any of the server/hardware.

I don't think scams are necessarily "defeatable" in the sense that they can be made to cease to exist. They will always exist in some form or another, always attacking Bitcoin or unsuspecting users. I think the question is, how do we make sure they are exposed so as few people as possible fall victim/prey to them, and also, how do we technically make our systems robust so that our systems don't topple over from scams either.

I believe we live in a time where 99.999% of everything that exists is a scam in one form or another primarily due to the influence of fiat, but also, the very nature of human beings in their desires to get ahead of others through tactical means. Many times these means come at the expense of others. I see it as a fundamental reality, like math and physics. Scams simply exist as a rule.

I agree we need to continue to expose the scammers, while also ensuring Bitcoin is robust against attacks. I haven't lost faith in the game theory that scammer attacks can be mitigated by the heavy fees and that their attempts are completely futile. They will run out of money sooner than Bitcoiners become impatient, from what I can tell. Of course, some Bitcoiners are far less patient than others. But I don't think any attacker in this case can sustain the cost of high fees forever. And in the meantime, Bitcoin gets stronger as mining becomes more attractive, giving us more security.

Not really related but I would really love to see a release where the LN node scans the mempool for any transactions affecting a channel and refuse to use the channel if such a TX exists. I've had many payment failures where a channel closed during the middle of my LN transaction and caused my sats to be in limbo. Luckily, these cases usually resolve after a very long CLTV timeout without any FC. I think it makes sense to avoid risky LN transactions that involve channels that could be confirmed-closed at any moment.

Sure, but I think people are realizing how valuable the hardest money in the universe actually is and what a premium it is to be able to store your money on it really is. The security of it is that good. If you can compromise on that, you can save money in exchange for risk. For example, using Liquid or some other side chain system. I'm not saying Liquid is as good as on-chain BTC.

But it's like telling someone that it's probably healthier to eat this $50 grass fed steak rather than the $2 soybean veggie patty. It doesn't help if they can't afford such premium food and can only afford $2. So, you make do with what you can afford. I don't know if that's a sign of a broken system, but maybe just a sign of the reality of the highest level of security in the universe. And maybe we ALL don't need it, but certainly it's pretty damn awesome that we can get a piece of that security today.

So keep your liquid funds in something, and if you're literally broke AF, and even Liquid fees are killing you, then you might have to go custodial. But work your way towards something non-custodial. And I don't think you really have to go non-custodial. I think there will always be some weird but viable and properly running side chain you can use. Not a fan of those side chains, but they are better than custodial crap.

I think it's pretty impressive. Nice, Bitcoin!

I would store all your wages in LN and at the end of the year move the excess money on-chain once per year as long-term retirement savings. If you expect to make some bigger purchases in the upcoming months, you could also keep that on-hand. Hopefully over time, your long-term savings is much bigger than what you keep for daily expenses.

Sounds like a good place to get mugged.

When you're no longer shocked that someone is stealing a bunch of stuff from shopping malls and drug stores, because it's so expected now. Or when drug use and violent crimes are near all time highs. It's not a hard line, but that's generally what I look at.

A "small amount" could be like 12 months worth of groceries and expenses, and a "big amount" could be your life savings of 20 years. Would that still be reasonable?

It seems like a fairly trivial exercise to determine the exact balances of channels. I haven't written the script yet, but it would consist of attempting a bunch of different size payments with the final destination back to my node which I forcefully always fail as the last hop. I can figure out which hops said "yes, I have enough balance for that" and incur no cost or risk to getting that information.

So given this, I have decided on my node to just update max_htlc_msat to a figure generally just below my current local balance.

In fact, I have been pondering as a non-dev whether we can add another optional node operator flag to LND which signals "public channel balance broadcasts" and other nodes can use this information as they wish.

Some routing would become immediately much more efficient, especially if people choose "only use known balances" in a route. For greater privacy, people could choose "all channels" of course. It's kind of like we have the option to use TOR or not.

I don't know how much more efficient payments would be if we knew all the balances of channels, but I suspect it will be a lot more efficient. And fee discovery would also be improved, since we know that "0 ppm" on a zero balance channel isn't a relevant or competitive fee.

Would people use this flag?

The second feature I was thinking of was the ability to set fee rate formula based on that balance. If not public, at least a server-side formula. What happens sometimes is that my fee updating script isn't fast enough to catch a sudden drain event. Maybe I can run it after each TX, but we know gossip is a pain. So it might be interesting to tell other nodes that I have a dynamic fee on this channel which changes based on the broadcasted balance, so if they want to drain the channel, it's going to cost a lot more sats. I don't know, haven't fleshed out the details, but the point is to have dynamically changing fees without spamming gossip channel updates to the whole network.

Rampant crime

That makes sense but it's usually a static number like 10 or 100, especially if it's a small channel. What I'm saying is that these are not sustainable if we have to close them.

LN seems like economically requires people who hold a large number of BTC to make big enough channels that can counteract the price of expensive on-chain TXs. If Bitcoin's future is only full of people with small amounts of BTC and all on-chain TXs are extremely expensive, I don't see how everyone can participate economically.

I hope so, that would be great!

But what I'm saying is that the fees don't matter. Once the liquidity is gone, it's gone. I could raise my fees super high and maybe I'll get to "keep my balanced liquidity" but what I'm basically doing is turning my flow to 0. There's no point in that. And as soon as I change it to something that has flow, the balance is gone again. Fees don't fix that.

Sounds like IOUs which is basically fractional reserve banking and printing money out of thin air to make it work? Or would it be like a guaranteed one-to-one? Which sounds like Liquid Network in a way.

If we assume that there will also be N hops, and each of the N hops to support the N transactions, then doesn't everything cancel out in the end? Sure, a single hop that handles 10 transactions will replace the 1 on-chain transaction, but that's 1 hop. The other 9 hops also do the same thing, so in the end, 10 transactions require 10 on-chain channels (one channel per hop).

In the mining case, let's say there are 10000 participants in the pool. Then it needs to open 10000 channels. Now if the pool has a ton of BTC up front, maybe it can benefit, but it's pretty painful to create these giant channels for each participant up front. And a participant might disappear, in which case, you pay the closing fee and then maybe open a channel for a different participant. This "churn" of channels can become rapidly expensive.

Now if you say the mining pool doesn't need to open a channel to each participant, now the participants are stuck without inbound liquidity. They can buy it, but that's again, on-chain TXs for each one. And that step to buy liquidity is not exactly easy or cheap.

My 10m sats channel drains usually within 1 or 2 transactions. Sometimes 4m or 5m sats at a time. Most of the nodes that I'm connected to have channels way smaller than that, such as 500k or 200k sats channels. Are you sure the 10 hops can handle that many?