Let’s talk about Cluster Mempool!

🧵1/X 2/ Each of our full nodes stores unconfirmed transactions in its mempool. This cache is an important resource for the node and enables the p2p transaction relay network. By learning about and validating most transactions before a block is announced, blocks relay quickly.

GM,

A 🧵 on node behavior concerning data:
1/16: All full nodes process the entire blockchain and keep a complete copy of the UTXO set. The UTXO set contains the current state of the Bitcoin ledger and is necessary to validate transactions or build blocks. 2/16: Many full nodes keep a complete copy of the blockchain. They may also keep a transaction index (-txindex=1). These "full-archive nodes" can help new nodes bootstrap by serving historic blocks which they announce with the `NODE_NETWORK` service flag.

P2SH-P2WPKH (single-sig wrapped segwit) became the most common input type in October last year, superseding P2PKH (legacy). P2WPKH (single-sig native segwit v0) was already tight on its heels. P2WPKH caught up with P2SH-P2WPKH in November.

So, I guess it's time to do a #mempoolreport. On 2022-05-11, just after just before 17:00Z, Binance started dumping about 100 blocks worth of consolidation transactions into the mempool.
Other than the usual approach, where consolidations are fed to the lower end of the mempool… they instead submitted the whole hot mess at fixed fee amounts of 200,000 ṩ per transaction. At exactly 100 P2PKH inputs and one P2WPKH output (to bc1qm34lsc65zpw79lxes69zkqmk6ee3ewf0j77s3h) the feerate works out to just short of 14 ṩ/vB for each transaction.

🧵I've been seeing a few comments lately that blockweight is an ugly hack, the witness discount was a mistake, and that the blocksize increase was unnecessary. A few thoughts.👇 Segwit was a bug fix, an efficiency improvement, and a blocksize increase. Economic incentives drive segwit adoption. Blocks have been mostly bigger than 1 MB since end of 2018.

via transactionfee.info/charts/block-s…; 2017–today; 7d, 30d, 100d averages; 1 MB line added by hand.👇

It's been a while since I asked. Were there any updates on bech32m/P2TR readiness that I missed? #bech32msupport, #P2TRsupport

Software wallets, hardware signers, web wallets, ATMs,… …exchanges, payment processors, libraries,…

1/ It's not only about RPis at home. A 10 s block interval would mean that block propagation and block validation take a significant chunk of the interval.
You'd get blockchain forks abound, poor block relay because of many competing chaintips, bad network convergence,…

https://twitter.com/vladtenev/status/1514684181468495880

2/ … large miners would be hugely advantaged by being able to build on top of their own block immediately instead of needing to wait to receive foreign blocks, which causes mining centralization and supercharges selfish mining.

@achow101, @glozow, and I have been scrutinizing the Bitcoin Core wallet coin selection lately. We have multiple ideas for improvements, but we have very little usage data to evaluate them. So far, we have one scenario generated from a service's data.
We're looking for… • people living on Bitcoin
• Bitcoin power users
• fervent sat stackers
• services

that would be willing to share payment history (from any wallet) with us.
We're looking for large sequences of `{±amount, feerate}`. Amounts can be slightly altered or rounded for privacy.

As people were getting ready to get married on the beach, a brief discussion of economic incentives of cross-input signature aggregation (CISA) led to an interesting comment (H/T @n1ckler) that made me rethink my characterization of its potential cost savings. 🧵/9 CISA refers to the idea of multiple inputs on a single transaction sharing a single signature. This is possible due to all signatures committing to the same message (i.e. to all outputs via `SIGHASH_DEFAULT`) and the signing algorithm's linearity. 2/9 bitcoin.stackexchange.com/a/107068/5406

"bits" is a horrible name for a subunit of bitcoin. I'll die in that hill.

https://twitter.com/Mario_Gibney/status/1160761554016411649

🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕
🥕🥕🥕🥕🥕TAPROOT IS LIVE🥕🥕🥕🥕🥕
🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕🥕

https://twitter.com/murchandamus/status/1459747322590543873

First Taproot transactions are in block 709635:

⛏️🟩🟩🟩🟩🟩🥕
LFG ⛏️🟩🟩🟩🟩🥕

Last night, Bitcoin's difficulty went down by 27.94%.
But what is difficulty in the first place?
🧵1/19: 2/19: Difficulty is a measure of the expected hashing work the Bitcoin network will perform for each valid block it finds.

The difficulty is a crucial value in Bitcoin's consensus process: we cannot have some nodes accept blocks that other nodes reject.

Let's talk about Taproot🥕!
I'll cover
• New features enabled by Taproot
• Things not included in Taproot

🧵1/X 2/ Taproot introduces a new output type called Pay to Taproot (P2TR). P2TR is similar to Pay to Public Key (P2PK), in that outputs lock funds directly to a public key rather than the hash of a key or script.

(See more here: learnmeabitcoin.com/technical/p2pk vs learnmeabitcoin.com/technical/p2pkh.)

1/ Time to catch up!
The mempool cleared 6+ sat/vB multiple times this week. This morning, 4 sat/vB can get you in the next block. Expect to see lots of single-digit feerates in the coming weeks!

Why?—Blockspace demand has tuned back with the recent price drop…

#mempoolreport 2/ …even though the recent miner migration has reduced the network's hashrate to less than 130 EH/s—brutally undershooting the difficulty equivalent of 179 EH/s.
In addition to the low blockspace demand, we are expecting a difficulty adjustment of about –16% in 59 blocks.

@Mario_Gibney 1/ Yeah, lemme try to draw it out. Let's assume it takes 6s for a block to reach other miners and compare 60s vs 600s block intervals for miners with 5% vs 30% of the hashrate. 6s is roughly the situation after Compact Blocks: dsn.kastel.kit.edu bitcoin/#propagation @Mario_Gibney 2/ The propagation delay is both an advantage and disadvantage: it gives the author a headstart for the next block, but also gives time for a competing block to emerge which may oust the author's block. Let's assume half the remaining HR works on the competing block.

Default mempools purging txs < 6.0 sat/vB.

Since a full mempool seems to be the new normal, at least temporarily. What can _businesses_ do to lower their operation costs?

The following is mostly picked from blog.bitgo.com/utxo-managemen… if you prefer long form.

#mempoolreport

1/ 1) Batch payments
You get a lot of withdrawal requests? Instead of paying each out separately, save up to 80% in fees by batching multiple payments into one transaction. It also makes UTXO management much easier!

bitcointechtalk.com/saving-up-to-8… 2/

@CryptoStorm3 @ChartsBtc Each transaction offers miners a small amount of bitcoins to incentivize confirmation. Blocks are limited to 4M weight units, so miners cannot include everything that is waiting. Naturally, they choose the transactions that pay the highest fee per weight unit to maximize revenue. @CryptoStorm3 @ChartsBtc Since a block is limited in size, and the block interval self-regulates to be roughly constant, the throughput of transaction data is limited.
OTOH, the amount of transactions that get submitted to the network is flexible.

Mempool depth is still on the rise with all fee bands growing. If we were headed into a major fee event, the #btc ecosystem would be much better prepared than in 2017. Native segwit is on the verge of wide adoption, opt-in RBF is right there for anyone that wants thrifty quick confirmations, LN maturity is coming along nicely, which…

@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt Alright, so our threat model is a widespread effort to change the protocol rules with support of a majority hashing attack. Presumably this is incompatible with existing network rules as enforced by fully validating nodes, but compatible with thin clients. @giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt a) A vast majority of FN oppose this protocol change. Attackers are banned by their peers, blocks don't propagate, most thin clients never see the blocks. Affected scrutinizing thin client discovers changed rules when first valid block is found, if it has at least 1 honest peer.

@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt Maybe I'm missing something, but current thin client implementations either rely on a trusted server or connect to multiple nodes. So, you'd not only need to be served a fake block, but also get verification by other nodes to follow it. That means you need to be sybilled. @giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt BIP157 done right would first gather multiple filter fingerprints and compare them, then download the full filter if they agree. If they disagree, the would need to be back-off validation procedures. I don't see why such a validation couldn't include parsing the full block.