While the meme might have a point I cannot take arguments such as these seriously. I interpret them as calls for ignorance or disinformation, both of which are pretty high up on my evil-scale. A lot of things are seemingly arbitrarily set, but not knowing about how they are set is seldom to your advantage. Perhaps you mean well, but I just don't see it...

The discussion is at #1265553 and I urge you to participate there with your interesting perspectives.

Indeed. Actively striving towards compliance means to willingly participate in that game. Running a mint (pseudo-)anonymously out of spite, or because one thinks it right, and taking the accompanied risk is something else.

This. I think the question of whether running a mint is breaking the law is interesting and relevant. Not because I'd shut mine down (if I were running one) if it were, but because it's better to be informed about what you are doing rather than being mistaken. If it is likely that running a mint is indeed illegal, telling plebs that it isn't can only backfire.

Although I still do not want to hazard a guess, the question did cause more curiosity to arise. I came to think about the implications of having a system for local filtering what one stores and not having one. IANAL and I do not keep up with legal developments around the world - or at all really -, but the Compuserve case came to mind (think it was Compuserve?). Anyway, the point from that thing was that there seems to be different culpability scenarios depending on if there are attempts to filter, where not attempting to filter seems to be the better choice - on the local level. I'm mostly thinking about filtering what is permanently stored. Changing the rules for everyone to make it harder to publish junk is still a good idea.

Not really. From my vantage point there seems to be nothing positive in it for the "Knots-side". I think, to hazard a guess one would need to have some understanding of the target audiences here - for which I have none... To me it simply does not make much sense. Perhaps needless to say, I'm impressed by neither the new relaying defaults nor core's ability to make it harder to spam the blockchain.

Yeah, the potential double-spending issue is interesting. But so is the apparent clumsiness of the proposal - and the path that has lead here. Whatever game theoretic play the spam team is playing it's obviously working.

I love your shill of this on nostr: "Ready to run Bitcoin Core v30 and make the knotzis go wild?". (https://primal.net/e/nevent1qqs2mzrcxv0mveykdr6s0zz3g0wf5yhrvrt02f63x4jx2t7ejscuthsrrqur8) I do wonder. Is it sensible to recommend running a just released version?

Thanks, @Scoresby! :)

I think a couple of things raises questions, in addition to the BIP giving the impression of being hastily written and not thought through. Like:

I also wonder about the implications of future developments. Like, say a node runs this BIP, and we get a new versions of tapleaf or segwit. What will happen to these nodes assuming they do not upgrade the node software they are running?

Disclosure: I am unfortunately not funded by any side of the spam "war", and so am just trying to understand what to do to avoid shooting myself in the foot.

Cool stuff! Never heard of bootc linux distros before. Gonna check it out for sure. Using Gentoo as my daily driver for more than a decade, so am not likely to change any time soon. But always fun to check out new seemingly sensible tech!

Some of these are really funny. Like getting diskfilled by the log. That's hilarious! I guess the most severe one is "CVE-2025-46598 - CPU DoS from unconfirmed transaction processing"...

1 sat = 1 sat! :D The fees are in ppm. So, for an 1M channel you get (1e6 * f_ppm + n * f_base) in fees (ish - excluding reserves etc.), regardless of the fiat price of bitcoin (n is the tx count). If f_base is zero then the count of transactions doesn't matter unless you're on an edge and can do rounding to your benefit. So, you earn more in fiat terms but not in sat terms.

You can see your outgoing liquidity in RTL, for instance. I don't use LND, so can't really help out with the technical details.

From the perspective of the ROI (fees) of the funds allocated to the channel size and its life cycle its not relevant. Everything is measured it sats. The transaction count only matters if you have a significant base fee set...

So, what I'd look at is the cost of opening and closing the channel, and contrast that to what fees you think you can set. The more you fund the channel you open with the less fees you can charge while aiming to break even. If your channel isn't used a lot, your channel may be closed as soon as your remote has a large enough amount of sats on their side that they judge could be used better (unless you have some agreement). So, you might perhaps estimate that only half of your liquidity will be pushed out. Fiat price has not much to do with anything here. That only comes into play when you want incoming liquidity for receiving payments for something you sell.

Sandbox, sandbox, sandbox. I've run my browser firejailed for years, even though I don't use any agentic stuff - just in case. I use Firefox these days, compiled from source and without AI stuff, but still think it's a good idea to sandbox it. But anyway, sandboxing AI seems to be a good idea - as clearly demonstrated by the dev community with its npm hacks and IDE agents that has the potential to wreck your system.

No. Increments in outgoing liquidity (plus on-chain funds) - assuming that you do not add/remove funds yourself. Your earned fees may actually increase at the same time as your outgoing liquidity decreases. This situation may arise during circular payments, for instance - perhaps depending on implementation and circular payment method. I've run a lightning node for some time, and while I have accumulated fees I definitely operate it at a loss. My motivation for running it is however not to be profitable (in sat terms).

What is more interesting to measure is your gains. Every other metric can be gamed. Afaik circular payments add to both routed sats and fees, for instance.

Neither do you, as I gather, because then you would give me a condensed explanation with links to technical KISS-sources instead of more commercial shill. And this isn't relevant anyway for your CGT-escape claim. In addition, liquid is not trust-less. You trust Blockstream and the federation (who mine your liquid txs). So, if you wanna commerce-talk it's "trust-minimized" at best. Still, I think that "Withdrawing USDT to a self-custodial wallet via Liquid breaks chain analysis." is an ill-informed claim.

You might be onto something here, but I think you main point is wrong. The USDT is likely tracked all the way. Even USDT on the Liquid network is freezable, and it is likely known who owns what USDT. When you buy L-BTC for it then all records needed for taxation is most probably available. What you can do after that with confidential txs is more unclear. Maybe you can decouple the coins from your identity - I don't have a deep understanding of how confidential txs work, and also do not know what data the liquid federation can keep and keeps behind the scenes - if any. That nostr link is just the same shill as stated above btw. Not being a hive-minded-vibe-drone I need more. I appreciate your reply though - costing your time and 1 sat and all.

This is a strong claim. May I bother you for a link to a lengthier elaboration/analysis of concrete implementations of this scenario?