release-notes: Update from blog draft

8 years ago · 99f5cf1893
1 changed files with 98 additions and 24 deletions
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@ -44,28 +44,102 @@ Segregated witness soft fork
 Segregated witness (segwit) is a soft fork that, if activated, will
 allow transaction-producing software to separate (segregate) transaction
-signatures (witnesses) from the rest of the data in a transaction, and
+signatures (witnesses) from the part of the data in a transaction that is
-to allow miners to place those witnesses outside of the traditional
+covered by the txid. This provides several immediate benefits:
-block structure. This provides two immediate benefits:
+
-
+- **Elimination of unwanted transaction malleability:** Segregating the witness
- **Elimination of malleability:** Segregating the witness allows both
+  allows both existing and upgraded software to calculate the transaction
-  existing software and upgraded software that receives transactions to
+  identifier (txid) of transactions without referencing the witness, which can
-  calculate the transaction identifier (txid) of segwit-using
+  sometimes be changed by third-parties (such as miners) or by co-signers in a
-  transactions without referencing the witness. This solves all known
+  multisig spend. This solves all known cases of unwanted transaction
-  cases of unwanted third-party transaction malleability, which is a
+  malleability, which is a problem that makes programming Bitcoin wallet
-  problem that makes programming Bitcoin wallet software more difficult
+  software more difficult and which seriously complicates the design of smart
-  and which seriously complicates the design of smart contracts for
+  contracts for Bitcoin.
-  Bitcoin.
+
-
+- **Capacity increase:** Segwit transactions contain new fields that are not
- **Capacity increase:** Moving witness data outside of the traditional
+  part of the data currently used to calculate the size of a block, which
-  block structure (but still inside a new-style block structure) means
+  allows a block containing segwit transactions to hold more data than allowed
-  new-style blocks can hold more data than older-style blocks, allowing
+  by the current maximum block size. Estimates based on the transactions
-  a modest increase to the amount of transaction data that can fit in a
+  currently found in blocks indicate that if all wallets switch to using
-  block.
+  segwit, the network will be able to support about 70% more transactions. The
-
+  network will also be able to support more of the advanced-style payments
-Segwit also simplifies the ability to add new features to Bitcoin and
+  (such as multisig) than it can support now because of the different weighting
-improves the efficiency of full nodes, which will help provide long-term
+  given to different parts of a transaction after segwit activates (see the
-benefits to Bitcoin users.
+  following section for details).
 - **Weighting data based on how it affects node performance:** Some parts of
  each Bitcoin block need to be stored by nodes in order to validate future
  blocks; other parts of a block can be immediately forgotten (pruned) or used
  only for helping other nodes sync their copy of the block chain.  One large
  part of the immediately prunable data are transaction signatures (witnesses),
  and segwit makes it possible to give a different "weight" to segregated
  witnesses to correspond with the lower demands they place on node resources.
  Specifically, each byte of a segregated witness is given a weight of 1, each
  other byte in a block is given a weight of 4, and the maximum allowed weight
  of a block is 4 million.  Weighting the data this way better aligns the most
  profitable strategy for creating blocks with the long-term costs of block
  validation.
 - **Signature covers value:** A simple improvement in the way signatures are
  generated in segwit simplifies the design of secure signature generators
  (such as hardware wallets), reduces the amount of data the signature
  generator needs to download, and allows the signature generator to operate
  more quickly.  This is made possible by having the generator sign the amount
  of bitcoins they think they are spending, and by having full nodes refuse to
  accept those signatures unless the amount of bitcoins being spent is exactly
  the same as was signed.  For non-segwit transactions, wallets instead had to
  download the complete previous transactions being spent for every payment
  they made, which could be a slow operation on hardware wallets and in other
  situations where bandwidth or computation speed was constrained.
 - **Linear scaling of sighash operations:** In 2015 a block was produced that
  required about 25 seconds to validate on modern hardware because of the way
  transaction signature hashes are performed.  Other similar blocks, or blocks
  that could take even longer to validate, can still be produced today.  The
  problem that caused this can't be fixed in a soft fork without unwanted
  side-effects, but transactions that opt-in to using segwit will now use a
  different signature method that doesn't suffer from this problem and doesn't
  have any unwanted side-effects.
 - **Increased security for multisig:** Bitcoin addresses (both P2PKH addresses
  that start with a '1' and P2SH addresses that start with a '3') use a hash
  function known as RIPEMD-160.  For P2PKH addresses, this provides about 160
  bits of security---which is beyond what cryptographers believe can be broken
  today.  But because P2SH is more flexible, only about 80 bits of security is
  provided per address. Although 80 bits is very strong security, it is within
  the realm of possibility that it can be broken by a powerful adversary.
  Segwit allows advanced transactions to use the SHA256 hash function instead,
  which provides about 128 bits of security  (that is 281 trillion times as
  much security as 80 bits and is equivalent to the maximum bits of security
  believed to be provided by Bitcoin's choice of parameters for its Elliptic
  Curve Digital Security Algorithm [ECDSA].)
 - **More efficient almost-full-node security** Satoshi Nakamoto's original
  Bitcoin paper describes a method for allowing newly-started full nodes to
  skip downloading and validating some data from historic blocks that are
  protected by large amounts of proof of work.  Unfortunately, Nakamoto's
  method can't guarantee that a newly-started node using this method will
  produce an accurate copy of Bitcoin's current ledger (called the UTXO set),
  making the node vulnerable to falling out of consensus with other nodes.
  Although the problems with Nakamoto's method can't be fixed in a soft fork,
  Segwit accomplishes something similar to his original proposal: it makes it
  possible for a node to optionally skip downloading some blockchain data
  (specifically, the segregated witnesses) while still ensuring that the node
  can build an accurate copy of the UTXO set for the block chain with the most
  proof of work.  Segwit enables this capability at the consensus layer, but
  note that Bitcoin Core does not provide an option to use this capability as
  of this 0.13.1 release.
 - **Script versioning:** Segwit makes it easy for future soft forks to allow
  Bitcoin users to individually opt-in to almost any change in the Bitcoin
  Script language when those users receive new transactions.  Features
  currently being researched by Bitcoin Core contributors that may use this
  capability include support for Schnorr signatures, which can improve the
  privacy and efficiency of multisig transactions (or transactions with
  multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can
  improve the privacy and efficiency of scripts with two or more conditions.
  Other Bitcoin community members are studying several other improvements
  that can be made using script versioning.
 Activation for the segwit soft fork is being managed using BIP9
 versionbits.  Segwit's version bit is bit 1, and nodes will begin
@ -93,8 +167,8 @@ signaling support for a soft fork.
 Null dummy soft fork
 -------------------
-Combined with the segwit soft fork is a soft fork that turns a
+Combined with the segwit soft fork is an additional change that turns a
-long-existing network relay policy into a consensus rule.  The
+long-existing network relay policy into a consensus rule. The
 `OP_CHECKMULTISIG` and `OP_CHECKMULTISIGVERIFY` opcodes consume an extra
 stack element ("dummy element") after signature validation. The dummy
 element is not inspected in any manner, and could be replaced by any