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.

Very interesting read, thanks for posting.