Still, it's different if one custodian gets popped, and people who (maybe unknowingly) accepted the custodian risk, or if the entire security basis of the entire Bitcoin ecosystem is broken. Coinbase isn't high impact, it's not the entire ecosystem.

"... because it would affect their own encryption...", another fallacy: appeal to rationality. He's assuming that there aren't powerful entities that either don't grasp or just don't care about the fallout.

Well, it is also a very human thing to obsess around these catastrophic events. See the fear of airplane crashes vs car crashes, one gets all the attention while the other is the actual killer.

That's what we call a low-probability / high impact event: quantum computers are unlikely to become powerful enough to steal coins in the next couple of years, but if they do, almost all coins are at risk. Comparing that to a high probability / low impact (comparatively) Event like an individual users coins being stolen makes little sense. This is called fallacy of relative privation, and relies on the inability to correctly gauge the impact of low probability events.

Vibe manager if I ever saw one...

Well, what did we expect when we deregulated everything? Governments and regulation are there to reign in the excesses of free markets (they literally are the only thing preventing monopolies long term), so if we deregulate we allow abusive and extractive behavior. And abusers get used to it and block any move in the other direction

Eventually the pendulum will swing back.

Too bad it had to be a memecoin (is it still a memecoin when er get utility from it's use?), but it's about time we disintermediated the cartel of scientific publishers. I hope this makes a dent into the Springers margin, ideally we'd set it up to compensate authors and reviewers for their hard work, rather than the legacy paper transport system for information.

Ugh, I see the banner with the Keynote speakers and I want to throw up...

Cool, doxxing developer financials as an incredibly inefficient method to control spam, that's what Bitcoin is all about /s

Oh, and guess why the fees went up after the block mined by ocean: because it was not full, we wasted available capacity, kept the mempool full, and disoriented fee estimators...

So the transactions were not mined when there was spare capacity, the block was not fully utilized and the transactions linger in memory because other miners deemed them too low fee? Nothing here singles out ocean as a positive: they wasted block capacity, the lingering transaction will likely eventually still confirm, and in the meantime they float in the mempool and waste cycles of other miners trying to build a block template.

Ocean behaves just like any normal miner, foregoing transactions it doesn't seem valuable. It's only their cost function is changed, which in a distributed system may cause unexpected effects (heterogenous policies as an attack vector is quite common).

Quick tip: if you ever used lightning then you actually used time locked coins 😉

Hm, I can't find the spec verbiage, but here's the discussion from 6y back: https://github.com/lightning/bolts/pull/503#discussion_r232644170

The spec proposal does suggest keeping the fee schedules of parallel channels aligned, but there is no requirement of that. The discussion on what to return errors for is quite interesting and touches the points you mentioned in the OP.

A couple of things here: it sounds like managej collapses the multigraph into a simple graph, coalescing parallel edges. That'd explain why witnessing balance on one also causes the other to be used. Secondly you point out correctly that the forwarding node may chose to use another channel (the scid now is more of an alias for the remote node, rather than being used as a channel identifier), however the spec also mandates that the forwarding node must use the specified scid when returning an error, which is the confusion you are facing here. That forwarding node is not spec compliant.

That's a cute idea, and reminds me about the design of gossip in the lightning spec where some results would be delivered in zip format. We had thought about the decompression bomb (mandating a non-vulnerable library that you can provide a buffer limit to, rather than just firing and forgetting), but we later deprecated the compressed response since few implementations could provide such a secure variant without implementing it themselves, so few Impls ever supported it.

Thanks @BitcoinErrorLog, it's easy to feel victimized and look for an overly powerful enemy to justify our own shortcomings. Maybe blaming these windmills less means we can work on our faults, and build a better ecosystem overall.