SegWit changed Bitcoin’s rules by separating spending-verification data, such as signatures, from the part used to calculate a transaction’s basic identifier. It also changed how block capacity is measured. For users, this can mean more space-efficient payments; for developers, a more reliable way to build one transaction on another.
When sending, a wallet specifies which previously received funds it spends and what new amounts go to the recipient and, if needed, back to you as change. It must also prove the right to spend those funds. Signatures and other verification data do that job. SegWit placed them in a section called the witness. Here, witness means evidence that the spending conditions are met, not a person watching the payment. The data was neither discarded nor moved outside Bitcoin: nodes enforcing SegWit’s rules still check it. [1]
A wallet tracks a payment by its txid. A later transaction also uses that identifier to refer to the funds it wants to spend. Previously, changing some signature data could change the txid without changing recipients or amounts. That complicated chains of unconfirmed payments. SegWit calculates txid without the witness, so changing only the witness does not change it. To protect the whole transaction against this problem, all its inputs must use SegWit. Changing recipients or inputs can still change txid. More stable references also helped Lightning Network, a network for payments through payment channels. A second identifier, wtxid, does include the witness. [1] [4]
SegWit introduced weight instead of counting every byte equally. A base-data byte costs 4 weight units; an additional witness byte costs 1. A whole block has a 4,000,000-unit limit. A transaction with 100 base bytes and another 100 witness bytes, for example, weighs 500 units and has a virtual size of 125 vB. That size determines the fee at a chosen rate in sat/vB. Savings therefore depend on transaction structure, while demand for block space still influences the rate. The weight limit does not mean every block has the same megabyte size or every SegWit payment is cheaper. [1]
On Bitcoin’s main network, native version-0 SegWit addresses begin with bc1q. P2WPKH and P2WSH distinguish two kinds of spending conditions: a usual key-controlled payment and a script-based payment, where a script is a set of rules. SegWit can also be wrapped in the older P2SH format with an address beginning with 3, but a 3 alone does not prove it uses SegWit. Taproot uses witness version 1 and bc1p addresses. The bc1 prefix therefore does not represent just one payment type. For everyday use, check the sending wallet’s format support and the recipient’s full address; none of these prefixes alone promises anonymity. [1] [2] [3]
The change was designed as a Soft Fork: tighter rules compatible with the older rules. An older node, however, does not fully enforce SegWit’s new conditions itself. The witness is cryptographically tied to the block by a witness commitment in the coinbase, the block’s first transaction. Signatures are therefore not an optional attachment that full validation can ignore. BIP 141 also expresses weight as three times base size plus total size; virtual size is weight divided by four, rounded up. These are two ways to describe the same accounting, not two different limits. [1]
For the clearest picture, read this entry together with Transaction, Transaction Fees, Lightning Network, Taproot. The reverse links also lead from Transaction, Transaction Fees, Taproot, Lightning Network.