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:

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.

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’.

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).

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”.

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​

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.

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):

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: A 2MB hardfork is a capacity increase but not a scalability improvement. Segregated Witness is a capacity increase and a scalability improvement. 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.

The Lightning network is not a sidechain. A sidechain relies on its own blockchain which is coupled to the Bitcoin blockchain via a two-way peg. On the other hand, the Lightning Network consists of native Bitcoin 2-of-2 multisig transactions. When two Lightning nodes open a payment channel, they both send funds to one multisig address and each provides the counterparty with a pre-signed exit transaction. If a party wants to resolve the payment channel, they can unilaterally add their own (the second) signature and send the transaction to the Bitcoin network for confirmation.