11 files changed, 244 insertions, 20 deletions
diff --git a/README.mediawiki b/README.mediawiki
index 11ecbb1..11013cc 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -258,13 +258,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Justus Ranvier
 | Informational
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0049.mediawiki|49]]
 | Applications
 | Derivation scheme for P2WPKH-nested-in-P2SH based accounts
 | Daniel Weigl
 | Informational
-| Draft
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0050.mediawiki|50]]
 |
@@ -371,13 +371,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Stephen Pair
 | Standard
 | Final
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0074.mediawiki|74]]
 | Applications
 | Allow zero value OP_RETURN in Payment Protocol
 | Toby Padilla
 | Standard
-| Draft
+| Rejected
 |-
 | [[bip-0075.mediawiki|75]]
 | Applications
@@ -771,6 +771,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0155.mediawiki|155]]
+| Peer Services
+| addrv2 message
+| Wladimir J. van der Laan
+| Standard
+| Draft
+|-
 | [[bip-0156.mediawiki|156]]
 | Peer Services
 | Dandelion - Privacy Enhancing Routing
diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index b4567c4..3bf5aec 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -240,7 +240,7 @@ What if a single merchant wishes to block a hard-fork?
 
 How about a small number of merchants (maybe only two) who sell products to each other?
 
-* In this scenario, it would seem the previous Bitcoin is alive any working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP.
+* In this scenario, it would seem the previous Bitcoin is alive and working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP.
 
 How can economic agreement veto a soft-fork?
 
diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki
index ba828e1..0f4fb81 100644
--- a/bip-0016.mediawiki
+++ b/bip-0016.mediawiki
@@ -40,7 +40,7 @@ The rules for validating these outpoints when relaying transactions or consideri
 # Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint.
 # {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey.
 
-These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) <ref>[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]</ref>. There are transaction earlier than 1333238400 in the block chain that fail these new validation rules. <ref>[http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]</ref>. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details).
+These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) <ref>[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]</ref>. There are transactions earlier than 1333238400 in the block chain that fail these new validation rules. <ref>[http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]</ref>. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details).
 
 For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is:
 
diff --git a/bip-0049.mediawiki b/bip-0049.mediawiki
index 74645a1..1e0ba2b 100644
--- a/bip-0049.mediawiki
+++ b/bip-0049.mediawiki
@@ -2,10 +2,10 @@
   BIP: 49
   Layer: Applications
   Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts
-  Author: Daniel Weigl <Daniel.Weigl@mycelium.com>
+  Author: Daniel Weigl <DanielWeigl@gmx.at>
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0049
-  Status: Draft
+  Status: Final
   Type: Informational
   Created: 2016-05-19
   License: PD
@@ -68,7 +68,7 @@ To derive the P2SH address from the above calculated public key, we use the enca
 
 ==Backwards Compatibility==
 
-This BIP is not backwards compatible by design as described under [#considerations]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong.
+This BIP is not backwards compatible by design as described under [[#considerations|considerations]]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong.
 
 
 ==Test vectors==
diff --git a/bip-0074.mediawiki b/bip-0074.mediawiki
index 01fcf2c..b6e9b39 100644
--- a/bip-0074.mediawiki
+++ b/bip-0074.mediawiki
@@ -5,7 +5,7 @@
   Author: Toby Padilla <tobypadilla@gmail.com>
   Comments-Summary: Unanimously Discourage for implementation
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0074
-  Status: Draft
+  Status: Rejected
   Type: Standards Track
   Created: 2016-01-29
   License: PD
diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki
index ed07c82..81763a0 100644
--- a/bip-0143.mediawiki
+++ b/bip-0143.mediawiki
@@ -391,7 +391,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
                02 4730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
     nLockTime: 00000000
   
-  Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the the input-output pairs are swapped:
+  Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the input-output pairs are swapped:
   0100000000010280e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffffe9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff0280969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac80969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000
     nVersion:  01000000
     marker:    00
diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index 75d8a1b..8ec2191 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -79,7 +79,7 @@ The serialization has the following structure:
 
 Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output.
 
-If the witness is empty, the old serialization format should be used. 
+If the witness is empty, the old serialization format must be used. 
 
 Currently, the only witness objects type supported are script witnesses which consist of a stack of byte arrays. It is encoded as a var_int item count followed by each item encoded as a var_int length followed by a string of bytes. Each txin has its own script witness. The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins.
 
diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki
new file mode 100644
index 0000000..5914241
--- /dev/null
+++ b/bip-0155.mediawiki
@@ -0,0 +1,189 @@
+<pre>
+  BIP: 155
+  Layer: Peer Services
+  Title: addrv2 message
+  Author: Wladimir J. van der Laan <laanwj@gmail.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0155
+  Status: Draft
+  Type: Standards Track
+  Created: 2019-02-27
+  License: BSD-2-Clause
+</pre>
+
+==Introduction==
+
+===Abstract===
+
+This document proposes a new P2P message to gossip longer node addresses over the P2P network.
+This is required to support new-generation Onion addresses, I2P, and potentially other networks
+that have longer endpoint addresses than fit in the 128 bits of the current <code>addr</code> message.
+
+===Copyright===
+
+This BIP is licensed under the 2-clause BSD license.
+
+===Motivation===
+
+Tor v3 hidden services are part of the stable release of Tor since version 0.3.2.9. They have
+various advantages compared to the old hidden services, among which better encryption and privacy
+<ref>[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt Tor Rendezvous Specification - Version 3]</ref>.
+These services have 256 bit addresses and thus do not fit in the existing <code>addr</code> message, which encapsulates onion addresses in OnionCat IPv6 addresses.
+
+Other transport-layer protocols such as I2P have always used longer
+addresses. This change would make it possible to gossip such addresses over the
+P2P network, so that other peers can connect to them.
+
+==Specification==
+
+<blockquote>
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+"SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be
+interpreted as described in RFC 2119<ref>[https://tools.ietf.org/html/rfc2119 RFC 2119]</ref>.
+</blockquote>
+
+The <code>addrv2</code> message is defined as a message where <code>pchCommand == "addrv2"</code>.
+It is serialized in the standard encoding for P2P messages.
+Its format is similar to the current <code>addr</code> message format
+<ref>[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer Reference: addr message]</ref>, with the difference that the 
+fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the time and services format has been changed to VARINT.
+
+This means that the message contains a serialized <code>std::vector</code> of the following structure:
+
+{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
+!Type
+!Name
+!Description
+|-
+| <code>VARINT</code> (unsigned)
+| <code>time</code>
+| Time that this node was last seen as connected to the network. A time in Unix epoch time format, up to 64 bits wide.
+|-
+| <code>VARINT</code> (unsigned)
+| <code>services</code>
+| Service bits. A 64-wide bit field.
+|-
+| <code>uint8_t</code>
+| <code>networkID</code>
+| Network identifier. An 8-bit value that specifies which network is addressed.
+|-
+| <code>std::vector<uint8_t></code>
+| <code>addr</code>
+| Network address. The interpretation depends on networkID.
+|-
+| <code>uint16_t</code>
+| <code>port</code>
+| Network port. If not relevant for the network this MUST be 0.
+|}
+
+One message can contain up to 1,000 addresses. Clients SHOULD reject messages with more addresses.
+
+Field <code>addr</code> has a variable length, with a maximum of 32 bytes (256 bits). Clients SHOULD reject
+longer addresses.
+
+The list of reserved network IDs is as follows:
+
+{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
+!Network ID
+!Enumeration
+!Address length (bytes)
+!Description
+|-
+| <code>0x01</code>
+| <code>IPV4</code>
+| 4
+| IPv4 address (globally routed internet)
+|-
+| <code>0x02</code>
+| <code>IPV6</code>
+| 16
+| IPv6 address (globally routed internet)
+|-
+| <code>0x03</code>
+| <code>TORV2</code>
+| 10
+| Tor v2 hidden service address
+|-
+| <code>0x04</code>
+| <code>TORV3</code>
+| 32
+| Tor v3 hidden service address
+|-
+| <code>0x05</code>
+| <code>I2P</code>
+| 32
+| I2P overlay network address
+|-
+| <code>0x06</code>
+| <code>CJDNS</code>
+| 16
+| Cjdns overlay network address
+|}
+
+To allow for future extensibility, clients MUST ignore address types that they do not know about.
+Client MAY store and gossip address formats that they do not know about. Further network ID numbers MUST be reserved in a new BIP document.
+
+Clients SHOULD reject addresses that have a different length than specified in this table for a specific address ID, as these are meaningless.
+
+See the appendices for the address encodings to be used for the various networks.
+
+==Compatibility==
+
+Send <code>addrv2</code> messages only, and exclusively, when the peer has a certain protocol version (or higher):
+<source lang="c++">
+//! gossiping using `addrv2` messages starts with this version
+static const int GOSSIP_ADDRV2_VERSION = 70016;
+</source>
+For older peers keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types.
+
+==Reference implementation==
+
+The reference implementation is available at (to be done)
+
+==Acknowledgements==
+
+- Jonas Schnelli: change <code>services</code> field to VARINT, to make the message more compact in the likely case instead of always using 8 bytes.
+
+- Luke-Jr: change <code>time</code> field to VARINT, for post-2038 compatibility.
+
+- Gregory Maxwell: various suggestions regarding extensibility
+
+==Appendix A: Tor v2 address encoding==
+
+The new message introduces a separate network ID for <code>TORV2</code>. 
+
+Clients MUST send Tor hidden service addresses with this network ID, with the 80-bit hidden service ID in the address field. This is the same as the representation in the legacy <code>addr</code> message, minus the 6 byte prefix of the OnionCat wrapping.
+
+Clients SHOULD ignore OnionCat (<code>fd87:d87e:eb43::/48</code>) addresses on receive if they come with the <code>IPV6</code> network ID.
+
+==Appendix B: Tor v3 address encoding==
+
+According to the spec <ref>[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt Tor Rendezvous Specification - Version 3: Encoding onion addresses]</ref>, next-gen <code>.onion</code> addresses are encoded as follows:
+<pre>
+onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion"
+ CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2]
+
+ where:
+   - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service.
+   - VERSION is an one byte version field (default value '\x03')
+   - ".onion checksum" is a constant string
+   - CHECKSUM is truncated to two bytes before inserting it in onion_address
+</pre>
+
+Tor v3 addresses MUST be sent with the <code>TORV3</code> network ID, with the 32-byte PUBKEY part in the address field. As VERSION will always be '\x03' in the case of v3 addresses, this is enough to reconstruct the onion address.
+
+==Appendix C: I2P address encoding==
+
+Like Tor, I2P naming uses a base32-encoded address format<ref>[https://geti2p.net/en/docs/naming#base32 I2P: Naming and address book]</ref>.
+
+I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by <code>.b32.i2p</code>.
+
+I2P addresses MUST be sent with the <code>I2P</code> network ID, with the decoded SHA-256 hash as address field.
+
+==Appendix D: Cjdns address encoding==
+
+Cjdns addresses are simply IPv6 addresses in the <code>fc00::/8</code> range<ref>[https://github.com/cjdelisle/cjdns/blob/6e46fa41f5647d6b414612d9d63626b0b952746b/doc/Whitepaper.md#pulling-it-all-together Cjdns whitepaper: Pulling It All Together]</ref>. They MUST be sent with the <code>CJDNS</code> network ID.
+
+==References==
+
+<references/>
diff --git a/bip-0158.mediawiki b/bip-0158.mediawiki
index 579a246..ad46da6 100644
--- a/bip-0158.mediawiki
+++ b/bip-0158.mediawiki
@@ -27,9 +27,8 @@ enables basic wallets and applications with more advanced smart contracts.
 [[bip-0157.mediawiki|BIP 157]] defines a light client protocol based on
 deterministic filters of block content. The filters are designed to
 minimize the expected bandwidth consumed by light clients, downloading filters
-and full blocks. This document defines two initial filter types, ''basic'' and
-''extended'', to provide support for advanced applications while reducing the
-filter size for regular wallets.
+and full blocks. This document defines the initial filter type ''basic''
+that is designed to reduce the filter size for regular wallets.
 
 == Definitions ==
 
diff --git a/bip-0173.mediawiki b/bip-0173.mediawiki
index ad6c58b..c3ee060 100644
--- a/bip-0173.mediawiki
+++ b/bip-0173.mediawiki
@@ -209,7 +209,7 @@ implementations' assumptions about lengths), but still be visually
 distinct.</ref> for testnet.
 * The data-part values:
 ** 1 byte: the witness version
-** A conversion of the the 2-to-40-byte witness program (as defined by [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) to base32:
+** A conversion of the 2-to-40-byte witness program (as defined by [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) to base32:
 *** Start with the bits of the witness program, most significant bit per byte first.
 *** Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.
 *** Translate those bits to characters using the table above.
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index f197728..b4a6407 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -118,6 +118,12 @@ The currently defined global types are as follows:
 *** <tt>{transaction}</tt>
 ** Note: Every PSBT must have a field with this type.
 
+* Type: Extended Public Key <tt>PSBT_GLOBAL_XPUB = 0x01</tt>
+** Key: The type followed by the 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived.
+*** <tt>{0x01}|{xpub}</tt>
+** Value: The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key.
+*** <tt>{master key fingerprint}|{32-bit int}|...|{32-bit int}</tt>
+
 The currently defined per-input types are defined as follows:
 
 * Type: Non-Witness UTXO <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt>
@@ -319,6 +325,8 @@ For a Signer to only produce valid signatures for what it expects to sign, it mu
 * If a witness UTXO is provided, no non-witness signature may be created
 * If a redeemScript is provided, the scriptPubKey must be for that redeemScript
 * If a witnessScript is provided, the scriptPubKey or the redeemScript must be for that witnessScript
+* If a sighash type is provided, the signer must check that the sighash is acceptable. If unacceptable, they must fail.
+* If a sighash type is not provided, the signer should sign using SIGHASH_ALL, but may use any sighash type they wish.
 
 =====Simple Signer Algorithm=====
 
@@ -326,13 +334,17 @@ A simple signer can use the following algorithm to determine what and how to sig
 
 <pre>
 sign_witness(script_code, i):
-    for key in psbt.inputs[i].keys:
-        if IsMine(key):
+    for key, sighash_type in psbt.inputs[i].items:
+        if sighash_type == None:
+            sighash_type = SIGHASH_ALL
+        if IsMine(key) and IsAcceptable(sighash_type):
             sign(witness_sighash(script_code, i, input))
 
 sign_non_witness(script_code, i):
-    for key in psbt.inputs[i].keys:
-        if IsMine(key):
+    for key, sighash_type in psbt.inputs[i].items:
+        if sighash_type == None:
+            sighash_type = SIGHASH_ALL
+        if IsMine(key) and IsAcceptable(sighash_type):
             sign(non_witness_sighash(script_code, i, input))
 
 for input,i in enumerate(psbt.inputs):
@@ -358,6 +370,23 @@ for input,i in enumerate(psbt.inputs):
         assert False
 </pre>
 
+====Change Detection====
+
+Signers may wish to display the inputs and outputs to users for extra verification.
+In such displays, signers may wish to identify which outputs are change outputs in order to omit them to avoid additional user confusion.
+In order to detect change, a signer can use the BIP 32 derivation paths provided in inputs and outputs as well as the extended public keys provided globally.
+
+For a single key output, a signer can observe whether the master fingerprint for the public key for that output belongs to itself.
+If it does, it can then derive the public key at the specified derivation path and check whether that key is the one present in that output.
+
+For outputs involving multiple keys, a signer can first examine the inputs that it is signing.
+It should determine the general pattern of the script and internally produce a representation of the policy that the script represents.
+Such a policy can include things like how many keys are present, what order they are in, how many signers are necessary, which signers are required, etc.
+The signer can then use the BIP 32 derivation paths for each of the pubkeys to find which global extended public key is the one that can derive that particular public key.
+To do so, the signer would extract the derivation path to the highest hardened index and use that to lookup the public key with that index and master fingerprint.
+The signer would construct this script policy with extended public keys for all of the inputs and outputs.
+Change outputs would then be identified as being the outputs which have the same script policy as the inputs that are being signed.
+
 ===Combiner===
 
 The Combiner can accept 1 or many PSBTs.