Trust Models (refer back to this when someone claims their thing is “non-custodial”, note that privacy is a different spectrum) * Holding Funds On Chain * Trusting you can get a transaction confirmed in some time horizon where your balance is way higher than the on chain cost (LN) * Trusting you can get a tree of many transaction confirmed in some time horizon where your balance is way higher than the on chain cost of the whole tree (in-round Ark for high-ish balances, rollups for *very* high balances after some future soft-fork) ^ non-custodial v custodial * Trusting you can get a tree of transactions confirmed in some time horizon where your balance is similar to the on chain cost (in-round Ark for moderate balances, rollups for most folks after some future soft fork) * Trusting 1-of-N with keys (rollups with BitVM) * Trusting N-of-M to do something honestly once in a TEE (statechains maybe?) * Trusting N-of-M to do something honestly once (statechains/statechains-on-Ark) * Trusting N-of-M with keys (Liquid, Fedimint) * Trusting 1 entity with keys (Cashu, Coinbase, …)

This isn’t specific to BOLT 12 and is really stretching the line on accuracy. Yes, if you reuse a BOLT 12 across two companies they can compare notes and see that you used the same one (duh!), but it’s not “because you reuse the same public key”, it’s because it’s the same thing! But, of course, you don’t *have * to do this. Wallets, by default, should generate a fresh BOLT 12 every time they display the receive key (and LDK will every time the wallet asks for a BOLT 12), including fetching a different “offer_issuer_id”. Ultimately, don’t assume things just based on the name of a field in a spec - the “offer_issuer_id” is a misnomer, LDK actually has a different name for it because of this, and IIRC the spec even says don’t reuse it if you’re a regular end-user wallet! View quoted note →

What dimension am I in?

Before Bitcoin makes any decisions on protocol extensions that might increase the risk of MEVil, we all need to get comfortable with this being how mining works in the future (and have some confidence we can get her, rather than where ethereum is). View quoted note →

If more complicated protocols become a major part of bitcoin's transactions, what the resulting MEVil looks like in practice is something we should all be clear about. @7d5x9 (from Twitter) and I sat down and wrote about the best (bad) solution we'd have if MEVil becomes big. In that world, complicated transaction construction algorithms would put immense pressure on mining centralization which, left to develop on their own, would drive horrible outcomes for Bitcoin. Instead, we propose the best idea we have - containing the damage to as small an area as possible by allowing the MEV(il) extractors to only bid for a small part of blockspace, leaving miners to pull from the public mempool for the rest. (It also enables more competition between MEV(il) extractors than ethereum's PBS by splitting the block space market into many smaller markets on a per-contract basis). It still represents a dramatic increase in centralization in the mining world, with marketplace centralization potentially allowing for exclusion of certain miners, but its way better than letting MEVil play out naturally.

GitHub

mevpool/mevpool-marketplace.md at main · mevpool/mevpool

Contribute to mevpool/mevpool development by creating an account on GitHub.

Big day for long form writing for me today. Phew.

Over the past few years Bitcoiners went from dismissing Lightning to cheering on custodial solutions. While many of those solutions have great properties and make sense for low-balance wallets, we shouldn’t lose sight of the goal - great non-custodial UX that Bitcoiners actually *want* to use. Luckily we have the tech for it (now), we just need the motivation and resources to build great wallets using it!

Custodial Solutions Are Not Solutions

Our own Matt Corallo gets to the core of what makes bitcoin everything that it is: self-custody. Without it, bitcoin is just another form of fiat.