Bitcoin Q&A: What is Segregated Witness?


A lot of people are asking about Segregated Witness. Segregated witness is a change in the architecture
of transactions that allows signatures to be in… a separate attached data structure and not computed
as part of the transaction hash or transaction ID. Segregated Witness has a number of advantages
over the traditional transaction architecture. Most importantly, it is an opt-in [feature], meaning
you can use Segregated Witness if you want [to]… but you don’t [need] to use Segregated
Witness if you don’t want to [use it]. With Segregated Witness, signatures are placed
in a separate Merkle tree in the block; those signatures are called “witnesses”
and the tree is called the witness Merkle tree. The transaction IDs are no longer affected by the
signatures, which fixes a problem called malleability, which allowed people to mess around with
signatures and change transaction IDs. This is an important problem to solve… because it affects [our] ability to implement various
types of smart contracts, including payment channels. Segregated Witness addresses are different than
traditional Bitcoin addresses. There are two formats. One is Segregated Witness wrapped
inside of pay-to-script-hash (P2SH). Those [addresses] begin with a ‘3’ and look
very much like Bitcoin multi-sig addresses. Segregated Witness, when wrapped in P2SH, is
backwards-compatible and easy to use for any wallet, whether it understands SegWit or not. There is also a new format for [SegWit] addresses
defined in [BIP-173], which is called “Bech32.” This format starts with the letters ‘bc1’ [and the
rest uses] lowercase, alphanumeric characters. ‘bc1’ or Bech32 addresses are full native Segregated
Witness addresses, without being wrapped in P2SH. We are gradually seeing more wallets, exchanges,
and [merchant] providers switch to that. One of the reasons why you want to use
Segregated Witness [for transactions] is because… it [comes with a fee discount because they use less data
compared with traditional bitcoin transactions]. That was a way to increase the capacity
of each block without doing a hard fork. So Segregated Witness also improves capacity. You can read about other advantages in
‘Mastering Bitcoin,’ but that is what SegWit is. “How would you know that you
are using Segregated Witness?” It depends. Your wallet may have [added] a special
function in order to use Segregated Witness. Keep in mind that Segregated Witness
has two different types of addresses. There are SegWit addresses wrapped in P2SH,
which start with a ‘3’ and look like multi-sig addresses, because multi-sig addresses are also wrapped in P2SH. Or you might see one of the new native
SegWit addresses, which starts with ‘bc1.’ If you see that ‘bc1,’ it is a Segregated Witness native
address. The reason we still have the P2SH addresses… is because those are backwards-compatible, allowing wallets which don’t yet understand the new format… to still be able to send to a [SegWit-enabled] wallet
without having to [migrate to the native addresses]. [Again, that backwards-compatible address starts with]
a ‘3,’ which is more broadly accepted by wallets today. If your wallet is sending from a SegWit address, then the
[signature will be] in a separate part of the transaction. You may not see that, but your wallet is capable
of handling Segregated Witness addresses. When you produce a receiving address
for someone else to send [bitcoin to] you, that receiving address either starts with a ‘3’ or ‘bc1.’ If it starts with ‘bc1,’ you are definitely using SegWit.
If it starts with ‘3,’ you are using SegWit or a multi-sig. If [the address] starts with a ‘1,’ you are using a
traditional Bitcoin address and not using SegWit. “What type of malleability and scalability issues can
Bitcoin present without using Segregated Witness?” That’s a great question. If you make a transaction without using Segregated
Witness, a third-party can maleate that transaction. They can modify it in unauthorized ways and
re-transmit [it] with a slightly modified signature, such that the transaction is still valid,
but its transaction ID has changed. This causes problems if you have other transactions
that depend on it and the transaction ID has changed… before it has been mined, then those other transactions
[will be] invalid and need to be changed too. You [couldn’t] create unbroadcasted transactions
and know that they will remain [valid]. You can’t create a chain of many dependent
transactions together; until each of them is confirmed, the transaction ID [could] be changed
by a third party and re-broadcasted. Malleability is quite a significant problem when it comes
to smart contracts and more advanced functionality. If you [send] transactions that do not have Segregated
Witness, then they are still susceptible to malleability. Using the SegWit addresses and [data] structure [with]
your transactions, you ensure they are not malleable. [Second-layer] protocols that do smart contracts, chain
transactions together, or create payment channels… use only SegWit, to make it impossible [for
third parties] to maleate those transactions. “Why is nobody [exploiting] the malleability bug in
Bitcoin or Bitcoin Cash, if you can interject a change… [with the] signatures, pay a higher
fee, and broadcast it again?” [With traditional addresses], you can change the
signature [and it will] be slightly different but still valid. You can’t change who is getting paid, you can’t change
the amount or where the money is coming from. You can’t steal money with transaction malleability, but
you can [cause confusion] by changing transaction IDs. There is not much point [to exploiting this bug yet]. You would use malleability as an attack for denial-of-
service or [creating issues] for types of smart contracts. But since 2013, every single exchange and [merchant]
provider knows about transaction malleability. They don’t allow you to make double withdrawals or
cause other problems with transaction malleability. “If we are making two different blocks, a transaction
and witness block, [are they] still the same size?” “Please elaborate on Segregated Witness.” There are not two different blocks. The transaction
data and witness data are part of the same block. One block would have both data sets in it: two
Merkle trees, committed in the coinbase transaction, and the Merkle root in the header of the block. The witness (signature) section and the transaction
section are in the same block, but not mixed together. The witness part is not inside each of the transactions,
but in a separate part of the data structure. [The witness part] has its own Merkle tree, so if the
witness changes because of transaction malleability, the transaction ID and Merkle root don’t change. “How is the witness part included in add-on blocks
and verified in the coinbase transaction?” Since the beginning, every single transaction is
hashed to produce a transaction identifier / hash. That transaction hash is put in the bottom of the
Merkle tree; all the transactions create [the] Merkle tree. The Merkle root of that tree, one hash that summarises
the entire tree, is stored in the header of the block. The witness parts are also stored in
exactly the same way, just in a different tree. Every single witness from every single transaction
is put into the bottom of a Merkle tree, the Merkle tree summarises all of [the witnesses] into
a Merkle root, and this one is the witness Merkle root. The witness Merkle root is incorporated
into the coinbase transaction. Validation of the block requires validating that the
Merkle roots of transactions and witnesses is correct, including all transactions and witnesses. Every witness is validated against every transaction. Validation hasn’t changed at all [and there are
no “add-on” blocks necessary for the witness part]. “SegWit security. Are there any concerns about
the potential increase in the number… of invalid blocks propagated, if not enough people are
storing the unhashed signature data on their nodes?” Jessie is [asking] about [what happens] if people decide
to not store the witness part, only the transaction part. Is there a potential increase in the
number of invalid blocks propagated? Not really. Ultimately, miners [and non-mining nodes]
validating the witness data ensure that invalid blocks… [don’t] propagate very far,
because they will be orphaned. Don’t forget that the [block] reward is an incentive to
keep miners honest; they must validate witness data. Otherwise, if they produce invalid blocks, those
will be rejected by the majority of the network. Jessie asks a follow-up: “If I [don’t] store signature data
on my node, could I not verify previous transactions?” “If that is the case, should large transactions
remain off SegWit or the Lightning Network, insofar as you not personally storing signature data?” No. Signature data is part of block and transaction
validation, whether you choose to store it or not. As Bitcoin works today, most nodes validate signature
data only once and then they stop validating it. [They] don’t necessarily have to store it in the future. If you decide to have a node that is not validating
witness data or not storing witness data, those are two very different things. You can’t configure your node to not validate witness
data; you can only configure your node to not store it. What does that mean? When [your node] receives
a transaction, it will validate the witness data. You may choose to not store it on
your blockchain [database] long-term. You don’t need to store it once you have validated it. But if you choose to not validate witness data
[at all], you are not running a validating node. If you are not running a validating node, you are
operating in Simple Payment Verification (SPV) mode, which means you are relying on the miners to do
validation for you; that is not [independent] validation. You have a range of choices. You can
validate [and] store, or validate [but not] store. If you choose not to validate [either], then you might as well run a light client
[since] you are not validating transaction data. You are running an SPV node. You always
have the opportunity to run an SPV node. But an SPV node [offers] less security [for verifying
your own transactions] than a fully validating node. You can [have] a fully validating node,
but not store all of the data [long-term]. You can prune the blockchain to reduce its
disk space, and you can not store witnesses.

Leave a Reply

Your email address will not be published. Required fields are marked *