7 files changed, 139 insertions, 7 deletions
diff --git a/README.mediawiki b/README.mediawiki
index c80d3ea..da18d6b 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -216,6 +216,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Justus Ranvier
 | Informational
 | Draft
+|-
+| [[bip-0049.mediawiki|49]]
+| Derivation scheme for P2WPKH-nested-in-P2SH based accounts
+| Daniel Weigl
+| Informational
+| Draft
 |- style="background-color: #cfffcf"
 | [[bip-0050.mediawiki|50]]
 | March 2013 Chain Fork Post-Mortem
diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index fe7761e..43a5ce6 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -126,12 +126,13 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
 * Comments-Summary: <summary tone>
   Comments-URI: <links to wiki page for comments>
   Status: <Draft | Active | Proposed | Deferred | Rejected |
-           Withdrawn | Final | Superseded>
+           Withdrawn | Final | Replaced | Obsolete>
   Type: <Standards Track | Informational | Process>
   Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
   License: <abbreviation for approved license(s)>
 * License-Code: <abbreviation for code under different approved license(s)>
 * Post-History: <dates of postings to bitcoin mailing list, or link to thread in mailing list archive>
+* Requires: <BIP number(s)>
 * Replaces: <BIP number>
 * Superseded-By: <BIP number>
 </pre>
diff --git a/bip-0049.mediawiki b/bip-0049.mediawiki
new file mode 100644
index 0000000..d4f58d7
--- /dev/null
+++ b/bip-0049.mediawiki
@@ -0,0 +1,104 @@
+<pre>
+  BIP: 49
+  Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts
+  Author: Daniel Weigl <Daniel.Weigl@mycelium.com>
+  Status: Draft
+  Type: Informational
+  Created: 2016-05-19
+</pre>
+
+==Abstract==
+
+This BIP defines the derivation scheme for HD wallets using the P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki|BIP 141]]) serialization format for segregated witness transactions.
+
+==Motivation==
+
+With the usage of P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh|BIP 141]]) transactions it is necessary to have a common derivation scheme.
+It allows the user to use different HD wallets with the same masterseed and/or a single account seamlessly.
+
+Thus the user needs to create a dedicated segregate witness accounts, which ensures that only wallets compatible with this BIP
+will detect the account and handle them appropriately.
+
+===Considerations===
+Two generally different approaches are possible for current BIP44 capable wallets:
+
+1) Allow the user to use the same account(s) that they already uses, but add segregated witness encoded addresses to it
+
+1.1) Use the same public keys as defined in BIP44, but in addition to the normal P2PKH address also derive the P2SH address from it.
+
+1.2) Use the same account root, but branch off and derive different external and internal chain roots to derive dedicated public keys for the segregated witness addresses.
+
+2) Create dedicated accounts only used for segregated witness addresses.
+
+The solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP49-compatible wallet masterseed into/in a non-BIP49-compatible wallet, the account might show up but also it might miss some UTXOs.
+
+Therefore this BIP uses solution 2, which fails in a more visible way. Either the account shows up or not at all. The user does not have to check his balance after using the same seed in different wallets.
+
+
+==Specifications==
+
+This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] root account.
+
+===Public key derivation===
+
+To derive a public key from the root account, this BIP uses the same account-structure as defined in
+[[bip-0044.mediawiki|BIP 44]], but only uses a different purpose value to indicate the different transaction
+serialization method.
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+For the `purpose`-path level it uses `49'`. The rest of the levels are used as defined in BIP44
+
+
+===Address derivation===
+
+To derive the P2SH address from the above calculated public key, we use the encapsulation defined in [[bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh|BIP 141]]:
+
+    witness:      <signature> <pubkey>
+    scriptSig:    <0 <20-byte-key-hash>>
+                  (0x160014{20-byte-key-hash})
+    scriptPubKey: HASH160 <20-byte-script-hash> EQUAL
+                  (0xA914{20-byte-script-hash}87)
+
+==Backwards Compatibility==
+
+This BIP is not backwards compatible by design as described under [#considerations]. A not compatible wallet will not discover accounts at all and the user will notice that something is wrong.
+
+
+==Test vectors==
+
+<pre>
+  masterseedWords = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
+  masterseed = tprv8ZgxMBicQKsPe5YMU9gHen4Ez3ApihUfykaqUorj9t6FDqy3nP6eoXiAo2ssvpAjoLroQxHqr3R5nE3a5dU3DHTjTgJDd7zrbniJr6nrCzd (testnet)
+
+  // Account 0, root = m/49'/0'/0'
+  account0Xpriv = tprv8fnNnm525ViePCEx7Z9cZb6QNUtsUc8XKaePnZtPnKZWHw1rnAC9r6MdMdsmrkGW7Vy3eVtwtRqrfkxfWjnitBTNEZjTb6pbui7BUmnBBd3 (testnet)
+
+  // Account 0, first receiving private key = m/49'/0'/0'/0/0
+  account0recvPrivateKey = cQHH4LLDxjDqTM2rRpEi29f9a3EAQ8A7yWxiNdR8nC8WrkKU7Dms
+  account0recvPrivateKeyHex = 0x508c73a06f6b6c817238ba61be232f5080ea4616c54f94771156934666d38ee3
+  account0recvPublickKeyHex = 0x039b3b694b8fc5b5e07fb069c783cac754f5d38c3e08bed1960e31fdb1dda35c24
+
+  // Address derivation
+  keyhash = HASH160(account0recvPublickKeyHex) = 0xf990679acafe25c27615373b40bf22446d24ff44
+  scriptSig = <0 <keyhash>> = 0x0014f990679acafe25c27615373b40bf22446d24ff44
+  addressBytes = HASH160(scriptSig) = 0x3fb6e95812e57bb4691f9a4a628862a61a4f769b
+
+  // addressBytes base58check encoded for testnet
+  address = base58check(prefix | addressBytes) = 2My47gHNc8nhX5kBWqXHU4f8uuQvQKEgwMd (testnet)
+</pre>
+
+
+==Reference==
+
+* [[bip-0016.mediawiki|BIP16 - Pay to Script Hash]]
+* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
+* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
+* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
+* [[bip-0141.mediawiki|BIP141 - Segregated Witness (Consensus layer)]]
+
+== Copyright ==
+
+This document is placed in the public domain.
+\ No newline at end of file
diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 2b2360b..6df2624 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -133,12 +133,24 @@ The following definitions are not used for consensus limits, but are suggested t
 
 ''Transaction weight'' is defined as ''Base transaction size'' * 3 + ''Total transaction size'' (ie. the same method as calculating ''Block weight'' from ''Base size'' and ''Total size'').
 
-''Virtual transaction size'' is defined as ''Transaction weight'' / 4 (rounded up to nearest integer).
+''Virtual transaction size'' is defined as ''Transaction weight'' / 4 (rounded up to the next integer).
 
-''Base transaction size'' is the transaction size in bytes with the original transaction serialization without any witness-related data.
+''Base transaction size'' is the size of the transaction serialised with the witness data stripped.
 
 ''Total transaction size'' is the transaction size in bytes serialized as described in [[bip-0144.mediawiki|BIP144]], including base data and witness data.
 
+=== New script semantics ===
+
+Despite that the script language for P2WPKH and P2WSH looks very similar to pre-segregated witness script, there are several notable differences. Users MUST NOT assume that a script spendable in pre-segregated witness system would also be spendable as a P2WPKH or P2WSH script. Before large-scale deployment in the production network, developers should test the scripts on testnet with the default relay policy turned on, and with a small amount of money after BIP141 is activated on mainnet.
+
+A major difference at consensus level is described in [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143], as a new transaction digest algorithm for signature verification in version 0 witness program.
+
+Three relay and mining policies are also included in the first release of segregated witness at reference implementation version 0.13.1. Softforks based on these policies are likely to be proposed in the near future. To avoid indefinite delay in transaction confirmation and permanent fund loss in a potential softfork, users MUST observe the new semantics carefully:
+
+# Only compressed public keys are accepted in P2WPKH and P2WSH (See [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type BIP143])
+# The argument of OP_IF/NOTIF in P2WSH must be minimal<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html</ref>
+# Signature(s) must be null vector(s) if an OP_CHECKSIG or OP_CHECKMULTISIG is failed (for both pre-segregated witness script and P2WSH. See [https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki BIP146])
+
 == Examples ==
 
 === P2WPKH ===
diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki
index 892c027..a0b0cce 100644
--- a/bip-0143.mediawiki
+++ b/bip-0143.mediawiki
@@ -125,6 +125,11 @@ Refer to the reference implementation, reproduced below, for the precise algorit
   return ss.GetHash();
 </source>
 
+== Restrictions on public key type ==
+As a default policy, only compressed public keys are accepted in P2WPKH and P2WSH. Each public key passed to a sigop inside version 0 witness program must be a compressed key: the first byte MUST be either 0x02 or 0x03, and the size MUST be 33 bytes. Transactions that break this rule will not be relayed or mined by default.
+
+Since this policy is preparation for a future softfork proposal, to avoid potential future funds loss, users MUST NOT use uncompressed keys in version 0 witness programs.
+
 == Example ==
 === Native P2WPKH ===
   
@@ -538,7 +543,7 @@ As a soft fork, older software will continue to operate without modification. No
 
 == Reference Implementation ==
 
-https://github.com/bitcoin/bitcoin/pull/7910
+https://github.com/bitcoin/bitcoin/pull/8149
 
 == References ==
 
diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index f2c8857..f10fe0c 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -103,9 +103,9 @@ and therefore, they have witness hash equal to normal hash.)
 <img src=bip-0144/witnesstx.png></img>
 
 === Relay ===
-New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
+New inv types MSG_WITNESS_TX (0x40000001, or (1<<30)+MSG_TX) and MSG_WITNESS_BLOCK (0x40000002, or (1<<30)+MSG_BLOCK) are added, only
 for use in getdata. Inventory messages themselves still use just MSG_TX and MSG_BLOCK,
-similar to MSG_FILTERED_BLOCK.
+similar to MSG_FILTERED_BLOCK. A further inv type MSG_FILTERED_WITNESS_BLOCK (0x40000003, or (1<<30)+MSG_FILTERED_BLOCK) is reserved for future use.
 
 * '''Rationale for not advertizing witnessness in invs''': we don't always use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: implicitly, every transaction and block have a witness, old ones just have empty ones.
 
@@ -117,7 +117,7 @@ MSG_WITNESS_BLOCK requests will return a block message with transactions that ha
 Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.
 
 == Reference Implementation ==
-https://github.com/sipa/bitcoin/commits/segwit
+https://github.com/bitcoin/bitcoin/pull/8149
 
 == Copyright ==
 This document is placed in the public domain.
diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl
index 568b8eb..f0e43d2 100755
--- a/scripts/buildtable.pl
+++ b/scripts/buildtable.pl
@@ -24,7 +24,11 @@ my %EmailField = (
 	Editor => undef,
 );
 my %MiscField = (
+	'Discussions-To' => undef,
 	'Post-History' => undef,
+	'Replaces' => undef,
+	'Superseded-By' => undef,
+	'Resolution' => undef,
 );
 
 my %ValidLayer = (