Reviewed and updated: October 19, 2026.
Bitcoin scaling involves more than a transactions-per-second number. A useful comparison asks how much work reaches the base chain, what a payment requires before it can succeed, and how the user can settle or exit when conditions change.
SegWit changed accounting, not the existence of a block limit
BIP 141 defines block weight with a limit of 4,000,000 weight units. Non-witness bytes and witness bytes have different weight costs. Witness data is still part of the block data; describing it as outside the blockchain is misleading.
For transaction weight W, virtual size is rounded up from W / 4. In a hypothetical example, a transaction weighing 600 units has a virtual size of 150 vbytes. At an assumed fee rate of 8 sat/vbyte, its fee is 1,200 satoshis. This is a calculation example, not a current fee recommendation. Different transaction structures have different sizes.
SegWit also addressed transaction malleability for its spending paths. Its effective capacity improvement depends on the transaction mix. There is no universal multiplier that applies equally to every block.
Taproot improves how spending conditions are represented
BIP 341 specifies Taproot's key and script spending paths. A cooperative key-path spend can conceal unused alternatives; a script-path spend reveals the selected branch and proof rather than every possible branch. The privacy and size benefits depend on how the wallet constructs and spends the output.
Taproot is not a promise that all multisignature transactions automatically collapse into one signature. Participants need an appropriate signing protocol and implementation. Nor does Taproot remove the block-weight limit or make all transactions private.
Lightning uses channels with directional liquidity
Lightning moves repeated payments into channels whose funding and enforcement connect to Bitcoin. Routed payments need a usable path with sufficient liquidity along the route. Lightning Labs' liquidity guide distinguishes the ability to send from the ability to receive.
Take a simplified channel with 500,000 satoshis of total capacity: 350,000 on Alice's side and 150,000 on Ben's. Ignoring reserves and fees, Alice can send 100,000 to Ben, leaving 250,000 on each side. The capacity remains 500,000; its direction changes. Alice cannot then send 300,000 through that channel merely because the headline capacity exceeds her payment.
Real usable amounts also reflect channel reserves, pending payments and routing fees. A sender needs outbound liquidity, the receiver needs inbound liquidity, and intermediate channels need suitable balances. More channels or faster computers alone do not guarantee a successful route.
Evaluate the failure and exit paths
| Situation | What matters |
|---|---|
| On-chain payment | Transaction size, fee rate, mempool conditions and confirmation policy |
| Lightning payment | Route availability, directional liquidity and payment constraints |
| Channel settlement | Cooperative or unilateral close, time locks and on-chain fees |
| Custodial Lightning service | The provider's balance records, availability and withdrawal terms |
Unilateral settlement can involve delays and monitoring responsibilities. A wallet may hide channel management behind a simpler interface, but the mechanism and any service-provider dependency still exist. Ask who can sign, who monitors the channel and what happens if the provider is unavailable.
This guide removes the earlier millions-of-TPS assertion and dated adoption examples. A scaling comparison should measure completed payments and the conditions under which they complete, rather than treating theoretical parallel activity as a live network guarantee.
Sources and scope
- Bitcoin Improvement Proposal 141: Segregated Witness
- Bitcoin Improvement Proposal 341: Taproot
- Lightning Labs: Managing Channel Liquidity
- Bitcoin Core: Segregated Witness Costs and Risks
Continue reading: Bitcoin architecture · Layer 1 and Layer 2
Editorial update: Corrected SegWit weight accounting and Taproot qualifications; removed unsubstantiated TPS claims; added fee and directional-channel calculations.