It turns out some pools are, without telling anyone, just acting as proxies for other pools.
This should scare you.
This should scare you very very much.
https://x.com/0xb10c/status/1780611768081121700
MEVil (or centralizing MEV) is one of the biggest threats to bitcoin’s value, but it’s poorly understood. I wrote about what it is (and isn’t) and how developers and bitcoiners must consider it carefully if we want bitcoin to survive.
Notably, we need to be incredibly careful when we’re looking at the new wave of bitcoin L2s - rollups can be incredibly nasty for the destruction of bitcoin - or not. Devs building these things have a responsibility to bitcoin, and the bitcoin community a responsibility to inform and avoid systems that risk bitcoin.
https://bluematt.bitcoin.ninja/2024/04/16/stop-calling-it-mev/
Just saw a “flashbots on bitcoin” pitch deck. I’ve never seen such a blatant and dangerous attack on bitcoin.
Make no mistake if this succeeds, and MEVil becomes a big thing on bitcoin, Bitcoin is doomed.
No, there’s enough value in these things it doesn’t matter if it’s discounted at the fee level or not, people would eventually have done it. The question is only if they do it carefully or not.
DEMAND is currently the only Sv2 pool. Ocean has said they want to add it eventually, but afaik don’t have a timeline.
But, more generally, go talk to miners! Explain why this is critical for bitcoin, and, thus, their business. Harass them on Twitter, make sure they hear it.
Mining is fairly decentralized already, transaction selection (ie the thing that matters for censorship resistance) is not (because it’s controlled by the pools). Moving that task from pools to the miners would make bitcoin a lot more censorship resistant.
It’s not perfect, something like P2Pool/BraidPool may be better, but it’s 95% there and pretty achieveable, getting miners to move to something totally different is a big ask.
I mean, in sum…. Not really. Industrial mining is just huge and you’d need a *lot* of Bitaxe to make a difference. You can attend your local meetup and try to find miners/pool operators and talk to them about the issues they’re creating though!
It’s time for miners to wake up and start migrating to Sv2.
Mining centralization is as bad as it’s ever been and the bullishness on bitcoin is totally unjustified given miners don’t seem to care about bitcoin in the slightest.
If it doesn’t get better nearly every PoS chain is literally going to be more decentralized and censorship resistant than bitcoin.
If you care about Bitcoin you are responsible for fixing this. Pressure miners.
You can attend your local meetup and/or me active on Twitter/nostr and try to find miners/pool operators and talk to them about the issues they’re creating though!
Yes I’m proposing simple outreach. There’s no reason miners want to avoid Sv2, so it’s really just a question of socially convincing them to do a bit of work to switch.
https://stratumprotocol.org/getting-started/ should get you going mining against DEMAND (the only pool that supports Sv2 today). If you have any issues please join the Sv2 discord!
Nah that’s just naive. Sure, economic incentive is some of the best pressure, but social pressure works too, especially when there’s no economic disincentive as with Sv2. Why are public large bitcoin miners not being harassed on Twitter to adopt tech that is good for Bitcoin?
DEMAND is currently the only Sv2 pool. Ocean has said they want to add it eventually, but afaik don’t have a timeline.
But, more generally, go talk to miners! Explain why this is critical for bitcoin, and, thus, their business. Harass them on Twitter, make sure they hear it.
Yes, that’s also why if “MEV comes to Bitcoin for real” we should probably give up on Bitcoin as a censorship resistant system (and, really, thus Bitcoin as a whole).
P2Pool did this a long time ago! More recently Bob Mcelrath has been working on reviving a variant of it using DAGs to increase the share chain block rate calling it BraidPool. I believe it’s still fairly early on.
They’ve contributed a lot to the design of it, but sadly they don’t yet allow you to select your own transactions when hashing. Only DEMAND allows that as of yet.
There’s a huge gap in the perception of self-driving cars between San Franciscans and everyone else. And it’s not because of the hype cycles that dominate SF tech - it’s because SF people replaced Uber with Waymo a year ago and haven’t looked back at the comparatively-terrible product of Uber.
Nah, almost all the cases people make a big deal of are actually cases where a human would have done the same, or worse. There’s a lot of people who like to scream in SF, very few for legitimate reasons. There’s obviously some teething issues with the tech, but overall it’s almost certainly better than your average Uber driver.
(Though Cruise’s tech is noticeably worse, they’ve had a *lot* more cases of definitely-their-fault accidents than Waymo, which has had vanishingly few). Sadly they get dumped into the same bucket.
Nostr is the only actually censorship resistant social network that exists today. Bluesky is working towards that but they’re quite a ways from it. That doesn’t mean they don’t have some great ideas that we should learn from, like how to do moderation.
I strongly disagree. Lightning hasn’t seen a fundamental overhaul, sure, but tons is iterative improvements have been made to address the largest user-facing issues.
Whether it’s better interop and bug fixing to (substantially) reduce spurious force closures, slicing to ensure liquidity fragmentation isn’t an issue, BOLT12 to provide stateless payment instructions and recipient privacy, anchors to address some pinning vulnerabilities and fee spikes preventing payments, etc, there’s been a ton of changes!
In net, spurious force-closures have probably dropped by 5-10x, surprise payment failures by 50% and a ton of other features.
Huh? The things I mention (except splicing) are broadly available and have been for several years!
In terms of “major improvements”, I’m not really sure what you’re looking for - lighting isn’t going to be rewritten to be a totally different system, liquidity constraints isn’t a solvable problem with lighting, and someone has to pay fees in channel transactions. If you want a fully trusted/custodial system you’re welcome to use one, but I’m not really sure how much different lightning can get. Do you have specific ideas or issues you have in mind here?
In terms of the personal attacks, I’m happy to respond to any specific points or cases you want to discuss but blanket ad hominem isn’t really a thing to respond to (and if you think I’ve told people they’re “wrong” about Lightning’s limitations, I dunno if you’ve been paying attention).
Ah, except BOLT12 as well, sorry about that. Though that solves fewer of the issues users complain about, except for static payment instructions, admittedly.
If I see someone talk about who might be satoshi, I lose all respect for them instantly. Ignore whether we should or shouldn’t, accusing someone of being satoshi puts them at very real physical risk.
There’s plenty of people who want to kidnap satoshi seeking some bitcoin. Don’t set someone up, you might actually get them killed.
For wallets wanting to get a head start on implementing human-readable bitcoin names, here’s a library that handles all the DNS parts!
* resolves against a local (/remote) TCP/53 resolver
* resolves against a DoH/DoT resolver
* creates/validates proofs
https://docs.rs/dnssec-prover/
It can even be run in WASM on a web page (and resolve via DoH directly)!
https://http-dns-prover.as397444.net
Default yes but servers MUST support both, for fallback :). When talking to an authoritative server, UDP is important, but when talking to a recursive resolver, who cares?
I strongly disagree. Lightning hasn’t seen a fundamental overhaul, sure, but tons is iterative improvements have been made to address the largest user-facing issues.
Whether it’s better interop and bug fixing to (substantially) reduce spurious force closures, slicing to ensure liquidity fragmentation isn’t an issue, BOLT12 to provide stateless payment instructions and recipient privacy, anchors to address some pinning vulnerabilities and fee spikes preventing payments, etc, there’s been a ton of changes!
In net, spurious force-closures have probably dropped by 5-10x, surprise payment failures by 50% and a ton of other features.
Notes by matt | export