Murch ado about nothing

On the Lack of Replay Protection

What is happening?

Around August 8th, 2026 at block height 961,632, BIP110: Reduced Data Temporary Softfork (RDTS) nodes are going to start enforcing mandatory signaling for their unpopular softfork. As RDTS is supported by less than one percent of the hashrate, Bitcoin miners will likely find dozens of blocks before an RDTS miner finds the first signaling block. RDTS nodes will reject the first non-signaling block which will cause a blockchain fork as they relegate themselves to a stunted chaintip extending about one block per day.

What is the Waste Metric?

Coin Selection

Funds are tracked in discrete portions, so called Unspent Transaction Outputs (see UTXO model). Generally, a wallet’s funds are split across multiple to numerous such UTXOs. When a user sends a transaction, their wallet software needs to pick some of their UTXOs to fund the transaction. The process of picking the input set of a transaction is referred to as Coin Selection.

The primary goal of Coin Selection is to raise sufficient funds to pay for the recipient outputs and fees of the transaction, but there are secondary goals as well:

A breakdown of different output types and their address formats

I was inspired by a recent reddit post to write my own description of the various single-sig output formats in Bitcoin. I’ll be covering only output types that make use of a single signature.

“Legacy Outputs” aka P2PKH

Pay to Public Key Hash was the first output type that got an address standard. Addresses for P2PKH outputs start with “1” and use the Base58Check encoding. The address encoding provides a checksum and represents a shorthand to communicate recipient information—which improved the UX over the prior situation which required the sender to handle the recipient’s full public key or non-standard output script to send a transaction.

2-of-3 inputs using Pay-to-Taproot

This article was originally published on my medium page on 2020-08-18.
This article was amended on 2020–12–20 to improve the description of the P2TR output scripts. Thanks to Matthew Zipkin, for pointing out the prior imprecision.

The Bitcoin community has been abuzz for a few years about bringing Schnorr signatures to Bitcoin. Since then, the idea has evolved into three formal Bitcoin Improvement Proposals: ‘BIP340 — Schnorr Signatures for secp256k1’, ‘BIP341 — Taproot: SegWit version 1 spending rules’, and ‘BIP342 — Validation of Taproot Scripts’. Respectively, they define a standard for Schnorr signatures in Bitcoin, introduce the Taproot construction, and formalize the new Script v1 instruction set. Taproot also iterates on the previous proposal of Merklized Alternative Script Trees (MAST).

Excited for Schnorr signatures

This article was originally published on my medium page and hackernoon on 2018-02-03.

If you’re keeping a finger on the pulse of Bitcoin development, you’ve probably already heard about Schnorr signatures and you probably won’t find much new here. You might rather want to check out Pieter Wuille’s recent talk at BPASE18, or Bryan Bishop’s compilation of transcripts of Schnorr signature talks whom this article heavily leans on.

Bitcoin signatures are created using the Elliptic Curve Digital Signing Algorithm (ECDSA). Schnorr signatures are another form of digital signatures. The signatures are based on the same security assumptions as ECDSA and are compatible with the elliptic curve Bitcoin already uses (secp256k1). This means that Schnorr signatures can be created with the same private keys and are compatible with currently used key derivation schemes.

A look at an early LN testnet topology

This article originally appeared on my medium site on 2017-12-29.

Let’s take a look together.

A commenter on my Fyookball response: ‘This [tweeted image] shows a lot of centralization around hubs’

We see about ten “supernodes” that stick out by having a lot of channels. We also see that there are some smaller nodes that form channels exclusively with these supernodes. I assume this is what you’re referring to, when you decry “centralization around hubs”.

PSA: Wrong fee rates on block explorers

This article originally appeared on my medium page on 2017-12-12.
Update: Blockchair.com, BTC.com and Smartbit.com.au have corrected their fee rates since my article. Thank you!

We’ve been getting support requests from customers inquiring why their transaction’s fee rate is not matching the parameters they set.

The problem is that popular blockchain explorers don’t get the fee rate right. Let’s look at the following transaction with two P2SH-P2WSH multisig inputs and six outputs: c​d​e​e​a​0​d​6​c​3​7​a​0​4​6​d​5​b​7​e​1​3​a​7​5​b​c​0​c​9​8​4​2​4​9​3​f​4​1​d​d​5​a​9​7​d​2​4​8​d​f​4​3​5​5​2​a​d​9​e​1​5​c​8​

Some subsidiary points on Lightning Network

This article first appeared on my medium page on 2017-06-29.

I was pondering whether it is a good use of my time to respond a second time to Jonald Fyookball. Since the new article mostly repackages the same misunderstandings, I have decided to only provide some subsidiary information.

Who performs the Routing in Lightning Network?

When a node in Lightning Network wants to initiate a payment the sender picks every hop of the route. To that end, they use “Onion routing” — they construct a packet much like a prank christmas present from your older brother: a multitude of ever smaller boxes, until it is finally revealed that it’s just a pair of alpaca socks.

Responding to Jonald Fyookball's article on "Lightning Network's Infeasibility"

This article was originally published on my medium page on 2017-06-27.

I have just read Jonald Fyookball’s article which claims to provide mathematical proof that the Lightning Network will fail to provide a ‘Decentralized Bitcoin Scaling Solution’.

It starts with a short description of single hop and multihop payments. After that it asserts that it will be infeasible to scale such a network topology to a any significant size.

Before exploring the details, the author already knows what the topology of the Lightning Network will look like (image from the article):

Capacity vs Scalability

Let’s talk about terminology.

Capacity: The number of transactions that can be processed on the network.

Scalability: Capability of the network to handle a growing amount of work.

Examples:

  1. A 2MB hardfork is a capacity increase but not a scalability improvement.
  2. Segregated Witness is a capacity increase and a scalability improvement.
  3. Monero has no block size limit and thus a higher capacity than Bitcoin, however its TXO pool is unpruneable, its blockchain would grow faster at same usage, and its transactions take more computational effort to validate, so it doesn’t scale as well as Bitcoin.