pull down to refresh
Because, sure, in some specific mempool instances, cluster mempool will have more profitable transactions stored in the mempool than the naive approach. But how frequently does that happen in real life?
Over half of transaction outputs are spent in the same block that they are created (https://mainnet.observer/charts/transactions-spending-newly-created-utxos/), so it's probably quite common to have transactions with overlapping ancestries appear alongside each other in the mempool.
The main purpose of cluster mempool is to make more profitable block templates. Smarter eviction is just a beneficial side effect from applying the new method to both the top and bottom of your node's mempool.
On chain Bitcoin is slow, expensive, and isn't private. You can use coinjoins to transact on chain anonymously, but then it's even slower and even more expensive.
Lightning fixes all of this since it's fast, cheap, and private. But this layer introduces a new set of tradeoffs like requiring continuous Internet connectivity, channel liquidity management, and annoyances like force close timelocks.
One steelman argument for Ordinals being a BIP is that sats of certain "rarity" levels are awarded directly to miners. (Of course, all sats are directly awarded to miners, but follow me here...)
Since the choice to split & sell these sats marginally affects the profitability of miners who obtain them, it is worth documenting how they are identified.
As far as I know, they haven't marketed themselves as self-custodial. I asked one of the Citrea cofounders specifically about their "trust minimized" setup - https://x.com/Kruwed/status/2032221603568787501
F2pool currently only mines transactions that pay at least 0.3 sat/vbyte.
Similarly, ViaBTC only mines transactions that pay at least 1 sat/vbyte.
You put Bitcoin & stablecoins in the same category: https://x.com/MattAhlborg/status/2028831326783049903
A long time ago, I commissioned a Core developer to draft the code change to disable assumevalid by default: https://github.com/bitcoin/bitcoin/commits/8d9e5060559c6b501fedac362aa4efc7d2dbd726/
I used v0.2.0 with a test key for a 1 on 1 chat and it worked smoothly. I didn't run it enough to notice battery drain though.
I don't think assumevalid should be enabled by default. AssumeUTXO is a more performant tradeoff if you are willing to sacrifice trust.
That’s why the 15% difficulty jump is more important than any court ruling today
So why didn't you title your post "Bitcoin's mining difficulty jumps 15%" instead of "6-3 Decision: Even the Supreme Court knows Fiat Power needs limits. Bitcoin wins"?
Stop talking, start doing.
Sure. You can specify the exact amount and address for a payment you want to make and that will be added as an output in your next coinjoin transaction. This lets you easily fund your cold storage or Lightning wallet with the exact size UXTOs you prefer.
There are several advantages from sending payments directly inside a coinjoin:
- The age of your inputs is not revealed, so the receiver does not learn how long you held (and thus, your profits/losses)
- The size of your change is not revealed, so the receiver does not learn how many coins you have left over
- You can batch multiple payments into one transaction without revealing they originate from the same sender
Damn, I didn't want to spoil the surprise but... UI support for sending payments directly inside coinjoin transactions has recently been merged to Wasabi. It's an incredibly overpowered feature that solves all of your UX issues & privacy concerns (while also improving block space efficiency).
Bullish on privacy.
Cross Input Signature Aggregation is underrated. Make coinjoins look less like clown cars and more like buses.