<commit_before>---
layout: post
name: segwit-benefits
id: en-segwit-benefits
title: Segregated Witness Benefits
permalink: /en/2016/01/25/segwit-benefits
version: 1
excerpt: >
  This page summarises some of the benefits of segregated witness that
  go beyond simply increasing the capacity of the block chain.
---
{% include _toc.html %}

The Segregated Witness soft-fork (segwit) includes a wide range of
features, many of which are highly technical. This page summarises
some of the benefits of those features that go beyond simply increasing
the capacity of the block chain.

## Malleability Fixes

Bitcoin transactions are identified by a 64-digit hexadecimal hash
called a transaction identifier (txid)
which is based on both the coins being spent and on who
will be able to spend the results of the transaction.

Unfortunately,
the way the hash is calculated allows anyone to make small
modifications to the transaction that will not change its meaning,
but will change the hash.  This is called third-party malleability.
BIP62 ("dealing with malleability") attempted to
address these issues in a piecemeal manner, but was too complicated to
implement as consensus checks and has been withdrawn.

For example, you could submit a transaction with hash ef74...c309 to
the network, but instead find that a third-party, such as a node on
the network relaying your transaction, or the miner who includes your
transaction in a block, modifies the transaction slightly, resulting in
your transaction still spending the same coins and paying the same addresses,
but being confirmed under the completely different hash 683f...8bfa instead.

More generally, if one or more of the signers of the transaction revise
their signatures then the transaction remains valid and pays the same
amounts to the same addresses, but the transaction hash changes completely
because it incorporates the signatures. The general case of changes to
signature data (but not the outputs or choice of inputs) modifying the
transaction is called scriptSig malleability.

Segwit prevents third-party and scriptSig malleability by allowing Bitcoin users to move the
malleable parts of the transaction into the *transaction witness,* and
segregating that witness so that changes to the witness does not affect
calculation of the transaction's hash.

### Who benefits?

- **Anyone monitoring unconfirmed transactions:** it's easiest to
  monitor the status of your own transactions by looking them up by txid.  But in
  a system with third-party malleability, wallets must implement extra
  code to be able to deal with changed txids (hashes).

- **Anyone spending unconfirmed transactions:** if Alice pays Bob in
  transaction 1, Bob pays Charlie in transaction 2, and then Alice's
  payment gets malleated and confirmed with a different txid, Bob's
  payment is now invalid and Bob gets all of the bitcoins he paid
  Charlie back.

    If Bob is honest, he will reissue the payment to Charlie; but if he
    isn't, he can keep those bitcoins for himself.

- **The Lightning Network:** with third-party and scriptSig malleability
  fixed, the Lightning Network is less complicated to implement and
  significantly more efficient in its use of space on the blockchain.
  With scriptSig malleability removed, it also becomes possible to run lightweight
  Lightning clients that outsource monitoring the blockchain, instead of
  each Lightning client needing to also be a full Bitcoin node.

- **Anyone using the block chain:** smart contracts today, such as
  micropayment channels, and anticipated new smart contracts, become less
  complicated to design, understand, and monitor.

Note: segwit transactions only avoid malleability if all their inputs are
segwit spends (either directly, or via a backwards compatible segwit
P2SH address).

### Further information

 * [Bitcoin Wiki on Malleability](https://en.bitcoin.it/wiki/Transaction_Malleability)
 * [MtGox Malleability issues](http://www.coindesk.com/bitcoin-bug-guide-transaction-malleability/)<commit_msg>drop mtgox claims re: malleability<commit_after>---
layout: post
name: segwit-benefits
id: en-segwit-benefits
title: Segregated Witness Benefits
permalink: /en/2016/01/25/segwit-benefits
version: 1
excerpt: >
  This page summarises some of the benefits of segregated witness that
  go beyond simply increasing the capacity of the block chain.
---
{% include _toc.html %}

The Segregated Witness soft-fork (segwit) includes a wide range of
features, many of which are highly technical. This page summarises
some of the benefits of those features that go beyond simply increasing
the capacity of the block chain.

## Malleability Fixes

Bitcoin transactions are identified by a 64-digit hexadecimal hash
called a transaction identifier (txid)
which is based on both the coins being spent and on who
will be able to spend the results of the transaction.

Unfortunately,
the way the hash is calculated allows anyone to make small
modifications to the transaction that will not change its meaning,
but will change the hash.  This is called third-party malleability.
BIP62 ("dealing with malleability") attempted to
address these issues in a piecemeal manner, but was too complicated to
implement as consensus checks and has been withdrawn.

For example, you could submit a transaction with hash ef74...c309 to
the network, but instead find that a third-party, such as a node on
the network relaying your transaction, or the miner who includes your
transaction in a block, modifies the transaction slightly, resulting in
your transaction still spending the same coins and paying the same addresses,
but being confirmed under the completely different hash 683f...8bfa instead.

More generally, if one or more of the signers of the transaction revise
their signatures then the transaction remains valid and pays the same
amounts to the same addresses, but the transaction hash changes completely
because it incorporates the signatures. The general case of changes to
signature data (but not the outputs or choice of inputs) modifying the
transaction is called scriptSig malleability.

Segwit prevents third-party and scriptSig malleability by allowing Bitcoin users to move the
malleable parts of the transaction into the *transaction witness,* and
segregating that witness so that changes to the witness does not affect
calculation of the transaction's hash.

### Who benefits?

- **Anyone monitoring unconfirmed transactions:** it's easiest to
  monitor the status of your own transactions by looking them up by txid.  But in
  a system with third-party malleability, wallets must implement extra
  code to be able to deal with changed txids (hashes).

- **Anyone spending unconfirmed transactions:** if Alice pays Bob in
  transaction 1, Bob pays Charlie in transaction 2, and then Alice's
  payment gets malleated and confirmed with a different txid, Bob's
  payment is now invalid and Bob gets all of the bitcoins he paid
  Charlie back.

    If Bob is honest, he will reissue the payment to Charlie; but if he
    isn't, he can keep those bitcoins for himself.

- **The Lightning Network:** with third-party and scriptSig malleability
  fixed, the Lightning Network is less complicated to implement and
  significantly more efficient in its use of space on the blockchain.
  With scriptSig malleability removed, it also becomes possible to run lightweight
  Lightning clients that outsource monitoring the blockchain, instead of
  each Lightning client needing to also be a full Bitcoin node.

- **Anyone using the block chain:** smart contracts today, such as
  micropayment channels, and anticipated new smart contracts, become less
  complicated to design, understand, and monitor.

Note: segwit transactions only avoid malleability if all their inputs are
segwit spends (either directly, or via a backwards compatible segwit
P2SH address).

### Further information

 * [Bitcoin Wiki on Malleability](https://en.bitcoin.it/wiki/Transaction_Malleability)
{'fraction_non_alphanumeric': 0.04219356454238137, 'fraction_numerical': 0.00626017278076875, 'mean_word_length': 4.665248226950355, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 5, 'https://': 2, 'lorem ipsum': 0, 'www.': 1, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6262029', 'n_tokens_mistral': 2028, 'n_tokens_neox': 1908, 'n_words': 1140}