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.
3/ P2TR inputs are more blockspace efficient than the hash-based output types (P2PKH, P2SH, P2WPKH, and P2WSH), as P2TR saves the space needed to reveal the hash preimage and can be unlocked with only a signature in the input.
4/ P2TR (native segwit v1) but will be the first output type that uses the `bech32m` address encoding, an updated version of bech32 which was used for P2WPKH and P2WSH (native segwit v0).
5/ While the previous output types used the Elliptic Curve Digital Signing Algorithm (ECDSA), P2TR uses the Schnorr signatures.
Schnorr signatures use a more compact serialization format, making them smaller than ECDSA signatures.
6/ The Schnorr signing algorithm is linear, meaning that multiple signatures for the same message can be aggregated into a single signature. Also, public keys and their signatures can be tweaked with scalars. This allows a number of nifty tricks…
7/ _Key aggregation_
The linearity allows us to aggregate multiple public keys into one public key, e.g. via MuSig2. When funds received to such an address are spent, the use of multisig is indistinguishable from regular single-sig use.
8/ _Adaptor signatures (AS)_
AS or scriptless scripts encode script-like behavior directly into public keys by tweaking them with other data. AS can be used to create Discreet Log Contracts and coinswaps that look like regular transactions to uninvolved. bitcoinops.org/en/topics/adap…
9/ _Taproot_
We'll put a single public key into a locking script but commit to both a public key and a Taptree. The UTXO can be spent _either_ via the `keypath` or via any leaf in the Taptree via the `scriptpath`.
10/ The leaves in the Taptree will use a new subset of Script, `Tapscript`. Tapscript removes a number of opcodes and replaces `OP_CHECKMULTISIG` with `OP_CHECKSIGADD`. Tapscript is compatible with Miniscript simplifying smart contract development. bitcoin.sipa.be/miniscript/
11/ _PTLCs_
Point Time Locked Contracts use an Adaptor Signature construction to replace the HTLCs currently used by Lightning network. They use less blockspace and cannot be correlated on-chain when channels close while payments are on-flight. suredbits.com/payment-points…
12/ Not included: Cross Input Signature Aggregation (CISA/XISA), a feature that allows multiple inputs on one transaction to share a single signature will not be shipped. Every input still needs its own signature! bitcoin.stackexchange.com/q/106224/5406
13/ Not included: `SIGHASH_ANYPREVOUT`, a new mode of spending inputs that lets signatures commit to a specific locking script rather than a specific UTXO. Required to roll out ELTOO, a new channel update protocol to replace LN-penalty. anyprevout.xyz
14/ Not included: Entroot, a generalization of Taproot and Graftroot where every output always requires a signature and satisfying a script. This construction is useful to arbitrarily combine various script structures and for delegating funds. gist.github.com/sipa/ca1502f84…
15/ I've also seen multiple claims that "Taproot will solve Bitcoin's scalability issue".—Taproot will only slightly increase the transaction throughput, mostly by reducing the size of multisig transactions.
16/ Altogether, we get:
• Better privacy
• Cheaper multisig
• Single-sig and multisig will be mostly indistinguishable
• Lightning improvements: PTLCs and aggregate keys as channel anchors
• A boost for scripting with DLCs, Adaptor Signatures, and Taptrees
17/17:
If you have questions or corrections, let me know!
PS: Eat more taproots.
18/17 Addendum 1: Not included: covenants. Taproot does not include any mechanisms to restrict the destinations outputs can be spent to.
19/17: Correction on Tapscript:
Tapscript disables exactly two opcodes, `OP_CHECKMULTISIG` and `OP_CHECKMULTISIGVERIFY`, redefines disabled opcodes to `OP_SUCCESS`, and introduces `OP_CHECKSIGADD`.
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…
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.
3/ Given the low blockspace demand and about 20% more blocks than the past two weeks, there is a chance that we see the mempool clear completely in the coming difficulty period for the first time since December 15th, …
@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.
@Mario_Gibney 3/ We can calculate the chance of finding one or more blocks in a time interval by starting with 100% and deducting the chance of finding 0 blocks. The chance to find 0 blocks in a time frame where we'd expect λ blocks is `p(0|λ) = exp(-λ)*(λ^0)/(0!) = exp(-λ)*1/1 = exp(-λ)`.
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!
2) Consolidate deposits
You're still getting tons of deposits and have to perform withdrawals. By funding withdrawals only with bigger UTXOs and consolidating smaller UTXOs at a lower feerate than your withdrawal transactions, you can save a ton of fees. 3/
@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.
@CryptoStorm3@ChartsBtc Especially, when the price makes big swings, people get excited and want to participate in the market. As a precept in Bitcoin is to be your own bank and control your funds directly, a lot of people do not keep funds on their exchange accounts but in their own wallets.
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…
… could at least serve as a valve for some smaller payments even when Wumbo seems a bit daunting still.
If you aren't working on all of these, you might want to consider to.
@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 b) Significant count of FN support protocol change. FN topology decouples, some Scrutinizing Thin Clients (STC) are eclipsed by attack. STC will at the latest fully validate the first block that includes any transaction that concerns them. 1) Discovers invalid block if rule...