Speedrunning the Bitcoin ecosystem: the post-SegWit innovation cycle
SegWit to Taproot. Lightning Network, and some notes on Ordinals, BRC20, and Runes.
SegWit → Taproot
SegWit is an upgrade to segregate witness data (digital signature) from transaction, and have it appended at the end of the block in form of a compact root signature representing each transaction (75% smaller in size, freeing up block space).
Taproot utilizes this new witness data from the previous SegWit upgrade to enable Schnorr schemes (allows aggregated signatures and multisigs, while maintaining constant data size), which in turn paves the way for the Lightning Network.
Further reading: https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer
Taproot effect: comparing ECDSA vs Schnorr signature schemes
Onchain multisig structure: multiple public keys (signers are revealed onchain) vs one public key (signers are hidden — onchain only shows one public key signing a transaction);
Key-pair programmability: non-linear (adapting keys like to encrypt/decrypt is hard — involves complicated math prone to errors) vs linear (adapting keys is a matter of simple addition/subtraction). In Schnorr, when you add the same thing to both public and private key, they will still be a valid key pair: when you “tweak” a Schnorr public key with a Merkle root (add that Merkle root to the public key), then you can simply add the Merkle root to the original private key and generate the spending key for the new tweaked public key.
The ability to commit to different spending scripts in a Merkle tree and only reveal the used script is a massive scalability win in terms of smart contract complexity that is possible to build on Bitcoin. This is how the Taproot upgrade paves the way for Lightning Network: all of the non-cooperative clauses in a Lightning channel such as penalty keys, or timelocks to allow them to be used, can be buried under a MAST with Taproot.
Examples of Taproot-enabled primitives
PSBT (partially signed bitcoin transactions): allows multiple parties to construct a conditional transaction and combine signatures for it offchain, before one party aggregates the received signatures and send the transaction onchain. Since signatures only represent authorization of a transaction under a specific condition that the signer has agreed to, the broadcaster can’t just arbitrarily modify the broadcasted transaction: the aggregated signatures will become gibberish, and the transaction won’t get broadcasted onchain. For example: a trade where bc123 signs for “send 1 BTC to bcABC if bcABC sends 1000 ORDI to bc123”, bcABC takes bc123’s signature and adds their own “send 1000 ORDI to bc123 if bc123 send 1 BTC to bcABC” signature, and then combine both signatures together to finally broadcast this PSBT onchain (where it’d be represented as a single Script, to be executed atomically by miners upon inclusion).
DLC (discreet locked contracts): allows an oracle to act as the third-party in 2-of-2 multisigs — event triggers are agreed upon and laid down in prior, and in the future, the oracle’s public key will send its signature to the DLC, indicating for an event from the list (and allowing the party associated with the backed event to claim the multisig funds).
An example use case is Liquidium, a peer-to-peer Bitcoin lending dApp. It utilizes PSBT to construct the lending DLC Script in the first place (involving lender and borrower), where its oracle will feed an event trigger into this onchain 2-of-2 multisig to determine the outcome (if the oracle feeds “borrower has paid 2 BTC” event, the borrower can then claim the Ordinal NFT within this 2-of-2 multisig; if no event is emitted until the multisig’s HTLC expiry date, the lender can then claim the Ordinal NFT).
Caveat: the trust lies on the oracle. If the Liquidium oracle feeds a false event, the onchain multisig is then compelled to execute based on the pre-programmed outcome, as it can’t discern between fraudulent or “truthful” offchain events.
Lightning Network
The Lightning Network (LN) is essentially a network enabling off-chain payment channels between two counterparties, where both parties deposit to a shared on-chain multisig address and conduct off-chain payments (in which each transaction is stacked on top of the previous transaction’s hash). To close the channel, any party may submit the most recent transaction hash onchain — upon a certain timelock period with no challenges (timelock logic lives natively on the multisig), the multisig redistributes the funds to its constituent addresses based on the submitted transaction hash.
This timelock exists to counteract malicious transaction hash submissions (not submitting the latest transaction hash), so that the honest party is given enough time to submit the latest transaction hash (if not, once the funds are released on-chain, there’s nothing the honest party can do to reverse the transaction). As a deterrent, the multisig is embedded with “justice close” (logic is on-chain), such that even if a party submits a malicious transaction hash, as long as the multisig is able to receive the honest transaction hash within the timelock period, the entirety of the channel’s balance will be forfeited to the honest party.
LN Watchtowers
Watchtowers are opt-in third-party nodes that store your channel’s list of transaction hashes, such that in the event of an attempted fraud, they can submit the latest transaction hash to the on-chain multisig on your behalf to thwart the breach. Not relying on watchtowers means you need to be chronically online to submit the transaction hash on your own within the timelock period in case of a breach attempt. If you don’t make it on time, the multisig will have no choice but to release the funds under the attacker’s terms (the transaction hash could even indicate that you transferred all of your bitcoins to the attacker).
Relying on watchtowers means they’ll be the ones chronically online to monitor for any attempted breach against you. If two peers opted in to watchtowers, the multisig can be configured to accommodate them such that on any channel closing events, they can step in (if needed) to thwart a fraudulent transaction hash by providing the latest transaction hash, but can do nothing to the multisig if there’s no channel closing events. Now, watchtowers are altruistically maintained by Lightning core devs, and that all channels are opted-in by default.
In practice, users don’t directly setup on-chain multisig and run a Lightning node on their own as it’s too cumbersome. Instead, they rely on Lightning nodes to transact on their behalf (and maintain channels with other nodes). As such, most users are actually custodying their bitcoins with a trusted Lightning node provider (where theoretically, they can collude with other nodes to force close channels, then send the bitcoins in custody to their own addresses).
The adoption chasm of non-custodial LN
The fact that users are required to run their own Lightning node to ensure their BTC is non-custodial, is a bottleneck to adoption (contrary to cypherpunks belief, no one wants to run a node).
This is notwithstanding the complicated liquidity management processes for your own Lightning channel. For example: if routing a payment from A to B typically involves four intermediate channels, it would in total require preloaded values five times as large as the actual payment amount — the typical user, who might upload, say, USD 200 to finance small expenses, would certainly unwilling to foot another USD 800 just to support the network's routing capacity.
There are actually non-custodial Lightning wallet solutions (i.e., Phoenix) out there that allows you to run your own Lightning node straight from an app on your phone — as long as the app is running in the background, your Lightning node remains active.
But this is a stop-gap solution IMO: channel funding is still trusted (users have to deposit via Phoenix’s Lightning node, which then routes the payment to the user’s own channel), and channel closing is also trusted (users route payment to Phoenix’s Lightning node, which then makes the transaction to the user’s on-chain address). The holy grail, at least for me, is still a trust-minimized 1-to-1 BTC bridge to a scalable PoS layer. At least, users don’t need to run a node to be non-custodial – if they feel a PoS network’s security is degrading (or just don’t align with its values), they are free to exit back to mainchain and explore other PoS layer options.
Ordinal Theory
Ordinals are merely file inscriptions on sats. Due to Bitcoin's UTXO model, each sat can be serialized based on the block it's issued (the 1st BTC mined on genesis block represents sat #1-100m; the 50th BTC mined represents sat #5b-500b; etc.). Any arbitrary data can then be "inscribed" into these unique sats via its witness data field (originally meant to store transaction signatures: SegWit introduces a diff signature scheme that is appended at the end of the block instead of each transaction, resulting in 75% smaller data size), tying the inscribed data to the unique sat (if the sat moves address, the inscription follows).
Note that ordinal numbers and sat rarity are different. Assume you hold a 0.5 BTC balance since 2015 (which consists of numerous sats). Upon the release of ordinal theory, you actually found out that you hold sat #100, meaning that some sats forming your 0.5 BTC balance is actually mined from genesis!
Even if you only choose to inscribe the sat in 2025, the fact that your sat is #100 would definitely have you subject to monstrous bids! Theoretically speaking, if we strictly look from a monetary-maximizing lens, the best combo would be to inscribe a sub-10k ordinal (you're among the first 10k inscriptors) with a sought-after sat (e.g., #1000, #10000, #69420, etc.).
BRC20
BRC20 is a standard built on top of ordinal theory. Instead of inscribing files, they inscribe JSON to create a fungible token (e.g: "deploy ORDI token, max supply 1b, max mint 1k per address"). People can inscribe another JSON to a random sat for minting ("mint 1k ORDI"), which can then be transferred to anyone. If you hold a "mint 1k ORDI" ordinal, and wants to transfer 200 ORDI, you do additional JSON inscriptions on more random sats to break your "1k ORDI" ordinal to smaller chunks ("300 ORDI chunk", "200 ORDI chunk", "500 ORDI chunk"), then transfer the "200 ORDI chunk" ordinal to your counterparty.
Anyone can index the chain to correctly derive each address' BRC20 balances – easy to identify "faulty" inscriptions and disregard it just by referencing the chain's ordering (e.g: a "mint 2k ORDI" inscription is ignored since it doesn't obey the "max mint 1k ORDI per address" parameter; a "500 ORDI chunk" inscription is ignored since the address doesn't currently hold ordinals like "mint 1k ORDI" or "800 ORDI chunk", that if added together doesn't total to at least 500 ORDI balance).
Runes
On paper, the only glaring difference between BRC20s and Runes is on how data is stored. BRC20 inscribes data on sats, while Runes make use of the OP_RETURN field to store data. However, this seemingly inconsequential data storage choice, presents wildly differing tradeoffs for each respective protocol.
BRC20 has a high onchain footprint, due to the high amounts of UTXOs being produced for its inscriptions. Runes aims to solve this by identifying unspent UTXOs, then uses this to create new transactions containing protocol messages with details like ID, output index, and amount, all stored in an OP_RETURN output.
The result is less “junk” UTXOs, which means less onchain bloat (and faster, cheaper, and more dependable transactions compared to BRC20s).