From 1f64d2b06d628dffdc297be9a8afbb9da4e6b6ca Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Mon, 21 Oct 2013 00:32:10 -0400 Subject: [PATCH 001/181] Rename to mediawiki extension --- bip-0001.md => bip-0001.mediawiki | 0 bip-0010.md => bip-0010.mediawiki | 0 bip-0011.md => bip-0011.mediawiki | 0 bip-0012.md => bip-0012.mediawiki | 0 bip-0013.md => bip-0013.mediawiki | 0 bip-0014.md => bip-0014.mediawiki | 0 bip-0015.md => bip-0015.mediawiki | 0 bip-0016.md => bip-0016.mediawiki | 0 bip-0017.md => bip-0017.mediawiki | 0 bip-0019.md => bip-0019.mediawiki | 0 bip-0020.md => bip-0020.mediawiki | 0 bip-0021.md => bip-0021.mediawiki | 0 bip-0022.md => bip-0022.mediawiki | 0 bip-0030.md => bip-0030.mediawiki | 0 bip-0031.md => bip-0031.mediawiki | 0 bip-0032.md => bip-0032.mediawiki | 0 bip-0033.md => bip-0033.mediawiki | 0 bip-0034.md => bip-0034.mediawiki | 0 bip-0035.md => bip-0035.mediawiki | 0 19 files changed, 0 insertions(+), 0 deletions(-) rename bip-0001.md => bip-0001.mediawiki (100%) rename bip-0010.md => bip-0010.mediawiki (100%) rename bip-0011.md => bip-0011.mediawiki (100%) rename bip-0012.md => bip-0012.mediawiki (100%) rename bip-0013.md => bip-0013.mediawiki (100%) rename bip-0014.md => bip-0014.mediawiki (100%) rename bip-0015.md => bip-0015.mediawiki (100%) rename bip-0016.md => bip-0016.mediawiki (100%) rename bip-0017.md => bip-0017.mediawiki (100%) rename bip-0019.md => bip-0019.mediawiki (100%) rename bip-0020.md => bip-0020.mediawiki (100%) rename bip-0021.md => bip-0021.mediawiki (100%) rename bip-0022.md => bip-0022.mediawiki (100%) rename bip-0030.md => bip-0030.mediawiki (100%) rename bip-0031.md => bip-0031.mediawiki (100%) rename bip-0032.md => bip-0032.mediawiki (100%) rename bip-0033.md => bip-0033.mediawiki (100%) rename bip-0034.md => bip-0034.mediawiki (100%) rename bip-0035.md => bip-0035.mediawiki (100%) diff --git a/bip-0001.md b/bip-0001.mediawiki similarity index 100% rename from bip-0001.md rename to bip-0001.mediawiki diff --git a/bip-0010.md b/bip-0010.mediawiki similarity index 100% rename from bip-0010.md rename to bip-0010.mediawiki diff --git a/bip-0011.md b/bip-0011.mediawiki similarity index 100% rename from bip-0011.md rename to bip-0011.mediawiki diff --git a/bip-0012.md b/bip-0012.mediawiki similarity index 100% rename from bip-0012.md rename to bip-0012.mediawiki diff --git a/bip-0013.md b/bip-0013.mediawiki similarity index 100% rename from bip-0013.md rename to bip-0013.mediawiki diff --git a/bip-0014.md b/bip-0014.mediawiki similarity index 100% rename from bip-0014.md rename to bip-0014.mediawiki diff --git a/bip-0015.md b/bip-0015.mediawiki similarity index 100% rename from bip-0015.md rename to bip-0015.mediawiki diff --git a/bip-0016.md b/bip-0016.mediawiki similarity index 100% rename from bip-0016.md rename to bip-0016.mediawiki diff --git a/bip-0017.md b/bip-0017.mediawiki similarity index 100% rename from bip-0017.md rename to bip-0017.mediawiki diff --git a/bip-0019.md b/bip-0019.mediawiki similarity index 100% rename from bip-0019.md rename to bip-0019.mediawiki diff --git a/bip-0020.md b/bip-0020.mediawiki similarity index 100% rename from bip-0020.md rename to bip-0020.mediawiki diff --git a/bip-0021.md b/bip-0021.mediawiki similarity index 100% rename from bip-0021.md rename to bip-0021.mediawiki diff --git a/bip-0022.md b/bip-0022.mediawiki similarity index 100% rename from bip-0022.md rename to bip-0022.mediawiki diff --git a/bip-0030.md b/bip-0030.mediawiki similarity index 100% rename from bip-0030.md rename to bip-0030.mediawiki diff --git a/bip-0031.md b/bip-0031.mediawiki similarity index 100% rename from bip-0031.md rename to bip-0031.mediawiki diff --git a/bip-0032.md b/bip-0032.mediawiki similarity index 100% rename from bip-0032.md rename to bip-0032.mediawiki diff --git a/bip-0033.md b/bip-0033.mediawiki similarity index 100% rename from bip-0033.md rename to bip-0033.mediawiki diff --git a/bip-0034.md b/bip-0034.mediawiki similarity index 100% rename from bip-0034.md rename to bip-0034.mediawiki diff --git a/bip-0035.md b/bip-0035.mediawiki similarity index 100% rename from bip-0035.md rename to bip-0035.mediawiki From c5e1b25bc4d458edc1043bc3c63e3fa2007050fc Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Mon, 21 Oct 2013 00:35:40 -0400 Subject: [PATCH 002/181] Archive Revision as of 21:29, 6 October 2013 https://en.bitcoin.it/w/index.php?title=BIP_0001&oldid=41572 --- bip-0001.mediawiki | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index 433126b1..b0662caf 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -1,8 +1,9 @@ +{{bip}} + 
   BIP: 1
   Title: BIP Purpose and Guidelines
-  Author: Amir Taaki 
-  Status: Active
+  Status: Accepted
   Type: Standards Track
   Created: 19-08-2011
@@ -19,15 +20,15 @@ Because the BIPs are maintained as text files in a versioned repository, their r There are three kinds of BIP: -* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validitity rules, or any change or addition that affects the interoperability of applications using Bitcoin. +* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. * An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice. * A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP. ==BIP Work Flow== -The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to (no cross-posting please). Also see BIP Editor Responsibilities & Workflow below. +The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to (no cross-posting please). Also see BIP Editor Responsibilities & Workflow below. -The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focussed the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocussed or too broad. If in doubt, split your BIP into several well-focussed ones. +The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones. Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum or the [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net] mailing list is the best way to go about this. @@ -35,7 +36,7 @@ Vetting an idea publicly before going as far as writing a BIP is meant to save t Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal. -Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors . This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. +Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors . This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and create and create a page for it on the [[Bitcoin_Improvement_Proposals|Bitcoin Wiki]]. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. @@ -57,7 +58,7 @@ BIPs can also be superseded by a different BIP, rendering the original obsolete. The possible paths of the status of BIPs are as follows: -[[File:bip-0001-1.png]] +[[File:BIP-0001-Process.png]] Some Informational and Process BIPs may also have a status of "Active" if they are never meant to be completed. E.g. BIP 1 (this BIP). @@ -69,7 +70,7 @@ Each BIP should have the following parts: * Abstract -- a short (~200 word) description of the technical issue being addressed. -* Copyright/public domain -- Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License [7]. +* Copyright/public domain -- Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License. * Specification -- The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin). @@ -139,10 +140,10 @@ BIPs may include auxiliary files such as diagrams. Such files must be named BIP- It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP. -If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor . If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :). +If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor . If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :). BIP Editor Responsibilities & Workflow -A BIP editor must subscribe to the list. All BIP-related correspondence should be sent (or CC'd) to (but please do not cross-post!). +A BIP editor must subscribe to the list. All BIP-related correspondence should be sent (or CC'd) to (but please do not cross-post!). For each new BIP that comes in an editor does the following: @@ -170,3 +171,4 @@ The editors don't pass judgement on BIPs. We merely do the administrative & edit This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the Bitcoin editors or the forums at bitcointalk.org. +[[Category:BIP|A]] From a3678b2342c7a2fd7913c8aeff0db67cd5958e51 Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Mon, 21 Oct 2013 00:38:05 -0400 Subject: [PATCH 003/181] Archive Revision as of 14:57, 18 January 2013 https://en.bitcoin.it/w/index.php?title=BIP_0010&oldid=35295 --- bip-0010.mediawiki | 147 +++++++++++++++++++++++---------------------- 1 file changed, 76 insertions(+), 71 deletions(-) diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki index bd96ed6b..2270a820 100644 --- a/bip-0010.mediawiki +++ b/bip-0010.mediawiki @@ -1,3 +1,5 @@ +{{bip}} + 
   BIP: 10
   Title: Multi-Sig Transaction Distribution
@@ -7,92 +9,95 @@
   Created: 28-10-2011
-A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the final, proposed transaction, and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction. +A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the proposed transaction and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction. + +This BIP describes a way standardize the encoding of proposal transactions, to assist with signature collection and broadcast (which includes regular, 1-of-1 transactions requiring signatures from an offline computer). The goal is to encourage a standard that guarantees interoperability of all programs that implement it. -This BIP describes a protocol to standardize the representation of proposal transactions and the subsequent collection of signatures to execute multi-signature transactions. The goal is to encourage a standard that guarantees interoperability of all programs that implement it. ==Motivation== The enabling of multi-signature transactions in Bitcoin will introduce a great deal of extra functionality to the users of the network, but also a great deal of extra complexity. Executing a multi-signature tx will be a multi-step process, and will potentially get worse with multiple clients, each implementing this process differently. By providing an efficient, standardized technique, we can improve the chance that developers will adopt compatible protocols and not bifurcate the user-base based on client selection. +In addition to providing a general encoding scheme for transaction signing/collection, it does not require the signing device to hold any blockchain information (all information needed for verification and signing is part of the encoding). This enables the existence of very lightweight devices that can be used for signing since they do not need the blockchain -- only a minimal set of Bitcoin tools and an ECDSA module. Therefore, BIP 0010 has benefit beyond just multi-signature transactions. + ==Specification== This BIP proposes the following process, with terms in quotes referring to recommended terminology that should be encouraged across all implementations. # One party will initiate this process by creating a "Distribution Proposal", which could be abbreviated DP, or TxDP -# Transaction preparation -- the user creating the TxDP will create the transaction as they would like to see it spent (obviously without the signatures). Then they will go through each input and replace its script with the script of the txout that the input is spending. The reason for is so that ''receiving parties can sign with their private key without needing access to the blockchain.'' -# This TxDP will be serialized (see below), which will include a tag identifying the TxDP in the serialization, as well as in the filename, if it is saved to file. -# The TxDP will have an "DP ID" which is the hash of the TxDP in Base58 -- the reason for the specific naming convention is to make sure it is not confused with the actual the transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected). The final Tx ID can be referred to as its "Broadcast ID", in order to distinguish it from the pre-signed ID. -# The TxDP will have an unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it. -# Identical TxDP objects with different signatures can be easily combined -# For cases where the TxDP might be put into a file to be sent via email, it should use .txdp or .btcdp suffix - +# The user creating the TxDP (the preparer) will create the transaction as they would like to see it spent, but with blank TxIn scripts (where the signatures scripts will eventually go). +# The proposed transaction will be spending a set of unspent TxOuts available in the blockchain. The full transactions containing these TxOuts will be serialized and included, as well. This so that the values of the TxIns can be verified before signing (the prev-tx-hash is part of the data being signed, but the value is not). By including the full tx, the signing party can verify that the tx matches the OutPoint hash, and then verify input values, all without any access to the blockchain. +# The TxDP will have an "DP ID" or "Unsigned ID" which is the hash of the proposed transaction with blanked scripts, in Base58. This is a specific naming convention to make sure it is not confused with the actual the transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected). The final Tx ID can be referred to as its "Broadcast ID", in order to distinguish it from the pre-signed ID. +# The TxDP will have an potentially-unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it. +# Identical TxDP objects with different signatures can be easily combined. This allows one party to send out all the requests for signatures at once, and combine them all when they are received (instead of having to "pass it around". +# For cases where the TxDP might be put into a file or sent via email, it should use .txdp or .btcdp suffix Anyone adopting BIP 0010 for multi-sig transactions will use the following format (without indentation): - '-----BEGIN-TRANSACTION-TXDPID-------' - ("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize) - (preparedTxSerializedHexLine0) - (preparedTxSerializedHexLine1) - (preparedTxSerializedHexLine2) - ... - ("_TXINPUT_") (00) (InputValue) - ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0) - (SigHexRemainingLines) - ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0) - (SigHexRemainingLines) - ("_TXINPUT_") (01) (InputValue) - ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0) - (SigHexRemainingLines) - ("_TXINPUT_") (02) (InputValue) - '-------END-TRANSACTION-TXDPID-------' - -A multi-signature proposal that has 3 signatures on it could be stored in a file "Tx_QrtZ3K42n.txdp" and it would look something like: - - '''-----BEGIN-TXDP-----''' - '''_TXDIST_f9beb4d9_QrtZ3K42n_fda5''' - 204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e642062 - 61696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104 - 678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6 - 49f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f - ac00000000f9beb4d9d7000000010000006fe28c0ab6f1b372c1a6a246ae63f7 - 4f931e8365e15a089c68d6190000000000982051fd1e4ba744bbbe680e1fee14 - 677ba1a3c3540bf7b1cdb606e857233e0e61bc6649ffff001d01e36299010100 - fe328f9a3920119cbd3f1311f830039832abb3baf284625151f328f9a3920 - '''_TXINPUT_00_23.13000000''' - _SIG_1Gffm3Kj3_02_7e_fa8d9127149200f568383a089c68d61900000000009 - 8205bbbe680e1fee1467744bbbe680e1fee14677ba1a3c3540bf7b1cdb606e85 - 7233e0e61bc6649 - '''_TXINPUT_01_4.00000000''' - '''_TXINPUT_02_10.00000000''' - _SIG_1QRTt83p8_007f ffff00db606e857233e0e61bc6649ffff00db60831f9 - 6efa8d9127149200f568383a089c68d619000000000098205bbbe680e1fee1 - 46770e1fee14677ba1a3c35 - _SIG_1m3Rk38fd_007f - ffff00db606e857233e0e61bc6649ffff00db606efa8d9127149200f568383a0 - 89c68d619000000000098205bbbe680e1fee146770e1fee14677ba1a3c35 - '''------END-TXDP------''' - -In this transaction, there are 3 inputs, providing 23.13, 4.0 and 10.0 BTC, respectively. Input 0 has one signature, input 1 has zero signatures, and input 2 has two signatures. - -The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpretted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program/parser to simply determine the core elements of the TxDP. - -A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it should not be the recommended method for combining TxDPs. + '-----BEGIN-TRANSACTION-TXDPID-------' + ("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize) + (serializedTxListInHex_Line1) + (serializedTxListInHex_Line2) + (serializedTxListInHex_Line3) + ... + ("_TXINPUT_") (00) (InputValue) + ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0) + (SigHexRemainingLines) + ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0) + (SigHexRemainingLines) + ("_TXINPUT_") (01) (InputValue) + ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0) + (SigHexRemainingLines) + ("_TXINPUT_") (02) (InputValue) + '-------END-TRANSACTION-TXDPID-------' + + +The following is an example TxDP from Armory, produced while running on the test network. Its DPID is 3fX59xPj: + + -----BEGIN-TRANSACTION-3fX59xPj------------------------------------------------- + _TXDIST_fabfb5da_3fX59xPj_00a0 + 010000000292807c8e70a28c687daea2998d6273d074e56fa8a55a0b10556974cf2b526e61000000 + 0000ffffffffe3c1ee0711611b01af3dee55b1484f0d6b65d17dce4eff0e6e06242e6cf457e10000 + 000000ffffffff02b0feea0b000000001976a91457996661391fa4e95bed27d7e8fe47f47cb8e428 + 88ac00a0acb9030000001976a914dc504e07b1107110f601fb679dd3f56cee9ff71e88ac00000000 + 0100000001eb626e4f73d88f415a8e8cb32b8d73eed47aa1039d0ed2f013abdc741ce6828c010000 + 008c493046022100b0da540e4924518f8989a9da798ca2d9e761b69a173b8cc41a3e3e3c6d77cd50 + 022100ecfa61730e58005338420516744ef680428dcfc05022dec70a851365c8575b190141042dc5 + be3afa5887aee4a377032ed014361b0b9b61eb3ea6b8a8821bfe13ee4b65cd25d9630e4f227a53e8 + bf637f85452c9981bcbd64ef77e22ce97b0f547c783effffffff0200d6117e030000001976a914cf + f580fd243f64f0ad7bf69faf41c0bf42d86d8988ac00205fa0120000001976a9148d573ef6984fd9 + f8847d420001f7ac49b222a24988ac000000000100000001f2782db40ae147398a31cff9c7cc3423 + 014a073a92e463741244330cc304168f000000008c493046022100c9311b9eef0cc69219cb96838f + dd621530a80c46269a00dccc66498bc03ccf7a0221003742ee652a0a76fd28ad81aa73bb7f7a0a6a + 81850af58f62d9a184d10e5eec30014104f815e8ef4cad584e04974889d7636e8933803d2e72991d + b5288c9e953c2465533905f98b7b688898c7c1f0708f2e49f0dd0abc06859ffed5144e8a1018a4e8 + 63ffffffff02008c8647000000001976a914d4e211215967f8e3744693bf85f47eb4ee9567fc88ac + 603d4e95010000001976a914e9a6b50901c1969d2b0fd43a3ccfa3fef3291efe88ac00000000 + _TXINPUT_00_150.00000000 + _SIG_mzUYGfqGpyXmppYpmWJ31Y4zTxR4ZCod22_00_008c + 4930460221007699967c3ec09d072599558d2e7082fae0820206b63aa66afea124634ed11a080221 + 0003346f7e963e645ecae2855026dc7332eb7237012539b34cd441c3cef97fbd4d01410497d5e1a0 + 0e1db90e893d1f2e547e2ee83b5d6bf4ddaa3d514e6dc2d94b6bcb5a72be1fcec766b8c382502caa + 9ec09fe478bad07d3f38ff47b2eb42e681c384cc + _TXINPUT_01_12.00000000 + _SIG_mzvaN8JUhHLz3Gdec1zBRxs5rNaYLQnbD1_01_008c + 49304602210081554f8b08a1ad8caa69e34f4794d54952dac7c5efcf2afe080985d6bd5b00770221 + 00dea20ca3dbae1d15ec61bec57b4b8062e7d7c47614aba032c5a32f651f471cfd014104c30936d2 + 456298a566aa76fefeab8a7cb7a91e8a936a11757c911b4c669f0434d12ab0936fc13986b156156f + 9b389ed244bbb580112be07dbe23949a4764dffb + -------END-TRANSACTION-3fX59xPj------------------------------------------------- + + + +In this transaction, there are two inputs, one of 150 BTC and the other of 12 BTC. This transaction combines 162 BTC to create two outputs, one of 160 BTC, one 1.9995 BTC, and a tx fee of 0.0005. In this TxDP, both inputs have been signed, and thus could broadcast immediately. + +The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpretted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program to parse the core elements of the TxDP. + +A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it is not the recommended method for combining TxDPs. == Reference Implementation == -This proposal has been implemented and tested in the ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction). Armory does not have Multi-signature transaction support yet, but all the code is implemented, just untested. The source code for this implementation be found in the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py Armory Github project]. The PyTxDistProposal class implements all features of BIP 0010: - -[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4616 Create TxDP from list of unspent TxOuts] - -[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4840 Serialization of TxDP] - -[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4879 Unserialize a TxDP] - -[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4795 Convert Completed TxDP to Broadcast-Tx] - -==Known Issues== - -One of the reasons TxDPs are versatile, is the ability for a device to "understand" and sign a transaction '''without''' access to the blockchain. However, this means that any information included in the TxDP that is not part of the final broadcast transaction (such as input values), cannot be verified by the device. i.e. Someone could create a TxDP and lie about the values of each input, knowing that the signing device will not be able to verify those values. Since the final, serialized transaction does not include input values, the subsequent signature will be valid no matter what inputs values were provided. +This proposal has been implemented and tested in the ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction), and will eventually use it for multi-signature transcations. The source code for this implementation be found in the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py Armory Github project]. Specifically, the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4704 PyTxDistProposal class] implements all features of BIP 0010. It contains reference code for both +[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L5095 serializing a TxDP] and [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L5143 unserializing a TxDP]. -This is only a minor issue, since developers who are concerned about such "attacks" can choose to ignore non-signed fields in the TxDP. Or, they can guarantee that all TxDPs will pass through a trusted system that ''does'' have access to the blockchain and can verify such information. +[[Category:BIP|D]] From f8d9ff0c508ff5b2c4d0b783237147504f38b63b Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Mon, 21 Oct 2013 00:39:05 -0400 Subject: [PATCH 004/181] Archive Revision as of 14:58, 18 January 2013 https://en.bitcoin.it/w/index.php?title=BIP_0011&oldid=35301 --- bip-0011.mediawiki | 3 +++ 1 file changed, 3 insertions(+) diff --git a/bip-0011.mediawiki b/bip-0011.mediawiki index 3eba9337..b58cffbb 100644 --- a/bip-0011.mediawiki +++ b/bip-0011.mediawiki @@ -1,3 +1,5 @@ +{{bip}} + 
   BIP: 11
   Title: M-of-N Standard Transactions
@@ -57,3 +59,4 @@ https://github.com/gavinandresen/bitcoin-git/tree/op_eval
 
 * [https://bitcointalk.org/index.php?topic=46538 OP_EVAL proposal]
 
+[[Category:BIP|C]]

From f6db0af39f6eee60ad7a5d8583ad902c139419a6 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Mon, 21 Oct 2013 00:39:46 -0400
Subject: [PATCH 005/181] Archive Revision as of 14:57, 18 January 2013

https://en.bitcoin.it/w/index.php?title=BIP_0012&oldid=35296
---
 bip-0012.mediawiki | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bip-0012.mediawiki b/bip-0012.mediawiki
index 37542ebd..7fee6de1 100644
--- a/bip-0012.mediawiki
+++ b/bip-0012.mediawiki
@@ -1,3 +1,5 @@
+{{bip}}
+
 
   BIP: 12
   Title: OP_EVAL
@@ -82,4 +84,4 @@ https://bitcointalk.org/index.php?topic=46538
 
 M-of-N Multisignature Transactions BIP 11
 
-
+[[Category:BIP|W]]

From 4be890738e6e867fb2c96eee065747a29e8dc7a5 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Mon, 21 Oct 2013 00:40:40 -0400
Subject: [PATCH 006/181] Archive Revision as of 20:30, 18 January 2013

https://en.bitcoin.it/w/index.php?title=BIP_0013&oldid=35307
---
 bip-0013.mediawiki | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/bip-0013.mediawiki b/bip-0013.mediawiki
index 97b8b8b5..2806584e 100644
--- a/bip-0013.mediawiki
+++ b/bip-0013.mediawiki
@@ -1,8 +1,10 @@
+{{bip}}
+
 
   BIP: 13
-  Title: Address Format for OP_EVAL
+  Title: Address Format for pay-to-script-hash
   Author: Gavin Andresen 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 18-10-2011
 

@@ -22,7 +24,7 @@ The new bitcoin address type is constructed in the same manner as existing bitco
 
     base58-encode: [one-byte version][20-byte hash][4-byte checksum]
 
-Version byte is 2 for a main-network address, 109 for a testnet address.
+Version byte is 5 for a main-network address, 196 for a testnet address.
 The 20-byte hash is the hash of the script that will be used to redeem the coins.
 And the 4-byte checksum is the first four bytes of the SHA256 hash of the version and hash.
 
@@ -38,15 +40,21 @@ This is one piece of the simplest path to a more secure bitcoin infrastructure.
 
 Assuming that typing in bitcoin addresses manually will become increasingly rare in the future, and given that the existing checksum method for bitcoin addresses seems to work "well enough" in practice and has already been implemented multiple times, the Author believes no change to the checksum algorithm is necessary.
 
+The leading version bytes are chosen so that, after base58 encoding, the leading character is consistent: for the main network, byte 5 becomes the character '3'. For the testnet, byte 196 is encoded into '2'.
+
 ==Backwards Compatibility==
 
 This proposal is not backwards compatible, but it fails gracefully-- if an older implementation is given one of these new bitcoin addresses, it will report the address as invalid and will refuse to create a transaction.
 
 ==Reference Implementation==
 
-https://github.com/gavinandresen/bitcoin-git/tree/op_eval
+See base58.cpp1/base58.h at https://github.com/bitcoin/bitcoin/src
 
 ==See Also==
 
-The OP_EVAL BIP.
+* [[BIP 0012|BIP 12: OP_EVAL, the original P2SH design]]
+* [[BIP 0016|BIP 16: Pay to Script Hash (aka "/P2SH/")]]
+* [[BIP 0017|BIP 17: OP_CHECKHASHVERIFY, another P2SH design]]
 
+[[Category:BIP|D]]
+[[Category:Security]]

From ff0313fc14489650e0f6ebf5c203865b1a606eb3 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Mon, 21 Oct 2013 00:41:28 -0400
Subject: [PATCH 007/181] Archive Revision as of 14:58, 18 January 2013

https://en.bitcoin.it/w/index.php?title=BIP_0014&oldid=35298
---
 bip-0014.mediawiki | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki
index 12cbacbc..d95ecb07 100644
--- a/bip-0014.mediawiki
+++ b/bip-0014.mediawiki
@@ -1,6 +1,8 @@
+{{bip}}
+
 
   BIP: 14
-  Title: Protocol Version and User Agent
+  Title: BIP Protocol Version and User Agent
   Author: Amir Taaki 
           Patrick Strateman 
   Status: Accepted
@@ -88,3 +90,4 @@ They should not be misused beyond what is specified in this section.
 
 When this document was published, the bitcoin protocol and Satoshi client versions were currently at 0.5 and undergoing changes. In order to minimise disruption and allow the undergoing changes to be completed, the next protocol version at 0.6 became peeled from the client version (also at 0.6). As of that time (January 2012), protocol and implementation version numbers are distinct from each other.
 
+[[Category:BIP|C]]

From 37a05d4acf3e7a356aa1f705d0e2d34738f17d74 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Mon, 21 Oct 2013 00:42:26 -0400
Subject: [PATCH 008/181] Archive Revision as of 15:15, 13 August 2013

https://en.bitcoin.it/w/index.php?title=BIP_0015&oldid=40121
---
 bip-0015.mediawiki | 84 ++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 81 insertions(+), 3 deletions(-)

diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki
index 8f86335d..9750c8b1 100644
--- a/bip-0015.mediawiki
+++ b/bip-0015.mediawiki
@@ -1,12 +1,16 @@
+{{bip}}
+
 
   BIP: 15
-  Title: Aliases
+  Title: BIP Aliases
   Author: Amir Taaki 
-  Status: Withdrawn
+  Status: Deferred 
   Type: Standards Track
   Created: 10-12-2011
 

 
+[[BIP 0070]] (payment protocol) may be seen as the alternative to Aliases.
+
 Using vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist.
 
 This document aims to layout through careful argument, a bitcoin alias system. This is a big modification to the protocol that is not easily changed in the future and has big ramifications. There is impetus in getting it correct the first time. Aliases have to be robust and secure.
@@ -31,7 +35,7 @@ Their FirstBits alias becomes:
 
 It is enough information to be given the FirstBits alias ''1brmlab''. When someone wishes to make a purchase, without FirstBits, they either have to type out their address laboriously by hand, scan their QR code (which requires a mobile handset that this author does not own) or find their address on the internet to copy and paste into the client to send bitcoins. FirstBits alleviates this impracticality by providing an easy method to make payments.
 
-Together with Vanitygen (vanity generator), it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination.
+Together with [[vanitygen|Vanitygen (vanity generator)]], it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination.
 
 However FirstBits has its own problems. One is that the possible aliases one is able to generate is limited by the available computing power available. It may not be feasible to generate a complete or precise alias that is wanted- only approximates may be possible. It is also computationally resource intensive which means a large expenditure of power for generating unique aliases in the future, and may not scale up to the level of individuals at home or participants with hand-held devices in an environment of ubiquitous computing.
 
@@ -49,6 +53,8 @@ Security wise, DNS is unsafe and insecure by design. It is possible to spoof rec
 
 As of Dec 2011, DNSSEC is still not yet a defacto standard on the internet. Should a participant in the bitcoin network wish to use DNS TXT records, they would in addition to having to configure DNS, be able to setup DNSSEC. This may not be feasible, especially where some registrars provide access to DNS through a web interface only.
 
+The disadvantage of DNS TXT records is that updating a record takes time. This encourages people to not use new addresses per transaction which has certain security issues.
+
 === Server Service ===
 
 Aside from using DNS TXT records, another possibility is using the domain name system to lookup hosts and then contact a service running on a predefined port to get the bitcoin address.
@@ -323,3 +329,75 @@ Value rpc_send(const Array& params, bool fHelp)
 ...
 
 
+=== IP Transactions ===
+
+An IP transaction is an old transaction format in bitcoin that is disabled and possibly could be deprecated. It involves being given an IP address to make payment to. Upon connecting to the node and requesting their public key using "checkorder", they will respond with a script in the form:
+
+   OP_CHECKSIG
+
+Similar to coinbase output transactions. IP transactions have the advantage of being able to contain additional metadata which can be useful in many transactions. Currently no authentication is done making the scheme insecure against man in the middle (MITM) attacks.
+
+This proposal seeks to enable DNS lookups for IP transactions.
+
+The "checkorder" message would contain a destination account, which could map to different isolated sets of keypairs/wallets running under the same host. The exact mapping from the checkorder reference info to the local system is implementation defined.
+
+By using DNS lookups, the MITM problem with IP transactions could be mitigated by storing a public key in a DNS TXT record. This public key would be used for all future "reply" messages originating from that host. First time use would require a confirmation for acceptance of that public key; like with SSH. Should the "reply" message not match the accepted public key, then the host will be given an error.
+
+[[Category:BIP|E]]
+
+=== Namecoin ID ===
+
+This proposal uses the Namecoin blockchain to associate an alias with a bitcoin address. Bitcoin queries a namecoin node. This retreives the structured data containing the bitcoin address(es) associated with this alias.
+
+Using a decentralised domain name system like Namecoin, means no external server or entity needs to be trusted unlike the other proposals listed here. This indicates a system with the advantage of having a high availability and ease of entry (no restrictions for users to create aliases).
+
+Two examples are presented below. The first shows a simpler format, while the second shows several Bitcoin addresses in a structured format.
+
+ $ namecoind name_show id/khal
+ {
+   "bitcoin" : "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T"
+ }
+
+ $ namecoind name_show id/khal
+ {
+   "bitcoin" :
+   {
+     "default" : "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
+     "donation": "1J3EKMfboca3SESWGrQKESsG1MA9yK6vN4"
+   }
+ }
+
+'''More possibilities :'''
+
+* Allow to securely use '''unsecured channels''' 
+You can put an url and a bitcoin address that will be used to sign the result. It means that a query to this url will return a bitcoin address and a signature. Bitcoin can then check (with the verify_message function) that the returned address has not been replaced by another one.
+ $ namecoind name_show id/khal
+ {
+   "bitcoin" :
+   {
+     "url" : "http://merchant.com/bitcoin/getnewaddres/",
+     "signedWith" : "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T"
+   }
+ }
+
+* Allow to get a different address each time, or per user, per order, etc
+ $ namecoind name_show id/khal
+ {
+   "bitcoin" :
+   {
+     "url" : "http://merchant.com/bitcoin/getaddres/{Your customer id}",
+     "signedWith" : "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
+     "useOnce": false
+   }
+ }
+In the above example, bitcoin will ask the user for "Your customer id" and replace that value in the url before making the http request. The merchant will receive the request and give the user a payment address associated with that customer.
+
+Any text can be put into the brackets, allowing merchants to adapt it to all their needs.
+
+
+* Specification is extensible
+
+New features can be added later to support uncovered cases.
+
+
+See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more informations.

From 57488fbd8b6d2d581b12864ce7a07149e19a177d Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Mon, 21 Oct 2013 00:43:57 -0400
Subject: [PATCH 009/181] Archive Revision as of 11:05, 8 July 2013

https://en.bitcoin.it/w/index.php?title=BIP_0016&oldid=39176
---
 bip-0016.mediawiki | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki
index 68c03547..5344469c 100644
--- a/bip-0016.mediawiki
+++ b/bip-0016.mediawiki
@@ -1,8 +1,10 @@
+{{bip}}
+
 
   BIP: 16
   Title: Pay to Script Hash
   Author: Gavin Andresen 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 03-01-2012
 

@@ -37,7 +39,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 same rules shall be applied when validating transactions in blocks with timestamps after February 15, 2012 (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) [https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]. There are transaction earlier than 13333238400 in the block chain that fail these new validation rules. [http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]. 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:
 
@@ -98,11 +100,16 @@ If a majority of hashing power does not support the new validation rules, then r
 
 ==Reference Implementation==
 
-Coming Soon
+https://gist.github.com/gavinandresen/3966071
 
 ==See Also==
 
 * https://bitcointalk.org/index.php?topic=46538
 * The [[BIP 0013|Address format for Pay to Script Hash BIP]]
 * M-of-N Multisignature Transactions [[BIP 0011|BIP 11]]
+* [[BIP_0016_QA|Quality Assurance test checklist]]
+
+== References ==
+
 
+[[Category:BIP|D]]

From 16fe80c1c61b0d78581af78854e419f7ab544c69 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Mon, 21 Oct 2013 00:44:39 -0400
Subject: [PATCH 010/181] Archive Revision as of 17:37, 28 April 2013

https://en.bitcoin.it/w/index.php?title=BIP_0017&oldid=37378
---
 bip-0017.mediawiki | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/bip-0017.mediawiki b/bip-0017.mediawiki
index 0cd5d708..d10ab8a9 100644
--- a/bip-0017.mediawiki
+++ b/bip-0017.mediawiki
@@ -1,9 +1,11 @@
+{{bip}}
+
 
   BIP: 17
   Title: OP_CHECKHASHVERIFY (CHV)
   Author: Luke Dashjr 
-  Status: Withdrawn
-  Type: Standards Track
+  Status: Draft
+  Type: Withdrawn
   Created: 18-01-2012
 

 
@@ -26,7 +28,7 @@ OP_CHECKHASHVERIFY will re-define the existing OP_NOP2 opcode, and will function
 * If the hashes match, do nothing, proceed as if an OP_NOP; if they do not match, the script fails immediately.
 * Note that in the case of a matched hash, the top stack item (the hash being compared with) is not popped off the stack. This is for backward compatibility.
 
-This opcode reassignment shall be applied when validating transactions in blocks only with timestamps after February 20, 2012 (see the Backwards Compatibility section for details).
+This opcode reassignment shall be applied when validating transactions in blocks only with timestamps after February 23, 2012 (see the Backwards Compatibility section for details).
 
 A new standard transaction type that is relayed and included in mined blocks is defined:
 
@@ -82,7 +84,7 @@ To gracefully upgrade and ensure no long-lasting block-chain split occurs, more
 
 To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "p2sh/CHV" in the input of the coinbase transaction for blocks that they create.
 
-On February 3, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If at least 60% contain "p2sh/CHV" in their coinbase, then all blocks with timestamps after 18 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions validated.
+On February 8, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If at least 60% contain "p2sh/CHV" in their coinbase, then all blocks with timestamps after 23 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions validated.
 
 If a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved).
 
@@ -100,3 +102,4 @@ OP_NOP2 is used, so existing OP_EVAL (BIP 12) transactions in the block chain ca
 * [[BIP 0011|M-of-N Multisignature Transactions (BIP 11)]]
 * Example BIP 17 transaction chain: [http://blockexplorer.com/tx/b8fd633e7713a43d5ac87266adc78444669b987a56b3a65fb92d58c2c4b0e84d a] [http://blockexplorer.com/tx/eb3b82c0884e3efa6d8b0be55b4915eb20be124c9766245bcc7f34fdac32bccb b] [http://blockexplorer.com/tx/055707ce7fea7b9776fdc70413f65ceec413d46344424ab01acd5138767db137 c] [http://blockexplorer.com/tx/6d36bc17e947ce00bb6f12f8e7a56a1585c5a36188ffa2b05e10b4743273a74b d]
 
+[[Category:BIP|D]]

From c7c647483003137bac5bf7e1525b4ec998c2dc16 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Mon, 21 Oct 2013 00:45:22 -0400
Subject: [PATCH 011/181] Archive Revision as of 23:13, 14 April 2012

https://en.bitcoin.it/w/index.php?title=BIP_0018&oldid=25340
---
 bip-0018.mediawiki | 130 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 130 insertions(+)
 create mode 100644 bip-0018.mediawiki

diff --git a/bip-0018.mediawiki b/bip-0018.mediawiki
new file mode 100644
index 00000000..d102aff5
--- /dev/null
+++ b/bip-0018.mediawiki
@@ -0,0 +1,130 @@
+{{bip}}
+
+
+  BIP: 18
+  Title: hashScriptCheck
+  Author: Luke Dashjr 
+  Status: Draft
+  Type: Standards Track
+  Created: 27-01-2012
+

+
+==Abstract==
+
+This BIP modifies the basic format of transaction inputs and outputs, replacing the current scriptSig and scriptPubKey (scripts executed to validate a transaction) with new contents: dataSig, scriptCheck, and hashScriptCheck.
+
+==Motivation==
+
+The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer.
+
+The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted.
+
+==Specification==
+
+scriptSig and scriptPubKey are hereby deemed to be deprecated.
+Bitcoin-compatible clients MUST still continue to support them for compatibility, but it should not be used for any new transaction types.
+Services and people which send Bitcoins SHOULD continue to support old pubkey-based addresses for the time being.
+Services and people which receive Bitcoins MAY continue to generate and use old pubkey-based addresses.
+
+To replace these, there are 3 new elements:
+* dataSig is included in place of scriptSig in transaction inputs, and contains multiple serialized data elements
+* scriptCheck is the final element of dataSig, and is executed with the preceding dataSig elements preloaded onto the stack (the element immediately before scriptCheck is the top of the stack)
+* hashScriptCheck is included in place of scriptPubKey in transaction outputs, to specify the hash of the scriptCheck allowed to redeem it
+
+dataSig is to be encoded the same as a push-only script.
+
+hashScriptCheck must be encoded exactly so:
+
+    0xa9 0x14 (20-byte-hash-value) 0x87
+
+This can be interpreted by legacy (pre-BIP 18) clients as the following script:
+
+    OP_HASH160 [20-byte-hash-value] OP_EQUAL
+
+If this template is not matched exactly OR the transaction is in a block with a timestamp before the hashScriptCheck activation date, validation MUST proceed in backward-compatibility mode, using scriptSig+scriptPubKey rather than dataSig+scriptCheck+hashScriptCheck.
+
+A hashScriptCheck-compliant input is valid only if:
+* dataSig MUST NOT contain any operations other than "push data" (it is data, not a script; no mixing scriptSig with hashScriptCheck)
+* scriptCheck MUST hash (using Bitcoin's Hash160 algorithm) to the output's hashScriptCheck.
+* scriptCheck MUST be executed with the dataSig-based stack specified above (ie, not including scriptCheck itself) to perform validation (this does not imply clients are required to validate transactions).
+* scriptCheck must not abort, and must leave a true value on the top of the stack. This is the current behaviour for scriptSig+scriptPubKey.
+
+The new scriptCheck SHOULD be checked against "standard transaction" templates by miners.
+
+For example, the hashScriptCheck and corresponding dataSig for a one-signature-required transaction is:
+
+    scriptCheck: [pubkey] OP_CHECKSIG
+    dataSig: [signature] {[pubkey] OP_CHECKSIG}
+    hashScriptCheck: [20-byte-hash of {[pubkey] OP_CHECKSIG}]
+
+===Signature operation limits for scriptCheck===
+
+Signature operations in scriptCheck do not follow the same rules previously applied to scriptSig and scriptPubKey.
+Instead, they shall contribute to the maximum number allowed per block (20,000) as follows:
+
+# OP_CHECKSIG and OP_CHECKSIGVERIFY count as 1 signature operation, whether or not they are evaluated.
+# OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY immediately preceded by OP_1 through OP_16 are counted as 1 to 16 signature operation, whether or not they are evaluated.
+# All other OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are counted as 20 signature operations.
+
+Examples:
+
++3 signature operations:
+    2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG
+
++22 signature operations
+    OP_CHECKSIG OP_IF OP_CHECKSIGVERIFY OP_ELSE OP_CHECKMULTISIGVERIFY OP_ENDIF
+
+==Rationale==
+
+This BIP replaces BIPs 12 and 17, which propose extensions to the Script system to allow scriptPubKey to outsource its verification.
+It also replaces BIP 16, which is identical in terms of protocol, but suggests a specific implementation and does not deprecate scriptPubKey to maintain protocol consistency.
+
+The Motivation for this BIP (and BIP 13, the pay-to-script-hash address type) is somewhat controversial; several people feel that it is unnecessary, and complex/multisignature transaction types should be supported by simply giving the sender the complete {serialized script}. The author believes that this BIP will minimize the changes needed to all of the supporting infrastructure that has already been created to send funds to a base58-encoded-20-byte bitcoin addresses, allowing merchants and exchanges and other software to start supporting multisignature transactions sooner.
+
+The signature operation counting rules are intended to be easy and quick to implement by statically scanning scriptCheck.
+Bitcoin imposes a maximum-number-of-signature-operations per block to prevent denial-of-service attacks on miners.
+If there was no limit, a rogue miner might broadcast a block that required hundreds of thousands of ECDSA signature operations to validate, and it might be able to get a head start computing the next block while the rest of the network worked to validate the current one.
+
+There is a 1-confirmation attack on old implementations, but it is expensive and difficult in practice. The attack is:
+
+# Attacker creates a pay-to-script-hash transaction that is valid when interpreted as scriptPubKey, but contains an invalid scriptCheck, and sends themselves some coins using it.
+# Attacker also creates a standard transaction that spends the pay-to-script transaction, and pays the victim who is running old software.
+# Attacker mines a block that contains both transactions.
+
+If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block.
+
+The attack is expensive because it requires the attacker create a block that they know will be invalidated by the rest of the network. It is difficult because creating blocks is difficult and users should not accept 1-confirmation transactions for higher-value transactions.
+
+==Backwards Compatibility==
+
+hashScriptCheck transactions are non-standard to old implementations, which will (typically) not relay them nor include them in blocks.
+
+Old implementations will validate that scriptCheck's hash value matches when they validate blocks created by software that fully support this BIP, but will do no other validation.
+
+Avoiding a block-chain split by malicious pay-to-script transactions requires careful handling of one case:
+
+* A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners.
+
+To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.
+
+To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create.
+
+At 00:00:00 UTC on 15 Mar 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If 550 or more contain "/P2SH/" in their coinbase, then all blocks with timestamps after 00:00:00 UTC on 1 Apr 2012 shall have their pay-to-script-hash transactions fully validated. Approximately 1,000 blocks are created in a week; 550 should, therefore, be approximately 55% of the network supporting the new feature.
+
+If a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved).
+
+==Forwards Compatibility ==
+The first two bytes of hashScriptCheck specify the hash algorithm and length used to verify scriptCheck.
+This BIP only allows Bitcoin's Hash160 algorithm, but leaves open the possibility of a future BIP implementing others.
+
+==Reference Implementation==
+
+https://github.com/gavinandresen/bitcoin-git/tree/pay_to_script_hash
+
+==See Also==
+
+* The [[BIP 0013|Address format for Pay to Script Hash BIP]]
+* [[BIP 16|BIP 16 - Pay to Script Hash (aka "/P2SH/")]]
+* M-of-N Multisignature Transactions [[BIP 0011|BIP 11]]
+
+[[Category:BIP]]

From 6a03bcba735c64d547de2c9e20c6c0597259a6c9 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Mon, 21 Oct 2013 00:46:12 -0400
Subject: [PATCH 012/181] Archive Revision as of 14:58, 18 January 2013

https://en.bitcoin.it/w/index.php?title=BIP_0019&oldid=35300
---
 bip-0019.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-0019.mediawiki b/bip-0019.mediawiki
index b17175ec..b653de8e 100644
--- a/bip-0019.mediawiki
+++ b/bip-0019.mediawiki
@@ -1,3 +1,5 @@
+{{bip}}
+
 
   BIP: 19
   Title: M-of-N Standard Transactions (Low SigOp)
@@ -67,4 +69,3 @@ Using OP_CHECKSIG only counts as 1 per signature, so can scale better.
 All used operations are already supported by old clients and miners as a non-standard transaction type.
 
 [[Category:BIP|C]]
-

From dc00d6cf02410bd1a4ba23c2c845ae8b9001fc59 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Mon, 21 Oct 2013 00:47:13 -0400
Subject: [PATCH 013/181] Archive Revision as of 10:39, 23 May 2013

https://en.bitcoin.it/w/index.php?title=BIP_0020&oldid=37954
---
 bip-0020.mediawiki | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/bip-0020.mediawiki b/bip-0020.mediawiki
index a96d8d03..3bd2605f 100644
--- a/bip-0020.mediawiki
+++ b/bip-0020.mediawiki
@@ -1,13 +1,15 @@
+{{bip}}
+
 
   BIP: 20
   Title: URI Scheme
   Author: Luke Dashjr 
-  Status: Rejected
+  Status: Replaced
   Type: Standards Track
   Created: 10-01-2011
 

 
-BIP 0020 is based off an earlier document by Nils Schneider.
+BIP 0020 is based off an earlier document by Nils Schneider. '''And has been replaced by BIP 0021'''
 
 ==Abstract==
 This BIP proposes a URI scheme for making Bitcoin payments.
@@ -208,4 +210,3 @@ This claims the money you were sent. Until your claim transaction has confirmed
 [[Category:Developer]]
 [[Category:Technical]]
 [[Category:BIP|D]]
-

From 86e1074d7fd4b4d67a373e662b68df2998a28cc5 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Mon, 21 Oct 2013 00:48:04 -0400
Subject: [PATCH 014/181] Archive Revision as of 18:45, 23 May 2013

https://en.bitcoin.it/w/index.php?title=BIP_0021&oldid=37974
---
 bip-0021.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki
index fa77e4b5..c4f3ef7a 100644
--- a/bip-0021.mediawiki
+++ b/bip-0021.mediawiki
@@ -1,3 +1,5 @@
+{{bip}}
+
 
   BIP: 21
   Title: URI Scheme
@@ -33,13 +35,12 @@ Graphical bitcoin clients SHOULD register themselves as the handler for the "bit
  bitcoinurn     = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]
  bitcoinaddress = base58 *base58
  bitcoinparams  = *bitcoinparam
- standardparam  = amountparam | labelparam | messageparam | otherparam
- bitcoinparam   = standardparam | reqparam
+ bitcoinparam   = amountparam | labelparam | messageparam | otherparam | reqparam
  amountparam    = "amount=" *digit [ "." *digit ]
  labelparam     = "label=" *pchar
  messageparam   = "message=" *pchar
  otherparam     = pchar *pchar "=" *pchar
- reqparam       = "req-" standardparam
+ reqparam       = "req-" pchar *pchar "=" *pchar
 
 === Query Keys ===
 
@@ -85,7 +86,7 @@ Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax.
 
 [foo] means optional,  are placeholders
 
- bitcoin:
[?amount=][?label=

 
 ==Abstract==
diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index 6f5dd456..c4d062ef 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -4,7 +4,7 @@
   Author: Mike Caldwell
   Status: Draft (Some confusion applies: The announcements for this never made it to the list, so it hasn't had public discussion)
   Type: Standards Track
-  Created: 20-11-2012
+  Created: 2012-11-20
 

 
 ==Abstract==
diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index a04a745e..cfa3bd50 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -8,7 +8,7 @@
            Sean Bowe 
   Status:  Draft
   Type:    Standards Track
-  Created: 10-09-2013
+  Created: 2013-09-10
 

 
 ==Abstract==
diff --git a/bip-0042.mediawiki b/bip-0042.mediawiki
index d48bcf73..d7ce71c4 100644
--- a/bip-0042.mediawiki
+++ b/bip-0042.mediawiki
@@ -4,7 +4,7 @@
   Author: Pieter Wuille 
   Status: Draft
   Type: Standards Track
-  Created: 01-04-2014
+  Created: 2014-04-01
 

 
 ==Abstract==
diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki
index ea5243d2..9ff29d6f 100644
--- a/bip-0050.mediawiki
+++ b/bip-0050.mediawiki
@@ -4,7 +4,7 @@
   Author: Gavin Andresen 
   Status: Draft
   Type: Informational
-  Created: 20-03-2013
+  Created: 2013-03-20
==What went wrong== diff --git a/bip-0060.mediawiki b/bip-0060.mediawiki index e23ecaed..ae9592ad 100644 --- a/bip-0060.mediawiki +++ b/bip-0060.mediawiki @@ -4,7 +4,7 @@ Author: Amir Taaki Status: Draft Type: Standards Track - Created: 16-06-2013 + Created: 2013-06-16 ==Abstract== diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index dfa40725..3f110509 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -4,7 +4,7 @@ Author: Pieter Wuille Status: Draft Type: Standards Track - Created: 12-03-2014 + Created: 2014-03-12 ==Abstract== diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 44611188..3e861db2 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -4,7 +4,7 @@ Author: Gavin Andresen Status: Draft Type: Standards Track - Created: 29-07-2013 + Created: 2013-07-29 ==Abstract== diff --git a/bip-0071.mediawiki b/bip-0071.mediawiki index 1fcb174d..44b4d3da 100644 --- a/bip-0071.mediawiki +++ b/bip-0071.mediawiki @@ -4,7 +4,7 @@ Author: Gavin Andresen Status: Draft Type: Standards Track - Created: 29-07-2013 + Created: 2013-07-29 ==Abstract== diff --git a/bip-0072.mediawiki b/bip-0072.mediawiki index 246a40c9..dae53f46 100644 --- a/bip-0072.mediawiki +++ b/bip-0072.mediawiki @@ -4,7 +4,7 @@ Author: Gavin Andresen Status: Draft Type: Standards Track - Created: 29-07-2013 + Created: 2013-07-29 ==Abstract== diff --git a/bip-0073.mediawiki b/bip-0073.mediawiki index 44143511..a020fb56 100644 --- a/bip-0073.mediawiki +++ b/bip-0073.mediawiki @@ -4,7 +4,7 @@ Author: Stephen Pair Status: Draft Type: Standards Track - Created: 27-08-2013 + Created: 2013-08-27 ==Abstract== From be336d352d9411f3b26dcac17b981029f25a383b Mon Sep 17 00:00:00 2001 From: Olivier Lalonde Date: Mon, 7 Apr 2014 00:15:29 +0800 Subject: [PATCH 095/181] Update bip-0032.mediawiki --- bip-0032.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 9ebaa3f0..fdc96138 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -2,7 +2,7 @@ RECENT CHANGES: * (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage) * (30 Apr 2013) Switched from multiplication by IL to addition of IL (faster, easier implementation) * (25 May 2013) Added test vectors -* (15 Jan 2014) Rename keys with index ≥ 0x8000000 to hardened keys, and add explicit covnersion functions. +* (15 Jan 2014) Rename keys with index ≥ 0x8000000 to hardened keys, and add explicit conversion functions. 
   BIP: 32

From e4556021dbcfb11834b8281677e9437a110844bf Mon Sep 17 00:00:00 2001
From: Aaron Voisine 
Date: Sat, 12 Apr 2014 00:07:46 -0700
Subject: [PATCH 096/181] Update bip-0038.mediawiki

fixed some typos that made the spec inconsistent and confusing to implement
---
 bip-0038.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index c4d062ef..6a81be3e 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -139,9 +139,9 @@ Steps to create new encrypted private keys given ''intermediate_passphrase_strin
 # Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
 # Now we will encrypt ''seedb''.  Derive a second key from ''passpoint'' using scrypt
 #*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes).  ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64.  The "+" operator is concatenation.
-#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
-# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
-# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''.  The "+" operator is concatenation.
+#*Split the result into two 32-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
+# Do AES256Encrypt(seedb[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
+# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedpart2''.  The "+" operator is concatenation.
 
 The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
 * 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''
@@ -163,7 +163,7 @@ A confirmation tool, given a passphrase and a confirmation code, can recalculate
 
 =====Decryption=====
 # Collect encrypted private key and passphrase from user.
-# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
+# Derive ''passfactor'' using scrypt with ''ownerentropy'' and the user's passphrase and use it to recompute ''passpoint''
 # Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
 # Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
 # Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.

From 1dc97a648ed0bc7ce4ebd416c29128814af68976 Mon Sep 17 00:00:00 2001
From: Andreas Schildbach 
Date: Sat, 12 Apr 2014 14:58:56 +0200
Subject: [PATCH 097/181] Define a deadline for returning funds via refund_to.

See discussion "BIP 70 refund field" on bitcoin-dev.
---
 bip-0070.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 3e861db2..4666ff65 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -145,7 +145,8 @@ Payment messages are sent after the customer has authorized payment:
 |-
 | transactions || One or more valid, signed Bitcoin transactions that fully pay the PaymentRequest
 |-
-| refund_to || One or more outputs where the merchant may return funds, if necessary.
+| refund_to || One or more outputs where the merchant may return funds, if necessary. The merchant may return funds using these outputs for up to 2 months
+after the time of the payment request. After that time has expired, parties must negotiate if returning of funds becomes necessary.
 |-
 | memo || UTF-8 encoded, plain-text note from the customer to the merchant.
 |}

From 86c90a9e792d16676ef14e1ac6e84f8f52c66ec8 Mon Sep 17 00:00:00 2001
From: Aaron Voisine 
Date: Sun, 13 Apr 2014 00:26:19 -0700
Subject: [PATCH 098/181] Update bip-0038.mediawiki

Updated Authors
---
 bip-0038.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index 6a81be3e..39f06325 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -1,7 +1,8 @@
 
   BIP: 38
   Title: Passphrase-protected private key
-  Author: Mike Caldwell
+  Authors: Mike Caldwell
+           Aaron Voisine 
   Status: Draft (Some confusion applies: The announcements for this never made it to the list, so it hasn't had public discussion)
   Type: Standards Track
   Created: 2012-11-20

From 4964569a67ea9b2ebf6ee61e5749ce6376620f90 Mon Sep 17 00:00:00 2001
From: Andreas Schildbach 
Date: Sat, 1 Mar 2014 00:03:02 +0100
Subject: [PATCH 099/181] Require including intermediate certificates in a
 BIP70 payment request.

---
 bip-0070.mediawiki | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 3e861db2..0bf10e22 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -221,10 +221,11 @@ used.
 
 Each certificate is a DER [ITU.X690.1994] PKIX certificate value. The
 certificate containing the public key of the entity that digitally
-signed the PaymentRequest must be the first certificate. This MAY be
+signed the PaymentRequest must be the first certificate. This MUST be
 followed by additional certificates, with each subsequent certificate
-being the one used to certify the previous one, up to a trusted root
-authority.  The recipient must verify the certificate chain according to
+being the one used to certify the previous one, up to (but not
+including) a trusted root authority. The trusted root authority MAY be
+included. The recipient must verify the certificate chain according to
 [RFC5280] and reject the PaymentRequest if any validation failure
 occurs.
 

From 4a85b38916278100b921a64e409b78b71ba37690 Mon Sep 17 00:00:00 2001
From: MidnightLightning 
Date: Wed, 5 Mar 2014 17:04:00 -0500
Subject: [PATCH 100/181] Update bip-0038.mediawiki

Fix some erroneous statements in the description of the math used for encryption/decryption of EC-Multiplied keys/addresses
---
 bip-0038.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index 39f06325..f34a09b4 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -121,7 +121,7 @@ Steps performed by ''owner'' to generate a single intermediate code, if lot and
 # Derive a key from the passphrase using scrypt
 #* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8.  salt is ''ownersalt''. n=16384, r=8, p=8, length=32.
 #* Call the resulting 32 bytes ''prefactor''.
-#* Take SHA256(SHA256(''prefactor'' + ''ownerentropy'')) and call this ''passfactor''.
+#* Take SHA256(SHA256(''prefactor'' + ''ownerentropy'')) and call this ''passfactor''. The "+" operator is concatenation.
 # Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes).  Call this ''passpoint''.  Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
 # Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
 #* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownerentropy'', and then ''passpoint''.  The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint'').  The checksum is handled in the Base58Check encoding.  The resulting string is called ''intermediate_passphrase_string''.
@@ -164,8 +164,8 @@ A confirmation tool, given a passphrase and a confirmation code, can recalculate
 
 =====Decryption=====
 # Collect encrypted private key and passphrase from user.
-# Derive ''passfactor'' using scrypt with ''ownerentropy'' and the user's passphrase and use it to recompute ''passpoint''
-# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt''
+# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
+# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownerentropy''
 # Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
 # Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
 # Use ''seedb'' to compute ''factorb''.

From a0d6bb343395abf46126c647771a556a32bd65c3 Mon Sep 17 00:00:00 2001
From: Brooks Boyd 
Date: Tue, 15 Apr 2014 16:31:01 -0500
Subject: [PATCH 101/181] Add test case for UTF8 NFC normalization

---
 bip-0038.mediawiki | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index f34a09b4..748cb9b7 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -252,6 +252,12 @@ Test 2:
 *Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
 *Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A
 
+Test 3:
+*Passphrase `\u03D2\u0301\u0000\U00010400\U0001F4A9`; [http://codepoints.net/U+03D2 GREEK UPSILON WITH HOOK], [http://codepoints.net/U+0301 COMBINING ACUTE ACCENT], [http://codepoints.net/U+0000 NULL], [http://codepoints.net/U+10400 DESERET CAPITAL LETTER LONG I], [http://codepoints.net/U+1F4A9 PILE OF POO]
+*Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn
+*Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
+*Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
+
 ===EC multiply, no compression, lot/sequence numbers===
 
 Test 1:
@@ -273,4 +279,3 @@ Test 2:
 *Unencrypted private key (hex): CA2759AA4ADB0F96C414F36ABEB8DB59342985BE9FA50FAAC228C8E7D90E3006
 *Confirmation code: cfrm38V8G4qq2ywYEFfWLD5Cc6msj9UwsG2Mj4Z6QdGJAFQpdatZLavkgRd1i4iBMdRngDqDs51
 *Lot/Sequence: 806938/1
-

From ab85705d40b3a229020c3c511e66c03cf0f379b7 Mon Sep 17 00:00:00 2001
From: Brooks Boyd 
Date: Tue, 15 Apr 2014 16:38:37 -0500
Subject: [PATCH 102/181] Add normalization note on test case

---
 bip-0038.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index 748cb9b7..29075ad3 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -253,10 +253,11 @@ Test 2:
 *Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A
 
 Test 3:
-*Passphrase `\u03D2\u0301\u0000\U00010400\U0001F4A9`; [http://codepoints.net/U+03D2 GREEK UPSILON WITH HOOK], [http://codepoints.net/U+0301 COMBINING ACUTE ACCENT], [http://codepoints.net/U+0000 NULL], [http://codepoints.net/U+10400 DESERET CAPITAL LETTER LONG I], [http://codepoints.net/U+1F4A9 PILE OF POO]
+*Passphrase \u03D2\u0301\u0000\U00010400\U0001F4A9; [http://codepoints.net/U+03D2 GREEK UPSILON WITH HOOK], [http://codepoints.net/U+0301 COMBINING ACUTE ACCENT], [http://codepoints.net/U+0000 NULL], [http://codepoints.net/U+10400 DESERET CAPITAL LETTER LONG I], [http://codepoints.net/U+1F4A9 PILE OF POO]
 *Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn
 *Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
 *Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
+* ''Note:'' The non-standard UTF-8 characters in this passphrase should be NFC normalized to result in a passphrase of 0xcf9300f0909080f09f92a9 before further processing
 
 ===EC multiply, no compression, lot/sequence numbers===
 

From d69abd64e13dd118ba011b348e0194315d748320 Mon Sep 17 00:00:00 2001
From: Brooks Boyd 
Date: Tue, 15 Apr 2014 16:45:03 -0500
Subject: [PATCH 103/181] Attempt to put the actual characters in the source
 file

---
 bip-0038.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index 29075ad3..1fd9d912 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -243,7 +243,7 @@ Test 1:
 *Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
 *Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
 *Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519
- 
+
 Test 2:
 *Passphrase: Satoshi
 *Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
@@ -253,7 +253,7 @@ Test 2:
 *Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A
 
 Test 3:
-*Passphrase \u03D2\u0301\u0000\U00010400\U0001F4A9; [http://codepoints.net/U+03D2 GREEK UPSILON WITH HOOK], [http://codepoints.net/U+0301 COMBINING ACUTE ACCENT], [http://codepoints.net/U+0000 NULL], [http://codepoints.net/U+10400 DESERET CAPITAL LETTER LONG I], [http://codepoints.net/U+1F4A9 PILE OF POO]
+*Passphrase ϓ␀𐐀💩 (\u03D2\u0301\u0000\U00010400\U0001F4A9; [http://codepoints.net/U+03D2 GREEK UPSILON WITH HOOK], [http://codepoints.net/U+0301 COMBINING ACUTE ACCENT], [http://codepoints.net/U+0000 NULL], [http://codepoints.net/U+10400 DESERET CAPITAL LETTER LONG I], [http://codepoints.net/U+1F4A9 PILE OF POO])
 *Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn
 *Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
 *Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4

From 4058075acd4f377c78bd61840e933f77d4525b5f Mon Sep 17 00:00:00 2001
From: Aaron Voisine 
Date: Wed, 16 Apr 2014 15:11:54 -0700
Subject: [PATCH 104/181] steps to recalculate address from confirmation code

also fixed some typos
---
 bip-0038.mediawiki | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index 39f06325..7c38222b 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -88,7 +88,7 @@ Encrypting a private key without the EC multiplication offers the advantage that
 Encryption steps:
 # Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it.  Let's call this "addresshash".
 # Derive a key from the passphrase using scrypt
-#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8.  ''addresshash'' came from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
+#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8.  salt is ''addresshash'' from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
 #*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
 # Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
 # Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''
@@ -124,7 +124,7 @@ Steps performed by ''owner'' to generate a single intermediate code, if lot and
 #* Take SHA256(SHA256(''prefactor'' + ''ownerentropy'')) and call this ''passfactor''.
 # Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes).  Call this ''passpoint''.  Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
 # Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
-#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownerentropy'', and then ''passpoint''.  The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownersalt'' + 33 bytes ''passpoint'').  The checksum is handled in the Base58Check encoding.  The resulting string is called ''intermediate_passphrase_string''.
+#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownerentropy'', and then ''passpoint''.  The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownerentropy'' + 33 bytes ''passpoint'').  The checksum is handled in the Base58Check encoding.  The resulting string is called ''intermediate_passphrase_string''.
 
 If lot and sequence numbers are not being included, then follow the same procedure with the following changes:
 * ''ownersalt'' is 8 random bytes instead of 4, and ''lotsequence'' is omitted.  ''ownerentropy'' becomes an alias for ''ownersalt''.
@@ -162,6 +162,12 @@ The result is a Base58Check-encoded concatenation of the following:
 
 A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase".  If applicable: "The lot number is ''lotnumber'' and the sequence number is ''sequencenumber''."
 
+To recalculate the address:
+# Derive ''passfactor'' using scrypt with ''ownerentropy'' and the user's passphrase and use it to recompute ''passpoint''
+# Derive decryption key for ''pointb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownerentropy''
+# Decrypt ''encryptedpointb'' to yield ''pointb''
+# ECMultiply ''pointb'' by ''passfactor''. Use the resulting EC point as a public key and hash it into ''address'' using either compressed or uncompressed public key methodology as specifid in ''flagbyte''.
+
 =====Decryption=====
 # Collect encrypted private key and passphrase from user.
 # Derive ''passfactor'' using scrypt with ''ownerentropy'' and the user's passphrase and use it to recompute ''passpoint''

From 4a58190577098c9caeda6a4028c90e53cfcc2bb0 Mon Sep 17 00:00:00 2001
From: Jud Stephenson 
Date: Fri, 28 Feb 2014 12:28:09 -0500
Subject: [PATCH 105/181] Adding additional implementations

---
 bip-0039.mediawiki | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index cfa3bd50..2fd8ad0d 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -123,3 +123,7 @@ Reference implementation including wordlists is available from
 
 http://github.com/trezor/python-mnemonic
 
+==Other Implementations==
+
+Objective-C - https://github.com/nybex/NYMnemonic
+

From 39b441f2ff18e7dcf71f357e43e4dd78a1b198b1 Mon Sep 17 00:00:00 2001
From: slush0 
Date: Wed, 9 Apr 2014 15:59:32 +0200
Subject: [PATCH 106/181] introduce BIP-0043 and BIP-0044

---
 README.mediawiki   |  13 ++-
 bip-0043.mediawiki |  61 +++++++++++
 bip-0044.mediawiki | 261 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 334 insertions(+), 1 deletion(-)
 create mode 100644 bip-0043.mediawiki
 create mode 100644 bip-0044.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index 816531b3..3103d74d 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -180,7 +180,18 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille
 | Standard
 | Draft
-
+|-
+| [[bip-0043.mediawiki|43]]
+| Purpose Field for Deterministic Wallets
+| Slush
+| Standard
+| Draft
+|-
+| [[bip-0044.mediawiki|44]]
+| Multi-Account Hierarchy for Deterministic Wallets
+| Slush
+| Standard
+| Draft
 |-
 | [[bip-0050.mediawiki|50]]
 | March 2013 Chain Fork Post-Mortem
diff --git a/bip-0043.mediawiki b/bip-0043.mediawiki
new file mode 100644
index 00000000..24dcb82b
--- /dev/null
+++ b/bip-0043.mediawiki
@@ -0,0 +1,61 @@
+
+  BIP:     BIP-0043
+  Title:   Purpose Field for Deterministic Wallets
+  Authors: Marek Palatinus 
+           Pavol Rusnak 
+  Status:  Draft
+  Type:    Standards Track
+  Created: 24-04-2014
+

+
+==Abstract==
+
+This BIP introduces a "Purpose Field" for use in deterministic wallets
+based on algorithm described in BIP-0032 (BIP32 from now on).
+
+==Motivation==
+
+Although Hierarchical Deterministic Wallet structure as described by BIP32
+is an important step in user experience and security of the cryptocoin wallets,
+the BIP32 specification offers implementors too many degrees of freedom.
+Multiple implementations may claim they are BIP32 compatible, but in fact
+they can produce wallets with different logical structures making them
+non-interoperable. This situation unfortunately renders "BIP32 compatible"
+statement rather useless.
+
+
+==Purpose==
+
+We propose the first level of BIP32 tree structure to be used as "purpose".
+This purpose determines the further structure beneath this node.
+
+
+m / purpose' / *
+

+
+Apostrophe indicates that BIP32 hardened derivation is used.
+
+We encourage different schemes to apply for assigning a separate BIP number
+and use the same number for purpose field, so addresses won't be generated
+from overlapping BIP32 spaces.
+
+Example: Scheme described in BIP44 should use 44' (or 0x8000002C) as purpose.
+
+Not all wallets may want to support the full range of features and possibilities
+described in these BIPs. Instead of choosing arbitrary subset of defined features
+and calling themselves BIPxx compatible, we suggest that software which needs
+only a limited structure should describe such structure in another BIP and use
+different "purpose" value.
+
+
+==Master node serialization==
+
+Because this scheme can be used to generate nodes for more cryptocurrencies
+at once, or even something totally unrelated to cryptocurrencies, there's no
+point in using a special version magic described in section "Serialization
+format" of BIP32. We suggest to use always 0x0488B21E for public and 0x0488ADE4
+for private nodes (leading to prefixes "xpub" and "xprv" respectively).
+
+==Reference==
+
+* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
new file mode 100644
index 00000000..850404e5
--- /dev/null
+++ b/bip-0044.mediawiki
@@ -0,0 +1,261 @@
+
+  BIP:     BIP-0044
+  Title:   Multi-Account Hierarchy for Deterministic Wallets
+  Authors: Marek Palatinus 
+           Pavol Rusnak 
+  Status:  Draft
+  Type:    Standards Track
+  Created: 24-04-2014
+

+
+==Abstract==
+
+This BIP defines logical hierarchy for deterministic wallets based on algorithm
+described in BIP-0032 (BIP32 from now on) and purpose scheme described in
+BIP-0043 (BIP43 from now on).
+
+This BIP is a particular application of BIP43.
+
+==Motivation==
+
+Hierarchy proposed in this paper is quite comprehensive. It allows to handle
+multiple coins, multiple accounts, external and internal chains per account and
+millions of addresses per chain.
+
+==Path levels==
+
+We define the following 5 levels in BIP32 path:
+
+
+m / purpose' / coin_type' / account' / change / address_index
+

+
+Apostrophe in the path indicates that BIP32 hardened derivation is used.
+
+Each level has special meaning described in the chapters below.
+
+===Purpose===
+
+Purpose is a constant set to 44' (or 0x8000002C) following the BIP43 recommendation.
+It indicates that the subtree of this node is used according to this specification.
+
+Hardened derivation is used at this level.
+
+===Coin type===
+
+One master node (seed) can be used for unlimited number of independent
+cryptocoins such as Bitcoin, Litecoin or Namecoin. However, sharing the same
+space for various cryptocoins has some disadvantages.
+
+This level creates a separate subtree for every cryptocoin, avoiding
+reusing addresses across cryptocoins and improving privacy issues.
+
+Coin type is a constant set for each cryptocoin. Cryptocoin developers may ask
+for registering unused number for their project.
+
+The list of already allocated coin types is in the chapter
+"Registered coin types" below.
+
+Hardened derivation is used at this level.
+
+===Account===
+
+This level splits the key space into independent user identities,
+so the wallet never mixes the coins across different accounts.
+
+User can use these accounts to organize the funds in the same
+fashion like bank accounts; for donation purposes (where all
+addresses are considered public), for saving purposes,
+for common expenses etc.
+
+Accounts are numbered from index 0 in sequentially increasing manner.
+This number is used as child index in BIP32 derivation.
+
+Hardened derivation is used at this level.
+
+Software should prevent a creation of an account if previous account does not
+have a transaction history (meaning no its address has been used before).
+
+Software needs to discover all used accounts after importing the seed from
+an external source. Such algorithm is described in "Account discovery" chapter.
+
+===Change===
+
+Constant 0 is used for external chain and constant 1 for internal chain (also
+known as change addresses). External chain is used for addresses that are meant
+to be visible outside of the wallet (e.g. for receiving payments). Internal
+chain is used for addresses which are not meant to be visible outside of the
+wallet and is used for return transaction change.
+
+Public derivation is used at this level.
+
+===Index===
+
+Addresses are numbered from index 0 in sequentially increasing manner.
+This number is used as child index in BIP32 derivation.
+
+Public derivation is used at this level.
+
+==Account discovery==
+
+When the master seed is imported from an external source the software should
+start to discover the accounts in the following manner:
+
+# derive the first account's node (index = 0)
+# derive the external chain node of this account
+# scan addresses of the external chain; respect the gap limit described below
+# if no transactions are found on the external chain stop discovery
+# if there are some transactions, increase the account index and go to step 1
+
+This algorithm is correct, because software should disallow creation of new
+accounts if previous one has no transaction history as described in chapter
+"Account" above.
+
+Please note that the algorithm works with the transaction history, not account
+balances, so you can have account with total 0 coins and the algorithm will
+still continue with discovery.
+
+===Address gap limit===
+
+Address gap limit is currently set to 20. If the software hits 20 unused
+addresses in a row, it expects there are no used addresses beyond this point
+and stops searching the address chain.
+
+Wallet software should warn when user is trying to exceed the gap limit on
+an external chain by generating a new address.
+
+==Registered coin types==
+
+These are the registered coin types for usage in level 2 of BIP44 described in
+chapter "Coin type" above.
+
+All these constants are used as hardened derivation.
+
+{|
+!index
+!hexa
+!coin
+|-
+|0
+|0x80000000
+|Bitcoin
+|-
+|1
+|0x80000001
+|Bitcoin Testnet
+|}
+
+==Examples==
+
+{|
+!coin
+!account
+!chain
+!address
+!path
+|-
+|Bitcoin
+|first
+|external
+|first
+|m / 44' / 0' / 0' / 0 / 0
+|-
+|Bitcoin
+|first
+|external
+|second
+|m / 44' / 0' / 0' / 0 / 1
+|-
+|Bitcoin
+|first
+|change
+|first
+|m / 44' / 0' / 0' / 1 / 0
+|-
+|Bitcoin
+|first
+|change
+|second
+|m / 44' / 0' / 0' / 1 / 1
+|-
+|Bitcoin
+|second
+|external
+|first
+|m / 44' / 0' / 1' / 0 / 0
+|-
+|Bitcoin
+|second
+|external
+|second
+|m / 44' / 0' / 1' / 0 / 1
+|-
+|Bitcoin
+|second
+|change
+|first
+|m / 44' / 0' / 1' / 1 / 0
+|-
+|Bitcoin
+|second
+|change
+|second
+|m / 44' / 0' / 1' / 1 / 1
+|-
+|Bitcoin Testnet
+|first
+|external
+|first
+|m / 44' / 1' / 0' / 0 / 0
+|-
+|Bitcoin Testnet
+|first
+|external
+|second
+|m / 44' / 1' / 0' / 0 / 1
+|-
+|Bitcoin Testnet
+|first
+|change
+|first
+|m / 44' / 1' / 0' / 1 / 0
+|-
+|Bitcoin Testnet
+|first
+|change
+|second
+|m / 44' / 1' / 0' / 1 / 1
+|-
+|Bitcoin Testnet
+|second
+|external
+|first
+|m / 44' / 1' / 1' / 0 / 0
+|-
+|Bitcoin Testnet
+|second
+|external
+|second
+|m / 44' / 1' / 1' / 0 / 1
+|-
+|Bitcoin Testnet
+|second
+|change
+|first
+|m / 44' / 1' / 1' / 1 / 0
+|-
+|Bitcoin Testnet
+|second
+|change
+|second
+|m / 44' / 1' / 1' / 1 / 1
+|}
+
+==Compatible walets==
+
+* [[https://mytrezor.com|myTREZOR web wallet]] ([[https://github.com/trezor/webwallet|source]])
+
+==Reference==
+
+* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
+* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]

From 585b1c31aa7e0a3f13456f1119c5157be9384090 Mon Sep 17 00:00:00 2001
From: slush0 
Date: Thu, 24 Apr 2014 13:56:27 +0200
Subject: [PATCH 107/181] Fixed date format

---
 bip-0043.mediawiki | 2 +-
 bip-0044.mediawiki | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0043.mediawiki b/bip-0043.mediawiki
index 24dcb82b..5fc20fe9 100644
--- a/bip-0043.mediawiki
+++ b/bip-0043.mediawiki
@@ -5,7 +5,7 @@
            Pavol Rusnak 
   Status:  Draft
   Type:    Standards Track
-  Created: 24-04-2014
+  Created: 2014-04-24
 

 
 ==Abstract==
diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index 850404e5..5444099b 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -5,7 +5,7 @@
            Pavol Rusnak 
   Status:  Draft
   Type:    Standards Track
-  Created: 24-04-2014
+  Created: 2014-04-24
==Abstract== From 22646636dd79518691a5ba5ed51bc35a84d11d49 Mon Sep 17 00:00:00 2001 From: Ross Nicoll Date: Sat, 26 Apr 2014 16:25:22 +0100 Subject: [PATCH 108/181] Replaced example domain name with example.com. --- bip-0070.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 3e861db2..1ee56bd2 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -25,7 +25,7 @@ The current, minimal Bitcoin payment protocol operates as follows: This BIP extends the above protocol to support several new features: -# Human-readable, secure payment destinations-- customers will be asked to authorize payment to "website.com" instead of an inscrutable, 34-character bitcoin address. +# Human-readable, secure payment destinations-- customers will be asked to authorize payment to "example.com" instead of an inscrutable, 34-character bitcoin address. # Secure proof of payment, which the customer can use in case of a dispute with the merchant. # Resistance from man-in-the-middle attacks that replace a merchant's bitcoin address with an attacker's address before a transaction is authorized with a hardware wallet. # Payment received messages, so the customer knows immediately that the merchant has received, and has processed (or is processing) their payment. From 694314d296cff6871b9e58c2b2b8f07305cb8a4a Mon Sep 17 00:00:00 2001 From: Ross Nicoll Date: Sat, 26 Apr 2014 16:44:13 +0100 Subject: [PATCH 109/181] Added file size limits for Payment and PaymentACK messages. --- bip-0070.mediawiki | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 1ee56bd2..84a85593 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -172,6 +172,9 @@ determine whether or not the transactions satisfy conditions of payment. If and only if they do, if should broadcast the transaction(s) on the Bitcoin p2p network. +Payment messages larger than 50,000 bytes should be rejected by +the merchant's server, to mitigate denial-of-service attacks. + ===PaymentACK=== PaymentACK is the final message in the payment protocol; it is sent @@ -189,6 +192,11 @@ Payment message: | memo || UTF-8 encoded note that should be displayed to the customer giving the status of the transaction (e.g. "Payment of 1 BTC for eleven tribbles accepted for processing.") |} +PaymentACK messages larger than 60,000 bytes should be rejected by +the wallet application, to mitigate denial-of-service attacks. This +is larger than the limits on Payment and PaymentRequest messages +as PaymentACK contains a full Payment message within it. + ==Localization== Merchants that support multiple languages should generate From d8bd74baf841f0d82a1b2b8af8ece37df50b06d4 Mon Sep 17 00:00:00 2001 From: Ross Nicoll Date: Sat, 26 Apr 2014 16:59:23 +0100 Subject: [PATCH 110/181] Added note about handling multiple copies of a Payment message, to ensure resend is safe in case of a transport layer failure. --- bip-0070.mediawiki | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 84a85593..b541cbcd 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -156,6 +156,11 @@ If the customer authorizes payment, then the Bitcoin client: # If PaymentDetails.payment_url is specified, POST a Payment message to that URL. The Payment message is serialized and sent as the body of the POST request. Errors communicating with the payment_url server should be communicated to the user. +The merchant's server should handle receiving multiple copies of the same Payment +message in response to a single PaymentRequest. This is required to ensure that in +case of a transport level failure during transmission, recovery is possible by +re-sending the Payment message. The endpoint URL must remain valid for at least +the same period of time as the original PaymentRequest. PaymentDetails.payment_url should be secure against man-in-the-middle attacks that might alter Payment.refund_to (if using HTTP, it must be From d3d1f242fd13527137f01310458132c5a324e79a Mon Sep 17 00:00:00 2001 From: Ross Nicoll Date: Sat, 26 Apr 2014 17:34:03 +0100 Subject: [PATCH 111/181] Added reference to RFC 2616 to BIP0072. --- bip-0072.mediawiki | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/bip-0072.mediawiki b/bip-0072.mediawiki index dae53f46..e4ed52f3 100644 --- a/bip-0072.mediawiki +++ b/bip-0072.mediawiki @@ -38,7 +38,9 @@ described in BIP 70. Bitcoin wallets must support fetching PaymentRequests via http and https protocols; they may support other protocols. Wallets must -include an Accept HTTP header in HTTP(s) requests: +include an "Accept" HTTP header in HTTP(s) requests (as defined +in RFC 2616): + 
Accept: application/bitcoin-paymentrequest
If a PaymentRequest cannot be obtained (perhaps the server is @@ -59,3 +61,7 @@ Non-backwards-compatible equivalent: 
 bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
+ +==References== + +[[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1 \ No newline at end of file From e91d87919bf3cce6d0dcd5c5bf1960c65129c0a5 Mon Sep 17 00:00:00 2001 From: Ross Nicoll Date: Sat, 26 Apr 2014 17:39:26 +0100 Subject: [PATCH 112/181] Added note about handling HTTP statuses which are neither error nor success. --- bip-0072.mediawiki | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bip-0072.mediawiki b/bip-0072.mediawiki index e4ed52f3..8617dbe4 100644 --- a/bip-0072.mediawiki +++ b/bip-0072.mediawiki @@ -45,7 +45,9 @@ in RFC 2616): If a PaymentRequest cannot be obtained (perhaps the server is unavailable), then the customer should be informed that the merchant's -payment processing system is unavailable. +payment processing system is unavailable. In the case of an HTTP +request, status codes which are neither success nor error (such as +redirect) should be handled as outlined in RFC 2616. ==Compatibility== From 89050ce1462f7a18898c884503966a9cf6f1f22b Mon Sep 17 00:00:00 2001 From: Ross Nicoll Date: Sun, 27 Apr 2014 00:43:47 +0100 Subject: [PATCH 113/181] Expanded and clarified wording on recovering from error states when sending payment to the merchant's server. --- bip-0070.mediawiki | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index b541cbcd..747295ce 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -99,6 +99,12 @@ about the merchant and a digital signature. | merchant_data || Arbitrary data that may be used by the merchant to identify the PaymentRequest. May be omitted if the merchant does not need to associate Payments with PaymentRequest or if they associate each PaymentRequest with a separate payment address. |} +The payment_url specified in the PaymentDetails must remain valid at least until the PaymentDetails +expires (or indefinitely if the PaymentDetails does not expire). Note that this is irrespective of +any state change in the underlying payment request; for example cancellation of an order should not +invalidate the payment_url, as it is important that the merchant's server can record mis-payments +in order to refund the payment. + A PaymentRequest is PaymentDetails optionally tied to a merchant's identity: 
     message PaymentRequest {
@@ -156,11 +162,13 @@ If the customer authorizes payment, then the Bitcoin client:
 # If PaymentDetails.payment_url is specified, POST a Payment message to that URL. The Payment message is serialized and sent as the body of the POST request.
 
 Errors communicating with the payment_url server should be communicated to the user.
-The merchant's server should handle receiving multiple copies of the same Payment
-message in response to a single PaymentRequest. This is required to ensure that in
-case of a transport level failure during transmission, recovery is possible by
-re-sending the Payment message. The endpoint URL must remain valid for at least
-the same period of time as the original PaymentRequest.
+In the scenario where the merchant's server receives multiple identical Payment
+messages for an individual PaymentRequest, it must acknowledge each. The second
+and further PaymentACK messages sent from the merchant's server may vary by memo
+field to indicate current state of the Payment (for example number of confirmations
+seen on the network). This is required in order to ensure that in case of a transport
+level failure during transmission, recovery is possible by the Bitcoin client
+re-sending the Payment message.
 
 PaymentDetails.payment_url should be secure against man-in-the-middle
 attacks that might alter Payment.refund_to (if using HTTP, it must be

From 3cbf3d7c030851e67b261e3a561b5490aaf7b8ab Mon Sep 17 00:00:00 2001
From: "David A. Harding" 
Date: Sat, 26 Apr 2014 20:26:22 -0400
Subject: [PATCH 114/181] Update bip-0070.mediawiki

Change "zero-byte placeholder" to "empty string"
---
 bip-0070.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 39888391..778b80fe 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -118,7 +118,7 @@ A PaymentRequest is PaymentDetails optionally tied to a merchant's identity:
 |-
 | serialized_payment_details || A protocol-buffer serialized PaymentDetails message.
 |-
-| signature || digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message, with all fields serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order) and signed using the public key in pki_data.  Before serialization, the signature field must be set to a zero-byte placeholder.
+| signature || digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message, with all fields serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order) and signed using the public key in pki_data.  Before serialization, the signature field must be set to an empty string.
 |}
 When a Bitcoin wallet application receives a PaymentRequest, it must authorize payment by doing the following:
 

From 67634c57d05e1eba18dc5946f8aed559d1888cd0 Mon Sep 17 00:00:00 2001
From: Pavol Rusnak 
Date: Thu, 24 Apr 2014 16:38:54 +0200
Subject: [PATCH 115/181] fix typos in BIP-0043 and BIP-0044

---
 bip-0043.mediawiki | 2 +-
 bip-0044.mediawiki | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0043.mediawiki b/bip-0043.mediawiki
index 5fc20fe9..14936f63 100644
--- a/bip-0043.mediawiki
+++ b/bip-0043.mediawiki
@@ -48,7 +48,7 @@ only a limited structure should describe such structure in another BIP and use
 different "purpose" value.
 
 
-==Master node serialization==
+==Node serialization==
 
 Because this scheme can be used to generate nodes for more cryptocurrencies
 at once, or even something totally unrelated to cryptocurrencies, there's no
diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index 5444099b..5e8351b0 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -74,7 +74,7 @@ This number is used as child index in BIP32 derivation.
 Hardened derivation is used at this level.
 
 Software should prevent a creation of an account if previous account does not
-have a transaction history (meaning no its address has been used before).
+have a transaction history (meaning none of its addresses have been used before).
 
 Software needs to discover all used accounts after importing the seed from
 an external source. Such algorithm is described in "Account discovery" chapter.

From 9d8e00207125d844e49e25b0fefeefa263287f2c Mon Sep 17 00:00:00 2001
From: Ross Nicoll 
Date: Sun, 27 Apr 2014 21:08:44 +0100
Subject: [PATCH 116/181] Loosened URL validity period on payment requests.

---
 bip-0070.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 747295ce..a65e5a5e 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -99,8 +99,8 @@ about the merchant and a digital signature.
 | merchant_data || Arbitrary data that may be used by the merchant to identify the PaymentRequest. May be omitted if the merchant does not need to associate Payments with PaymentRequest or if they associate each PaymentRequest with a separate payment address.
 |}
 
-The payment_url specified in the PaymentDetails must remain valid at least until the PaymentDetails
-expires (or indefinitely if the PaymentDetails does not expire). Note that this is irrespective of
+The payment_url specified in the PaymentDetails should remain valid at least until the PaymentDetails
+expires (or as long as possible if the PaymentDetails does not expire). Note that this is irrespective of
 any state change in the underlying payment request; for example cancellation of an order should not
 invalidate the payment_url, as it is important that the merchant's server can record mis-payments
 in order to refund the payment.

From 917838608c08b80ac1a6a9f2ba9e40453aa0bc6c Mon Sep 17 00:00:00 2001
From: "David A. Harding" 
Date: Mon, 28 Apr 2014 14:56:30 -0400
Subject: [PATCH 117/181] Update bip-0070.mediawiki

Revised final sentence of signature field description.
---
 bip-0070.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 778b80fe..5bfb12bb 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -118,7 +118,7 @@ A PaymentRequest is PaymentDetails optionally tied to a merchant's identity:
 |-
 | serialized_payment_details || A protocol-buffer serialized PaymentDetails message.
 |-
-| signature || digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message, with all fields serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order) and signed using the public key in pki_data.  Before serialization, the signature field must be set to an empty string.
+| signature || digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message, with all fields serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order) and signed using the public key in pki_data.  Before serialization, the signature field must be set to an empty value so that the field is included in the signed PaymentRequest hash but contains no data.
 |}
 When a Bitcoin wallet application receives a PaymentRequest, it must authorize payment by doing the following:
 

From 8919394624565808e29d815080a861f0cfc0291c Mon Sep 17 00:00:00 2001
From: e4xit 
Date: Tue, 29 Apr 2014 09:35:33 +0100
Subject: [PATCH 118/181] Minor grammatical & spelling corrections

---
 bip-0044.mediawiki | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index 5e8351b0..52294353 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -10,7 +10,7 @@
 
 ==Abstract==
 
-This BIP defines logical hierarchy for deterministic wallets based on algorithm
+This BIP defines a logical hierarchy for deterministic wallets based on an algorithm
 described in BIP-0032 (BIP32 from now on) and purpose scheme described in
 BIP-0043 (BIP43 from now on).
 
@@ -18,7 +18,7 @@ This BIP is a particular application of BIP43.
 
 ==Motivation==
 
-Hierarchy proposed in this paper is quite comprehensive. It allows to handle
+The hierarchy proposed in this paper is quite comprehensive. It allows the handling of
 multiple coins, multiple accounts, external and internal chains per account and
 millions of addresses per chain.
 
@@ -32,7 +32,7 @@ m / purpose' / coin_type' / account' / change / address_index
 
 Apostrophe in the path indicates that BIP32 hardened derivation is used.
 
-Each level has special meaning described in the chapters below.
+Each level has a special meaning, described in the chapters below.
 
 ===Purpose===
 
@@ -50,7 +50,7 @@ space for various cryptocoins has some disadvantages.
 This level creates a separate subtree for every cryptocoin, avoiding
 reusing addresses across cryptocoins and improving privacy issues.
 
-Coin type is a constant set for each cryptocoin. Cryptocoin developers may ask
+Coin type is a constant, set for each cryptocoin. Cryptocoin developers may ask
 for registering unused number for their project.
 
 The list of already allocated coin types is in the chapter
@@ -63,8 +63,8 @@ Hardened derivation is used at this level.
 This level splits the key space into independent user identities,
 so the wallet never mixes the coins across different accounts.
 
-User can use these accounts to organize the funds in the same
-fashion like bank accounts; for donation purposes (where all
+Users can use these accounts to organize the funds in the same
+fashion as bank accounts; for donation purposes (where all
 addresses are considered public), for saving purposes,
 for common expenses etc.
 
@@ -73,11 +73,11 @@ This number is used as child index in BIP32 derivation.
 
 Hardened derivation is used at this level.
 
-Software should prevent a creation of an account if previous account does not
+Software should prevent a creation of an account if a previous account does not
 have a transaction history (meaning none of its addresses have been used before).
 
 Software needs to discover all used accounts after importing the seed from
-an external source. Such algorithm is described in "Account discovery" chapter.
+an external source. Such an algorithm is described in "Account discovery" chapter.
 
 ===Change===
 
@@ -104,15 +104,15 @@ start to discover the accounts in the following manner:
 # derive the first account's node (index = 0)
 # derive the external chain node of this account
 # scan addresses of the external chain; respect the gap limit described below
-# if no transactions are found on the external chain stop discovery
+# if no transactions are found on the external chain, stop discovery
 # if there are some transactions, increase the account index and go to step 1
 
-This algorithm is correct, because software should disallow creation of new
-accounts if previous one has no transaction history as described in chapter
+This algorithm is successful because software should disallow creation of new
+accounts if previous one has no transaction history, as described in chapter
 "Account" above.
 
 Please note that the algorithm works with the transaction history, not account
-balances, so you can have account with total 0 coins and the algorithm will
+balances, so you can have an account with 0 total coins and the algorithm will
 still continue with discovery.
 
 ===Address gap limit===
@@ -121,7 +121,7 @@ Address gap limit is currently set to 20. If the software hits 20 unused
 addresses in a row, it expects there are no used addresses beyond this point
 and stops searching the address chain.
 
-Wallet software should warn when user is trying to exceed the gap limit on
+Wallet software should warn when the user is trying to exceed the gap limit on
 an external chain by generating a new address.
 
 ==Registered coin types==
@@ -251,7 +251,7 @@ All these constants are used as hardened derivation.
 |m / 44' / 1' / 1' / 1 / 1
 |}
 
-==Compatible walets==
+==Compatible wallets==
 
 * [[https://mytrezor.com|myTREZOR web wallet]] ([[https://github.com/trezor/webwallet|source]])
 

From fe4685a73c2471c6a5dce9e244dd929ecaad35bf Mon Sep 17 00:00:00 2001
From: Nicolas Dorier 
Date: Tue, 29 Apr 2014 15:44:02 +0200
Subject: [PATCH 119/181] C# implementation

Github link to a C# implementation
---
 bip-0032.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index fdc96138..0563d35e 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -271,6 +271,8 @@ A JavaScript implementation is available at https://github.com/sarchar/brainwall
 
 A PHP implemetation is available at https://github.com/Bit-Wasp/bitcoin-lib-php
 
+A C# implementation is available at https://github.com/NicolasDorier/NBitcoin (ExtKey, ExtPubKey)
+
 ==Acknowledgements==
 
 * Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.

From bd34818589456c237f9c9b1a9e701039e0c82c5f Mon Sep 17 00:00:00 2001
From: Telepatheic 
Date: Thu, 1 May 2014 21:33:07 +0100
Subject: [PATCH 120/181] Small typo

---
 bip-0038.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index 7c38222b..67e68645 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -78,7 +78,7 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are
 * Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
 ** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
 ** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
-* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6Pn):
+* Range in base58check encoding for EC-multiplied keys with compression (prefix 6Pn):
 ** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
 ** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)
 

From 18bb72aa2716a4cf7665530cbc5a09d27362bc14 Mon Sep 17 00:00:00 2001
From: Andy Alness 
Date: Fri, 2 May 2014 15:27:54 -0700
Subject: [PATCH 121/181] Validate a payment request is still valid prior to
 payment

Currently there exists the potential for a user to load a payment request into
their wallet which is valid at that time but its expiration lapses prior to
the user authorizing the payment. This could lead to an unnecessary customer
service interaction.
---
 bip-0070.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 692d7f0f..1969d4d8 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -153,6 +153,7 @@ after the time of the payment request. After that time has expired, parties must
 If the customer authorizes payment, then the Bitcoin client:
 
 # Creates and signs one or more transactions that satisfy (pay in full) PaymentDetails.outputs
+# Validate that customer's system unix time (UTC) is still before PaymentDetails.expires. If it is not, the payment should be cancelled.
 # Broadcast the transactions on the Bitcoin p2p network.
 # If PaymentDetails.payment_url is specified, POST a Payment message to that URL. The Payment message is serialized and sent as the body of the POST request.
 

From 5be4021fa14ba679fefd44e02cb9d25d6b6707c3 Mon Sep 17 00:00:00 2001
From: "David A. Harding" 
Date: Tue, 20 May 2014 11:34:21 -0400
Subject: [PATCH 122/181] Disambiguate Which Key Is Compromised When Ext.
 PubKey + PrivKey Are Leaked

I mistakenly inferred from the following clause that a parent extended
public key plus a child private key would be equivalent to knowing the
extended *child* private key---meaning that the *parent* private key was
still secure:

> knowledge of the extended public key + any non-hardened private key
> descending from it is equivalent to knowing the extended private key

This patch's addition of the word "parent" (twice) removes the ambiguity
and may help other readers draw the correct inference that the parent
private key is no longer secure in this case.

I also changed "+" to "plus" to avoid confusion with the actual
mathematical operations used in this BIP.
---
 bip-0032.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index 0563d35e..504597ff 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -201,7 +201,7 @@ Private and public keys must be kept safe as usual. Leaking a private key means
 
 Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys.
 
-One weakness that may not be immediately obvious, is that knowledge of the extended public key + any non-hardened private key descending from it is equivalent to knowing the extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys.
+One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys.
 It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.
 
 

From c2374611f4580ec56eaaaede2b5589c14c68be7a Mon Sep 17 00:00:00 2001
From: Nicolas Dorier 
Date: Tue, 27 May 2014 18:05:59 +0200
Subject: [PATCH 123/181] Add reference implementation links

This BIP is really hard to implement because of the lack of test vectors and lack of documented  implementations. This will save time for implementers.
---
 bip-0070.mediawiki | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 5d5674c3..c76ba6a1 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -292,6 +292,11 @@ http://datatracker.ietf.org/wg/pkix/charter/
 
 Protocol Buffers : https://developers.google.com/protocol-buffers/
 
+==Reference implementation==
+
+Create Payment Request generator : https://bitcoincore.org/~gavin/createpaymentrequest.php
+Sources at : https://bitcoincore.org/~gavin/createpaymentrequest.php
+
 ==See Also==
 
 Javascript Object Signing and Encryption working group :

From 9690c2df4855b9c5076947b6d8571fd3607501c6 Mon Sep 17 00:00:00 2001
From: Nicolas Dorier 
Date: Tue, 27 May 2014 18:08:40 +0200
Subject: [PATCH 124/181] Add BitcoinJ excellent introduction

---
 bip-0070.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index c76ba6a1..a23ef7e4 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -297,6 +297,8 @@ Protocol Buffers : https://developers.google.com/protocol-buffers/
 Create Payment Request generator : https://bitcoincore.org/~gavin/createpaymentrequest.php
 Sources at : https://bitcoincore.org/~gavin/createpaymentrequest.php
 
+BitcoinJ : https://bitcoinj.github.io/payment-protocol#introduction
+
 ==See Also==
 
 Javascript Object Signing and Encryption working group :

From b2c0b87a9c5eac3fe7af3c7eb1655004fde19817 Mon Sep 17 00:00:00 2001
From: Gavin Andresen 
Date: Wed, 4 Jun 2014 19:11:04 -0400
Subject: [PATCH 125/181] Clarify handling of default fields for signing.

---
 bip-0070.mediawiki | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index a23ef7e4..433eb131 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -124,7 +124,11 @@ A PaymentRequest is PaymentDetails optionally tied to a merchant's identity:
 |-
 | serialized_payment_details || A protocol-buffer serialized PaymentDetails message.
 |-
-| signature || digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message, with all fields serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order) and signed using the public key in pki_data.  Before serialization, the signature field must be set to an empty value so that the field is included in the signed PaymentRequest hash but contains no data.
+| signature || digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message,
+with all serialized fields serialized in numerical order (all current protocol buffer implementations serialize
+fields in numerical order) and signed using the public key in pki_data. Optional fields that are not set
+are not serialized (however, setting a field to its default value will cause it to be serialized and will affect
+the signature). Before serialization, the signature field must be set to an empty value so that the field is included in the signed PaymentRequest hash but contains no data.
 |}
 When a Bitcoin wallet application receives a PaymentRequest, it must authorize payment by doing the following:
 

From e33c834cf53ded7766169f56ac0ad06510e66c66 Mon Sep 17 00:00:00 2001
From: Richard Moore 
Date: Mon, 9 Jun 2014 14:19:44 -0400
Subject: [PATCH 126/181] Clarify AES parameters passed in

There was some slight ambiguity in which items passed into AESEncrypt was the key and which was the block.
---
 bip-0038.mediawiki | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index 67e68645..21157ef2 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -90,8 +90,8 @@ Encryption steps:
 # Derive a key from the passphrase using scrypt
 #*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8.  salt is ''addresshash'' from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
 #*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
-# Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1''
-# Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2''
+# Do AES256Encrypt(block = bitcoinprivkey[0...15] xor derivedhalf1[0...15], key = derivedhalf2), call the 16-byte result ''encryptedhalf1''
+# Do AES256Encrypt(block = bitcoinprivkey[16...31] xor derivedhalf1[16...31], key = derivedhalf2), call the 16-byte result ''encryptedhalf2''
 
 The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
 * 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''
@@ -141,8 +141,8 @@ Steps to create new encrypted private keys given ''intermediate_passphrase_strin
 # Now we will encrypt ''seedb''.  Derive a second key from ''passpoint'' using scrypt
 #*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes).  ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64.  The "+" operator is concatenation.
 #*Split the result into two 32-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
-# Do AES256Encrypt(seedb[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1''
-# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedpart2''.  The "+" operator is concatenation.
+# Do AES256Encrypt(block = (seedb[0...15] xor derivedhalf1[0...15]), key = derivedhalf2), call the 16-byte result ''encryptedpart1''
+# Do AES256Encrypt(block = ((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31]), key = derivedhalf2), call the 16-byte result ''encryptedpart2''.  The "+" operator is concatenation.
 
 The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
 * 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''
@@ -153,8 +153,8 @@ The party generating the Bitcoin address has the option to return a ''confirmati
 To generate it, we need ''flagbyte'', ''ownerentropy'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
 # ECMultiply ''factorb'' by G, call the result ''pointb''.  The result is 33 bytes.
 # The first byte is 0x02 or 0x03.  XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pointbprefix''.
-# Do AES256Encrypt(pointb[1...16] xor derivedhalf1[0...15], derivedhalf2) and call the result ''pointbx1''.
-# Do AES256Encrypt(pointb[17...32] xor derivedhalf1[16...31], derivedhalf2) and call the result ''pointbx2''.
+# Do AES256Encrypt(block = (pointb[1...16] xor derivedhalf1[0...15]), key = derivedhalf2) and call the result ''pointbx1''.
+# Do AES256Encrypt(block = (pointb[17...32] xor derivedhalf1[16...31]), key = derivedhalf2) and call the result ''pointbx2''.
 # Concatenate ''pointbprefix'' + ''pointbx1'' + ''pointbx2'' (total 33 bytes) and call the result ''encryptedpointb''.
 
 The result is a Base58Check-encoded concatenation of the following:

From ba1cca2225152fc0fa3a48b4b392fe713ea7d035 Mon Sep 17 00:00:00 2001
From: Pavol Rusnak 
Date: Wed, 21 May 2014 17:30:55 +0200
Subject: [PATCH 127/181] bip-0044: scan just external chains

---
 bip-0044.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index 52294353..df6f8e6a 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -119,7 +119,8 @@ still continue with discovery.
 
 Address gap limit is currently set to 20. If the software hits 20 unused
 addresses in a row, it expects there are no used addresses beyond this point
-and stops searching the address chain.
+and stops searching the address chain. We scan just the external chains, because
+internal chains receive only coins that come from the associated external chains.
 
 Wallet software should warn when the user is trying to exceed the gap limit on
 an external chain by generating a new address.

From 13dc446a4ce780ae8d983195873481f7ef997884 Mon Sep 17 00:00:00 2001
From: Gavin Andresen 
Date: Thu, 12 Jun 2014 10:45:06 -0400
Subject: [PATCH 128/181] Add Mike as co-author, status Draft->Final

We've got multiple implementations, so Final status is appropriate.

And Mike agreed to help pull clarifying edits.
---
 bip-0070.mediawiki | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 433eb131..91618665 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -1,8 +1,7 @@
 
   BIP: 70
   Title: Payment Protocol
-  Author: Gavin Andresen 
-  Status: Draft
+  Authors: Gavin Andresen , Mike Hearn 

From d58c6d99da927fab43bec9ca57baeeff57c9c7d0 Mon Sep 17 00:00:00 2001
From: Gavin Andresen 
Date: Thu, 12 Jun 2014 10:45:38 -0400
Subject: [PATCH 129/181] Fix mike's email address

---
 bip-0070.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 91618665..a104bd18 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: 70
   Title: Payment Protocol
-  Authors: Gavin Andresen , Mike Hearn , Mike Hearn 
   Type: Standards Track
   Created: 2013-07-29
 


From 3aa996b5553b92e1e6b05b42448c7f657dac8760 Mon Sep 17 00:00:00 2001
From: Gavin Andresen 
Date: Thu, 12 Jun 2014 10:46:26 -0400
Subject: [PATCH 130/181] Status Draft --> Final

---
 bip-0071.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0071.mediawiki b/bip-0071.mediawiki
index 44b4d3da..1fc84892 100644
--- a/bip-0071.mediawiki
+++ b/bip-0071.mediawiki
@@ -2,7 +2,7 @@
   BIP: 71
   Title: Payment Protocol MIME types
   Author: Gavin Andresen 
-  Status: Draft
+  Status: Final
   Type: Standards Track
   Created: 2013-07-29
 


From 8571f42a6c0cdf9ba25817a2ea60b1b5ba988181 Mon Sep 17 00:00:00 2001
From: Gavin Andresen 
Date: Thu, 12 Jun 2014 10:46:59 -0400
Subject: [PATCH 131/181] Status got lost in editing

---
 bip-0070.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index a104bd18..c3544fab 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -2,6 +2,7 @@
   BIP: 70
   Title: Payment Protocol
   Authors: Gavin Andresen , Mike Hearn 
+  Status: Final
   Type: Standards Track
   Created: 2013-07-29
From 83ade87ba339b1895a70ea172e2369810bdc3708 Mon Sep 17 00:00:00 2001 From: Gavin Andresen Date: Thu, 12 Jun 2014 10:47:49 -0400 Subject: [PATCH 132/181] Status changed from Draft to Final --- bip-0072.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0072.mediawiki b/bip-0072.mediawiki index 8617dbe4..4dcc48b5 100644 --- a/bip-0072.mediawiki +++ b/bip-0072.mediawiki @@ -2,7 +2,7 @@ BIP: 72 Title: bitcoin: uri extensions for Payment Protocol Author: Gavin Andresen - Status: Draft + Status: Final Type: Standards Track Created: 2013-07-29 @@ -66,4 +66,4 @@ bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe ==References== -[[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1 \ No newline at end of file +[[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1 From 07da8f4d12f2d81437ae32847a9ba45ffc6abb3a Mon Sep 17 00:00:00 2001 From: ReadLiberty Date: Mon, 16 Jun 2014 15:04:11 +0200 Subject: [PATCH 133/181] Fixed typo --- bip-0001.mediawiki | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index c9857a85..5c8a544f 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -12,8 +12,7 @@ BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providin We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. -Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal -. +Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. ==BIP Types== There are three kinds of BIP: From 4d9e7bc20cef9b296f1c1e9112e729186b54fc61 Mon Sep 17 00:00:00 2001 From: Gavin Andresen Date: Wed, 18 Jun 2014 11:13:44 -0400 Subject: [PATCH 134/181] reject P2P message (BIP61) --- bip-0061.mediawiki | 153 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+) create mode 100644 bip-0061.mediawiki diff --git a/bip-0061.mediawiki b/bip-0061.mediawiki new file mode 100644 index 00000000..a18a4e60 --- /dev/null +++ b/bip-0061.mediawiki @@ -0,0 +1,153 @@ +
+  BIP: 61
+  Title: Reject P2P message
+  Author: Gavin Andresen 
+  Status: Final
+  Type: Standards Track
+  Created: 2014-06-18
+
+ +==Abstract== + +This BIP describes a new message type for the Bitcoin peer-to-peer network. + +==Motivation== + +Giving peers feedback about why their blocks or transactions are rejected, or +why they are being banned for not following the protocol helps +interoperability between different implementations. + +It also gives SPV (simplified payment verification) clients a hint that something +may be wrong when their transactions are rejected due to insufficient priority +or fees. + +==Specification== + +Data types in this specification are as described at https://en.bitcoin.it/wiki/Protocol_specification + +===reject=== + +One new message type "reject" is introduced. It is sent directly to a peer in response to a "version", "tx" or "block" message. + +For example, the message flow between two peers for a relayed transaction that is rejected for some reason would be: + + --> inv + <-- getdata + --> tx + <-- reject + +All implementations of the P2P protocol version 70,002 and later should support the reject message. + +====common payload==== + + +Every reject message begins with the following fields. Some messages append extra, message-specific data. + +{| +| Field Size || Name || Data type || Comments +|- +| variable || response-to-msg || var_str || Message that triggered the reject +|- +| 1 || reject-code || uint8_t || 0x01 through 0x4f (see below) +|- +| variable || reason || var_string || Human-readable message for debugging +|} + +The human-readable string is intended only for debugging purposes; in particular, different implementations may +use different strings. The string should not be shown to users or used for anthing besides diagnosing +interoperability problems. + +The following reject code categories are used; in the descriptions below, "server" is the peer generating +the reject message, "client" is the peer that will receive the message. + +{| +| Range || Category +|- +| 0x01-0x0f || Protocol syntax errors +|- +| 0x10-0x1f || Protocol semantic errors +|- +| 0x40-0x4f || Server policy rule +|} + +==== rejection codes common to all message types ==== + +{| +| Code || Description +|- +| 0x01 || Message could not be decoded +|} + +==== reject version codes ==== + +Codes generated during the intial connection process in response to a "version" message: + +{| +| Code || Description +|- +| 0x11 || Client is an obsolete, unsupported version +|- +| 0x12 || Duplicate version message received +|} + +==== reject tx payload, codes ==== + +Transaction rejection messages extend the basic message with the transaction id hash: + +{| +| Field Size || Name || Data type || Comments +|- +| 32 || hash || char[32] || transaction that is rejected +|} + +The following codes are used: + +{| +| Code || Description +|- +| 0x10 || Transaction is invalid for some reason (invalid signature, output value greater than input, etc.) +|- +| 0x40 || Not mined/relayed because it is "non-standard" (type or version unknown by the server) +|- +| 0x41 || One or more output amounts are below the 'dust' threshold +|- +| 0x42 || Transaction does not have enough fee/priority to be relayed or mined +|} + +==== payload, reject block ==== + +Block rejection messages extend the basic message with the block header hash: + +{| +| Field Size || Name || Data type || Comments +|- +| 32 || hash || char[32] || block (hash of block header) that is rejected +|} + +Rejection codes: + +{| +| code || description +|- +| 0x10 || Block is invalid for some reason (invalid proof-of-work, invalid signature, etc) +|- +| 0x11 || Block's version is no longer supported +|- +| 0x43 || Inconsistent with a compiled-in checkpoint +|} + +Note: blocks that are not part of the server's idea of the current best chain, but are otherwise valid, should not trigger reject messages. + +== Compatibility == + +The reject message is backwards-compatible; older peers that do not recognize the reject message will ignore it. + +== Implementation notes == + +Implementors must consider what happens if an attacker either sends them +reject messages for valid transactions/blocks or sends them random +reject messages, and should beware of possible denial-of-service attacks. +For example, notifying the user of every reject message received +would make it trivial for an attacker to mount an annoy-the-user attack. +Even merely writing every reject message to a debugging log could make +an implementation vulnerable to a fill-up-the-users-disk attack. From 4336363ac26e58087e60315c2abf90d9d26a6b8e Mon Sep 17 00:00:00 2001 From: Robbie Clarken Date: Sat, 21 Jun 2014 17:24:59 +1000 Subject: [PATCH 135/181] Fix URL to source of PHP payment request generator The link to the source code of Gavin's PHP implementation was for the demo web page instead of the GitHub repository. --- bip-0070.mediawiki | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index c3544fab..03baf5bd 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -298,8 +298,7 @@ Protocol Buffers : https://developers.google.com/protocol-buffers/ ==Reference implementation== -Create Payment Request generator : https://bitcoincore.org/~gavin/createpaymentrequest.php -Sources at : https://bitcoincore.org/~gavin/createpaymentrequest.php +Create Payment Request generator : https://bitcoincore.org/~gavin/createpaymentrequest.php ([[https://github.com/gavinandresen/paymentrequest|source]]) BitcoinJ : https://bitcoinj.github.io/payment-protocol#introduction From 989916fa2f08608d9f3c449939f36b90c4a79865 Mon Sep 17 00:00:00 2001 From: Aaron Voisine Date: Thu, 26 Jun 2014 10:34:26 -0700 Subject: [PATCH 136/181] unicode normalization of password Added instructions for unicode normalization of password --- bip-0038.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index 67e68645..81efcd55 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -88,7 +88,7 @@ Encrypting a private key without the EC multiplication offers the advantage that Encryption steps: # Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash". # Derive a key from the passphrase using scrypt -#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''addresshash'' from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus) +#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8 and normalized using Unicode Normalization Form C (NFC). salt is ''addresshash'' from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus) #*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''. # Do AES256Encrypt(bitcoinprivkey[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedhalf1'' # Do AES256Encrypt(bitcoinprivkey[16...31] xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedhalf2'' @@ -119,7 +119,7 @@ Steps performed by ''owner'' to generate a single intermediate code, if lot and # Encode the lot and sequence numbers as a 4 byte quantity (big-endian): lotnumber * 4096 + sequencenumber. Call these four bytes ''lotsequence''. # Concatenate ''ownersalt'' + ''lotsequence'' and call this ''ownerentropy''. # Derive a key from the passphrase using scrypt -#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8. salt is ''ownersalt''. n=16384, r=8, p=8, length=32. +#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8 and normalized using Unicode Normalization Form C (NFC). salt is ''ownersalt''. n=16384, r=8, p=8, length=32. #* Call the resulting 32 bytes ''prefactor''. #* Take SHA256(SHA256(''prefactor'' + ''ownerentropy'')) and call this ''passfactor''. # Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys. From 1064fbc9e10eba3391340b41b2d488f71c052012 Mon Sep 17 00:00:00 2001 From: wozz Date: Tue, 1 Jul 2014 06:47:34 -0400 Subject: [PATCH 137/181] Move Test 3 to the correct location. The encrypted key for unicode test should be in the section for No compression, no EC multiply. --- bip-0038.mediawiki | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index e48a0859..949220bd 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -226,6 +226,13 @@ Test 2: *Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5 *Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE +Test 3: +*Passphrase ϓ␀𐐀💩 (\u03D2\u0301\u0000\U00010400\U0001F4A9; [http://codepoints.net/U+03D2 GREEK UPSILON WITH HOOK], [http://codepoints.net/U+0301 COMBINING ACUTE ACCENT], [http://codepoints.net/U+0000 NULL], [http://codepoints.net/U+10400 DESERET CAPITAL LETTER LONG I], [http://codepoints.net/U+1F4A9 PILE OF POO]) +*Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn +*Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF +*Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4 +* ''Note:'' The non-standard UTF-8 characters in this passphrase should be NFC normalized to result in a passphrase of 0xcf9300f0909080f09f92a9 before further processing + ===Compression, no EC multiply=== Test 1: @@ -258,13 +265,6 @@ Test 2: *Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH *Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A -Test 3: -*Passphrase ϓ␀𐐀💩 (\u03D2\u0301\u0000\U00010400\U0001F4A9; [http://codepoints.net/U+03D2 GREEK UPSILON WITH HOOK], [http://codepoints.net/U+0301 COMBINING ACUTE ACCENT], [http://codepoints.net/U+0000 NULL], [http://codepoints.net/U+10400 DESERET CAPITAL LETTER LONG I], [http://codepoints.net/U+1F4A9 PILE OF POO]) -*Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn -*Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF -*Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4 -* ''Note:'' The non-standard UTF-8 characters in this passphrase should be NFC normalized to result in a passphrase of 0xcf9300f0909080f09f92a9 before further processing - ===EC multiply, no compression, lot/sequence numbers=== Test 1: From e8a67ead35d6c3315f0e9aa77216e1ab13cff755 Mon Sep 17 00:00:00 2001 From: christianlundkvist Date: Wed, 2 Jul 2014 20:58:05 -0400 Subject: [PATCH 138/181] Add password to test vector section. --- bip-0039.mediawiki | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 2fd8ad0d..6f7b1500 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -115,7 +115,10 @@ will make the desired wallet available. ==Test vectors== -See https://github.com/trezor/python-mnemonic/blob/master/vectors.json +The test vectors include input entropy, mnemonic and seed. The +passphrase "TREZOR" is used for all vectors. + +https://github.com/trezor/python-mnemonic/blob/master/vectors.json ==Reference Implementation== From 11643a7585504d94996650fb7c390df0f4db4e41 Mon Sep 17 00:00:00 2001 From: christianlundkvist Date: Wed, 2 Jul 2014 21:08:56 -0400 Subject: [PATCH 139/181] Run spell check. --- bip-0039.mediawiki | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 6f7b1500..dba76a0e 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -16,17 +16,17 @@ This BIP describes the implementation of a mnemonic code or mnemonic sentence -- a group of easy to remember words -- for the generation of deterministic wallets. -It consists of two parts: generating the mnenomic, and converting it into a +It consists of two parts: generating the mnemonic, and converting it into a binary seed. This seed can be later used to generate deterministic wallets using BIP-0032 or similar methods. ==Motivation== -A mnenomic code or sentence is superior for human interaction compared to the -handling of raw binary or hexidecimal representations of a wallet seed. The +A mnemonic code or sentence is superior for human interaction compared to the +handling of raw binary or hexadecimal representations of a wallet seed. The sentence could be written on paper or spoken over the telephone. -This guide meant to be as a way to transport computer-generated randomnes over +This guide meant to be as a way to transport computer-generated randomness over human readable transcription. It's not a way how to process user-created sentences (also known as brainwallet) to wallet seed. From df21b4ce4592ad7f03b0132345b522ad881dbb82 Mon Sep 17 00:00:00 2001 From: Giannis Dzegoutanis Date: Wed, 9 Jul 2014 12:04:44 +0200 Subject: [PATCH 140/181] BIP 44 - Specify that this BIP is not a central repository for registered coin types. Provide links to the central repo. --- bip-0044.mediawiki | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index df6f8e6a..4a8b3219 100644 --- a/bip-0044.mediawiki +++ b/bip-0044.mediawiki @@ -127,8 +127,8 @@ an external chain by generating a new address. ==Registered coin types== -These are the registered coin types for usage in level 2 of BIP44 described in -chapter "Coin type" above. +These are the default registered coin types for usage in level 2 of BIP44 +described in chapter "Coin type" above. All these constants are used as hardened derivation. @@ -146,6 +146,14 @@ All these constants are used as hardened derivation. |Bitcoin Testnet |} +This BIP is not a central directory for the registered coin types, please +visit Satoshi Labs that maintains the full list: + +[[http://doc.satoshilabs.com/slips/slip-0044.html|SLIP-0044 : Registered coin types for BIP-0044]] + +To register a new coin type, an existing wallet that implements the standard +is required. This can be done [[https://github.com/satoshilabs/docs/blob/master/slips/slip-0044.rst|here]]. + ==Examples== {| From 3a94ead4dd67d74be4fb863cdaaf679658f89f10 Mon Sep 17 00:00:00 2001 From: Timothy Hobbs Date: Wed, 9 Jul 2014 14:18:59 +0000 Subject: [PATCH 141/181] Spelling BIP 39 --- bip-0039.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 2fd8ad0d..eb60fffd 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -16,17 +16,17 @@ This BIP describes the implementation of a mnemonic code or mnemonic sentence -- a group of easy to remember words -- for the generation of deterministic wallets. -It consists of two parts: generating the mnenomic, and converting it into a +It consists of two parts: generating the mnemonic, and converting it into a binary seed. This seed can be later used to generate deterministic wallets using BIP-0032 or similar methods. ==Motivation== -A mnenomic code or sentence is superior for human interaction compared to the +A mnemonic code or sentence is superior for human interaction compared to the handling of raw binary or hexidecimal representations of a wallet seed. The sentence could be written on paper or spoken over the telephone. -This guide meant to be as a way to transport computer-generated randomnes over +This guide meant to be as a way to transport computer-generated randomness over human readable transcription. It's not a way how to process user-created sentences (also known as brainwallet) to wallet seed. From 224faeaa2a9770f74bb28629126be94e72a3e0a2 Mon Sep 17 00:00:00 2001 From: Timothy Hobbs Date: Wed, 9 Jul 2014 14:20:55 +0000 Subject: [PATCH 142/181] Spelling bip 32 --- bip-0032.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 0563d35e..e5fa7911 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -15,7 +15,7 @@ RECENT CHANGES: ==Abstract== -This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins. +This document describes hierarchical deterministic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins. The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients. Although the wallets described here have many features, not all are required by supporting clients. From 0bf935b552b25fefb9a6791bcb73bd883b1b87c7 Mon Sep 17 00:00:00 2001 From: Aaron Voisine Date: Wed, 9 Jul 2014 11:21:34 -0700 Subject: [PATCH 143/181] BIP39 grammar --- bip-0039.mediawiki | 46 +++++++++++++++++++++++----------------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index eb60fffd..e77955f3 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -26,25 +26,25 @@ A mnemonic code or sentence is superior for human interaction compared to the handling of raw binary or hexidecimal representations of a wallet seed. The sentence could be written on paper or spoken over the telephone. -This guide meant to be as a way to transport computer-generated randomness over -human readable transcription. It's not a way how to process user-created -sentences (also known as brainwallet) to wallet seed. +This guide is meant to be a way to transport computer-generated randomness with +a human readable transcription. It's not a way to process user-created +sentences (also known as brainwallets) into a wallet seed. ==Generating the mnemonic== -The mnemonic must encode entropy in any multiple of 32 bits. With larger entropy -security is improved but the sentence length increases. We can refer to the +The mnemonic must encode entropy in a multiple of 32 bits. With more entropy +security is improved but the sentence length increases. We refer to the initial entropy length as ENT. The recommended size of ENT is 128-256 bits. First, an initial entropy of ENT bits is generated. A checksum is generated by taking the first 
ENT / 32
bits of its SHA256 hash. This checksum is appended to the end of the initial entropy. Next, these concatenated bits are are split into groups of 11 bits, each encoding a number from 0-2047, serving -as an index to a wordlist. Later, we will convert these numbers into words and +as an index into a wordlist. Finally, we convert these numbers into words and use the joined words as a mnemonic sentence. The following table describes the relation between the initial entropy -length (ENT), the checksum length (CS) and length of the generated mnemonic +length (ENT), the checksum length (CS) and the length of the generated mnemonic sentence (MS) in words. 
@@ -65,7 +65,7 @@ MS = (ENT + CS) / 11
 An ideal wordlist has the following characteristics:
 
 a) smart selection of words
-   - wordlist is created in such way that it's enough to type the first four
+   - the wordlist is created in such way that it's enough to type the first four
      letters to unambiguously identify the word
 
 b) similar words avoided
@@ -74,39 +74,39 @@ b) similar words avoided
      prone and more difficult to guess
 
 c) sorted wordlists
-   - wordlist is sorted which allows for more efficient lookup of the code words
-     (i.e. implementation can use binary search instead of linear search)
-   - this also allows trie (prefix tree) to be used, e.g. for better compression
+   - the wordlist is sorted which allows for more efficient lookup of the code words
+     (i.e. implementations can use binary search instead of linear search)
+   - this also allows trie (a prefix tree) to be used, e.g. for better compression
 
-The wordlist can contain native characters, but they have to be encoded in UTF-8
+The wordlist can contain native characters, but they must be encoded in UTF-8
 using Normalization Form Compatibility Decomposition (NFKD).
 
 ==From mnemonic to seed==
 
-A user may decide to protect their mnemonic by passphrase. If a passphrase is not
+A user may decide to protect their mnemonic with a passphrase. If a passphrase is not
 present, an empty string "" is used instead.
 
-To create a binary seed from the mnemonic, we use PBKDF2 function with a mnemonic
-sentence (in UTF-8 NFKD) used as a password and string "mnemonic" + passphrase (again
-in UTF-8 NFKD) used as a salt. Iteration count is set to 2048 and HMAC-SHA512 is used as
-a pseudo-random function. Desired length of the derived key is 512 bits (= 64 bytes).
+To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic
+sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again
+in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as
+the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).
 
 This seed can be later used to generate deterministic wallets using BIP-0032 or
 similar methods.
 
-The conversion of the mnemonic sentence to binary seed is completely independent
+The conversion of the mnemonic sentence to a binary seed is completely independent
 from generating the sentence. This results in rather simple code; there are no
 constraints on sentence structure and clients are free to implement their own
 wordlists or even whole sentence generators, allowing for flexibility in wordlists
 for typo detection or other purposes.
 
-Although using mnemonic not generated by algorithm described in "Generating the
-mnemonic" section is possible, this is not advised and software must compute
-checksum of the mnemonic sentence using wordlist and issue a warning if it is
+Although using a mnemonic not generated by the algorithm described in "Generating the
+mnemonic" section is possible, this is not advised and software must compute a
+checksum for the mnemonic sentence using a wordlist and issue a warning if it is
 invalid.
 
-Described method also provides plausible deniability, because every passphrase
-generates a valid seed (and thus deterministic wallet) but only the correct one
+The described method also provides plausible deniability, because every passphrase
+generates a valid seed (and thus a deterministic wallet) but only the correct one
 will make the desired wallet available.
 
 ==Wordlists==

From a7ba9f2ef0202da42673a5815fcfdbdc5dcd6118 Mon Sep 17 00:00:00 2001
From: Gregory Maxwell 
Date: Mon, 14 Jul 2014 04:41:10 -0700
Subject: [PATCH 144/181] Update README.mediawiki

Getutxos message BIP assigned BIP64.
---
 README.mediawiki | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/README.mediawiki b/README.mediawiki
index 3103d74d..d5e3fb19 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -224,6 +224,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | BIP number allocated
 |-
+| [[bip-0064.mediawiki|64]]
+| getutxos message
+| Mike Hearn
+| Standard
+| Draft
+|-
 | [[bip-0070.mediawiki|70]]
 | Payment protocol
 | Gavin Andresen

From 6ac80993561f0934d56d21254ca4de354e59b4a5 Mon Sep 17 00:00:00 2001
From: christianlundkvist 
Date: Wed, 16 Jul 2014 19:51:47 -0400
Subject: [PATCH 145/181] Revert "Run spell check."

This reverts commit 11643a7585504d94996650fb7c390df0f4db4e41.
---
 bip-0039.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index dba76a0e..6f7b1500 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -16,17 +16,17 @@
 This BIP describes the implementation of a mnemonic code or mnemonic sentence --
 a group of easy to remember words -- for the generation of deterministic wallets.
 
-It consists of two parts: generating the mnemonic, and converting it into a
+It consists of two parts: generating the mnenomic, and converting it into a
 binary seed. This seed can be later used to generate deterministic wallets using
 BIP-0032 or similar methods.
 
 ==Motivation==
 
-A mnemonic code or sentence is superior for human interaction compared to the
-handling of raw binary or hexadecimal representations of a wallet seed. The
+A mnenomic code or sentence is superior for human interaction compared to the
+handling of raw binary or hexidecimal representations of a wallet seed. The
 sentence could be written on paper or spoken over the telephone.
 
-This guide meant to be as a way to transport computer-generated randomness over
+This guide meant to be as a way to transport computer-generated randomnes over
 human readable transcription. It's not a way how to process user-created
 sentences (also known as brainwallet) to wallet seed.
 

From c61a4b9491aa17ca5f7c8a1084c50c06e7d30702 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Fri, 18 Jul 2014 17:03:39 +0200
Subject: [PATCH 146/181] Restructure and make rules 2 and 4 unconditional

---
 bip-0062.mediawiki | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki
index 3f110509..4fd29c3f 100644
--- a/bip-0062.mediawiki
+++ b/bip-0062.mediawiki
@@ -31,7 +31,7 @@ Several sources of malleability are known:
 # '''Inputs ignored by scripts''' If a scriptPubKey starts with an OP_DROP, for example, the last data push of the corresponding scriptSig will always be ignored.
 # '''Sighash flags based masking''' Sighash flags can be used to ignore certain parts of a script when signing.
 # '''New signatures by the sender''' The sender (or anyone with access to the relevant private keys) is always able to create new signatures that spend the same inputs to the same outputs.
-The first six and part of the seventh can be fixed by extra consensus rules. The last three can't, but are always under control of the (original) sender.
+The first six and part of the seventh can be fixed by extra consensus rules. The last two can't, but are always under control of the (original) sender.
 
 ==Specification==
 
@@ -46,6 +46,16 @@ Seven extra rules are introduced, to combat exactly the seven first sources of m
 # '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed.
 # '''Inputs ignored by scripts''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script invalid.
 
+===Block validity===
+
+To introduce these new rules in the network, we add both nVersion=3 blocks and nVersion=3 transactions (nVersion=2 is skipped for transactions in order to keep the version numbers synchronized with block version numbers).
+The same mechanism as in BIP 0034 is used to introduce nVersion=3 blocks. When 75% of the past 1000 blocks are nVersion=3, a new consensus rule is activated which requires:
+* All transactions in such blocks are required to follow rules #2 and #4.
+* nVersion>=3 transactions in such blocks are required to follow all the above rules.
+
+When 95% of the past 1000 blocks are nVersion>=3, nVersion=2 blocks become invalid entirely. Note however that nVersion=1 transactions remain valid forever.
+
+
 ===References===
 
 Below is a summary of the effects on signatures, their encoding and data pushes.
@@ -82,10 +92,6 @@ For reference:
 
 ==Compatibility==
 
-'''Version 3 blocks and transactions''' To introduce these new rules in the network, we add both nVersion=3 blocks and nVersion=3 transactions (nVersion=2 transactions are skipped in order to keep the version numbers synchronized).
-
 '''Relay of transactions''' A new node software version is released which makes nVersion=3 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of nVersion=1 transactions is unaffected. An nVersion=1 transaction spending an output created by an nVersion=3 transaction is also unaffected.
 
-'''Block validity''' In addition, the same mechanism as in BIP 0034 is reused to introduce nVersion=3 blocks. When 75% of the past 1000 blocks are nVersion=3, a new consensus rule is activated which requires nVersion>=3 transactions in nVersion>=3 blocks (and only that combination) to follow the above rules. An nVersion>=3 block with an nVersion>=3 transaction whose scriptSig does not follow the new rules, becomes invalid. When 95% of the past blocks are nVersion>=3, nVersion=2 blocks become invalid entirely. Note however that nVersion=1 transactions remain valid forever.
-
 '''Wallet updates''' As nVersion=3 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but setting nVersion=3 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software.

From 25a55ed60f8fefca48b23840d372fa9253b4f02c Mon Sep 17 00:00:00 2001
From: Dave Collins 
Date: Tue, 22 Jul 2014 17:35:46 -0500
Subject: [PATCH 147/181] Add BIP0032 Go implementation.

---
 bip-0032.mediawiki | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index e5fa7911..3ef2d9ec 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -265,7 +265,9 @@ An Objective-C implementation is available at https://github.com/oleganza/CoreBi
 
 A Ruby implementation is available at https://github.com/wink/money-tree
 
-A Go implementation is available at https://github.com/WeMeetAgain/go-hdwallet
+Two Go implementations exist:
+
+hdkeychain (https://github.com/conformal/btcutil/tree/master/hdkeychain) provides an API for bitcoin hierarchical deterministic extended keys (BIP0032).  Go HD Wallet (https://github.com/WeMeetAgain/go-hdwallet).
 
 A JavaScript implementation is available at https://github.com/sarchar/brainwallet.github.com/tree/bip32
 

From ca48f2ce30ca937983bd006e30d783f4e9e3ec61 Mon Sep 17 00:00:00 2001
From: Mike Hearn 
Date: Thu, 10 Jul 2014 16:18:29 +0200
Subject: [PATCH 148/181] BIP 64: getutxo message

(closes #88)
---
 bip-0064.mediawiki | 103 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 103 insertions(+)
 create mode 100644 bip-0064.mediawiki

diff --git a/bip-0064.mediawiki b/bip-0064.mediawiki
new file mode 100644
index 00000000..b03dcac1
--- /dev/null
+++ b/bip-0064.mediawiki
@@ -0,0 +1,103 @@
+
+  BIP: 64
+  Title: getutxo message
+  Author: Mike Hearn 
+  Status: Draft
+  Type: Standards Track
+  Created: 2014-06-10
+

+
+==Abstract==
+
+This document describes a small P2P protocol extension that performs UTXO lookups given a set of outpoints.
+
+==Motivation==
+
+All full Bitcoin nodes maintain a database called the unspent transaction output set. This set is
+how double spending is checked for: to be valid a transaction must identify unspent outputs in this
+set using an identifier called an "outpoint", which is merely the hash of the output's containing
+transaction plus an index.
+
+The ability to query this can sometimes be useful for a lightweight/SPV client which does not have
+the full UTXO set at hand. For example, it can be useful in applications implementing assurance
+contracts to do a quick check when a new pledge becomes visible to test whether that pledge was
+already revoked via a double spend. Although this message is not strictly necessary because e.g.
+such an app could be implemented by fully downloading and storing the block chain, it is useful for
+obtaining acceptable performance and resolving various UI cases.
+
+Another example of when this data can be useful is for performing floating fee calculations in an
+SPV wallet. This use case requires some other changes to the Bitcoin protocol however, so we will
+not dwell on it here.
+
+==Specification==
+
+Two new messages are defined. The "getutxos" message has the following structure:
+
+{|class="wikitable"
+! Field Size !! Description !! Data type !! Comments
+|-
+| 1 || check mempool || bool || Whether to apply mempool transactions during the calculation, thus exposing their UTXOs and removing outputs that they spend.
+|-
+| ? || outpoints || vector || The list of outpoints to be queried. Each outpoint is serialized in the same way it is in a tx message.
+|}
+
+The response message "utxos" has the following structure:
+
+{|class="wikitable"
+! Field Size !! Description !! Data type !! Comments
+|-
+| 4 || chain height || uint32 || The height of the chain at the moment the result was calculated.
+|-
+| 32 || chain tip hash || uint256 || Block hash of the top of the chain at the moment the result was calculated.
+|-
+| ? || hit bitmap || byte[] || An array of bytes encoding one bit for each outpoint queried. Each bit indicates whether the queried outpoint was found in the UTXO set or not.
+|-
+| ? || result utxos || result[] || A list of result objects (defined below), one for each outpoint that is unspent (i.e. has a bit set in the bitmap).
+|}
+
+The result object is defined as:
+
+{|class="wikitable"
+! Field Size !! Description !! Data type !! Comments
+|-
+| 4 || tx version || uint32 || The version number of the transaction the UTXO was found in.
+|-
+| 4 || height || uint32 || The height of the block containing the defining transaction, or 0x7FFFFFFF if the tx is in the mempool.
+|-
+| ? || output || CTxOut || The output itself, serialized in the same way as in a tx message.
+|}
+
+==Backward compatibility==
+
+Nodes indicate support by advertising a protocol version above 70003 and by setting a new
+NODE_GETUTXO flag in their nServices field, which has a value of 2 (the second bit of the field).
+
+==Authentication==
+
+The UTXO set is not currently authenticated by anything. There are proposals to resolve this by
+introducing a new consensus rule that commits to a root hash of the UTXO set in blocks, however this
+feature is not presently available in the Bitcoin protocol. Once it is, the utxos message could be
+upgraded to include Merkle branches showing inclusion of the UTXOs in the committed sets.
+
+If the requesting client is looking up outputs for a signed transaction that they have locally, the
+client can partly verify the returned output by running the input scripts with it. Currently this
+verifies only that the script is correct. A future version of the Bitcoin protocol is likely to also
+allow the value to be checked in this way. It does not show that the output is really unspent or was
+ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey 
+should be checked before execution to ensure the remote peer doesn't just set the script to OP_TRUE.
+
+If the requesting client has a mapping of chain heights to block hashes in the best chain e.g.
+obtained via getheaders, then they can obtain a proof that the output did at one point exist by
+requesting the block and searching for the output within it. When combined with Bloom filtering this
+can be reasonably efficient.
+
+Note that even when the outputs are being checked against something this protocol has the same
+security model as Bloom filtering: a remote node can lie through omission by claiming the requested
+UTXO does not exist / was already spent (they are the same, from the perspective of a full node).
+Querying multiple nodes and combining their answers can be a partial solution to this, although as
+nothing authenticates the Bitcoin P2P network a man in the middle could still yield incorrect
+results.
+
+==Implementation==
+
+https://github.com/bitcoin/bitcoin/pull/4351/files
\ No newline at end of file

From 89902494429a677a194bed43c789158f3dd4afe5 Mon Sep 17 00:00:00 2001
From: bip39jp 
Date: Fri, 15 Aug 2014 01:21:48 +0900
Subject: [PATCH 149/181] BIP0039 Added Japanese wordlist

---
 bip-0039.mediawiki    |   13 +
 bip-0039/japanese.txt | 2048 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 2061 insertions(+)
 create mode 100644 bip-0039/japanese.txt

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index eb60fffd..56bb9aa8 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -112,6 +112,19 @@ will make the desired wallet available.
 ==Wordlists==
 
 * [[bip-0039/english.txt|English]]
+* [[bip-0039/japanese.txt|Japanese]]
+
+===Wordlists (Special Considerations)===
+
+====Japanese====
+1. Users will most likely separate the words with UTF-8 ideographic space.
+(UTF-8 bytes: 0xE38080) When splitting for validation or joining for generation, replace
+all instances of ascii space with the ideographic space, and in case of a mixture of space
+types, also replace just before seed generation.
+
+2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the
+ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily
+for two smaller words (This would be a problem with any of the 3 character sets in Japanese)
 
 ==Test vectors==
 
diff --git a/bip-0039/japanese.txt b/bip-0039/japanese.txt
new file mode 100644
index 00000000..aa7673fc
--- /dev/null
+++ b/bip-0039/japanese.txt
@@ -0,0 +1,2048 @@
+あい
+あいこくしん
+あう
+あお
+あおぞら
+あか
+あかちゃん
+あき
+あきる
+あく
+あさ
+あさひ
+あし
+あずき
+あせ
+あそぶ
+あたる
+あつい
+あな
+あに
+あね
+あひる
+あまい
+あみ
+あめ
+あめりか
+あやまる
+あゆむ
+あらいぐま
+あらし
+あり
+ある
+あれ
+あわ
+あんこ
+いう
+いえ
+いおん
+いか
+いがい
+いかいよう
+いけ
+いけん
+いこく
+いこつ
+いさん
+いし
+いじゅう
+いす
+いせい
+いせえび
+いせかい
+いせき
+いそうろう
+いそがしい
+いたりあ
+いてざ
+いてん
+いと
+いない
+いなか
+いぬ
+いね
+いのち
+いのる
+いはつ
+いはん
+いびき
+いひん
+いふく
+いへん
+いほう
+いま
+いみ
+いみん
+いも
+いもうと
+いもたれ
+いもり
+いや
+いやす
+いよかん
+いよく
+いらい
+いらすと
+いりぐち
+いりょう
+いりょうひ
+いる
+いれい
+いれもの
+いれる
+いろ
+いろえんぴつ
+いわ
+いわう
+いわかん
+いんげんまめ
+うえ
+うおざ
+うかぶ
+うきわ
+うく
+うくらいな
+うくれれ
+うけつぐ
+うけつけ
+うける
+うごく
+うこん
+うさぎ
+うし
+うしなう
+うしろ
+うしろがみ
+うすい
+うすぎ
+うせつ
+うそ
+うた
+うちあわせ
+うちがわ
+うちき
+うつ
+うなぎ
+うなじ
+うに
+うねる
+うのう
+うぶげ
+うぶごえ
+うま
+うまれる
+うみ
+うむ
+うめ
+うめる
+うもう
+うやまう
+うよく
+うら
+うらない
+うる
+うるさい
+うれしい
+うろこ
+うわき
+うわさ
+えい
+えいえん
+えいが
+えいぎょう
+えいご
+えおり
+えき
+えきたい
+えくせる
+えさ
+えしゃく
+えすて
+えつらん
+えと
+えのぐ
+えび
+えほうまき
+えほん
+えま
+えまき
+えもじ
+えもの
+えらい
+えらぶ
+えり
+えりあ
+える
+えん
+えんえん
+おきる
+おく
+おけ
+おこる
+おしえる
+おやゆび
+おらんだ
+かあつ
+かい
+かう
+かお
+かがし
+かき
+かく
+かこ
+かさ
+かす
+かち
+かつ
+かなざわし
+かに
+かね
+かのう
+かほう
+かほご
+かまぼこ
+かみ
+かむ
+かめれおん
+かも
+かゆい
+からい
+かるい
+かろう
+かわ
+かわら
+きあい
+きあつ
+きいろ
+ぎいん
+きうい
+きうん
+きえる
+きおう
+きおく
+きおち
+きおん
+きか
+きかい
+きかく
+きかん
+きかんしゃ
+きぎ
+ききて
+きく
+きくばり
+きくらげ
+きけん
+きけんせい
+きこう
+きこえる
+きこく
+きさい
+きさく
+きさま
+きさらぎ
+きし
+きしゅ
+きす
+きすう
+きせい
+きせき
+きせつ
+きそ
+きそう
+きそく
+きぞく
+ぎそく
+きぞん
+きた
+きたえる
+きち
+きちょう
+きつえん
+きつつき
+きつね
+きてい
+きどう
+きどく
+きない
+きなが
+きぬ
+きぬごし
+きねん
+きのう
+きはく
+きびしい
+きひん
+きふ
+ぎふ
+きふく
+ぎぼ
+きほう
+きぼう
+きほん
+きまる
+きみ
+きみつ
+ぎむ
+きむずかしい
+きめ
+きめる
+きもだめし
+きもち
+きやく
+きよう
+きらい
+きらく
+きり
+きる
+きれい
+きれつ
+きろく
+ぎろん
+きわめる
+ぐあい
+くい
+くいず
+くうかん
+くうき
+くうぐん
+くうこう
+くうそう
+くうふく
+くうぼ
+くかん
+くき
+くきょう
+くげん
+ぐこう
+くさ
+くさい
+くさき
+くさばな
+くさる
+くし
+くしゃみ
+くしょう
+くすのき
+くすり
+くすりゆび
+くせ
+くせげ
+くせん
+くたびれる
+くち
+くちこみ
+くちさき
+くつ
+くつした
+くつろぐ
+くとうてん
+くどく
+くなん
+くに
+くねくね
+くのう
+くふう
+くま
+くみあわせ
+くみたてる
+くむ
+くめる
+くやくしょ
+くらす
+くり
+くれる
+くろ
+くろう
+くわしい
+ぐんじょ
+けあな
+けいけん
+けいこ
+けいさい
+けいさつ
+げいのうじん
+けいれき
+けいれつ
+けいれん
+けいろ
+けおとす
+けおりもの
+けが
+げき
+げきか
+げきげん
+げきだん
+げきちん
+げきど
+げきは
+げきやく
+げこう
+げこくじょう
+けさ
+げざい
+けさき
+げざん
+けしき
+けしごむ
+けしょう
+けす
+げすと
+けた
+げた
+けたば
+けち
+けちゃっぷ
+けちらす
+けつ
+けつあつ
+けつい
+けつえき
+けっこん
+けつじょ
+けってい
+けつまつ
+げつようび
+げつれい
+けつろん
+げどく
+けとばす
+けとる
+けなげ
+けなす
+けなみ
+けぬき
+げねつ
+けねん
+けはい
+げひん
+けぶかい
+げぼく
+けまり
+けみかる
+けむし
+けむり
+けもの
+けらい
+ける
+げろ
+けろけろ
+けわしい
+けんい
+けんえつ
+けんお
+けんか
+げんき
+けんきゅう
+けんきょ
+けんけい
+けんけつ
+けんげん
+けんこう
+けんさ
+けんさく
+けんしゅう
+けんしゅつ
+けんしん
+けんすう
+けんそう
+げんそう
+けんそん
+げんち
+けんちく
+けんてい
+げんてい
+けんとう
+けんない
+けんにん
+げんぶつ
+けんま
+けんみん
+けんめい
+けんらん
+けんり
+けんりつ
+こあくま
+こい
+ごい
+こいびと
+こうい
+こうえん
+こうか
+こうかい
+こうかん
+こうさい
+こうさん
+こうしん
+こうず
+こうすい
+こうせん
+こうそう
+こうそく
+こうたい
+こうちゃ
+こうつう
+こうてい
+こうとうぶ
+こうない
+こうはい
+こうはん
+こうもく
+こえ
+こえる
+こおり
+ごがつ
+こかん
+こく
+こくご
+こくない
+こくはく
+こけい
+こける
+ここ
+こころ
+ごさ
+こさめ
+こし
+こしつ
+こす
+こすう
+こせい
+こせき
+こぜん
+こそだて
+こたい
+こたえる
+こたつ
+こちょう
+こっか
+こつこつ
+こつばん
+こつぶ
+こてい
+こてん
+こと
+ことがら
+ことし
+こなごな
+こねこね
+このまま
+このみ
+このよ
+こはん
+ごはん
+ごび
+こひつじ
+こふう
+こふん
+こぼれる
+ごま
+こまかい
+こまつし
+こまつな
+こまる
+こむ
+こむぎこ
+こめ
+こもじ
+こもち
+こもの
+こもん
+こや
+こやく
+こやま
+こゆう
+こゆび
+こよい
+こよう
+こりる
+こる
+これくしょん
+ころっけ
+こわもて
+こわれる
+こん
+こんいん
+こんかい
+こんき
+こんしゅう
+こんしゅん
+こんすい
+こんだて
+こんだん
+こんとん
+こんなん
+こんびに
+こんぽう
+こんぽん
+こんまけ
+こんや
+こんやく
+こんれい
+こんわく
+さいかい
+さいがい
+さいきん
+さいご
+さいこん
+さいしょ
+さうな
+さお
+さかいし
+さかな
+さかみち
+さき
+さく
+さくし
+さくじょ
+さくひん
+さくら
+さけ
+さこく
+さこつ
+さたん
+さつえい
+さっか
+さっきょく
+さつじん
+さつたば
+さつまいも
+さてい
+さといも
+さとう
+さとおや
+さとる
+さのう
+さば
+さばく
+さべつ
+さほう
+さほど
+さます
+さみしい
+さみだれ
+さむけ
+さめ
+さめる
+さやえんどう
+さゆう
+さよう
+さよく
+さら
+さらだ
+さる
+さわやか
+さわる
+さんいん
+さんか
+さんきゃく
+さんこう
+さんさい
+さんざん
+さんすう
+さんせい
+さんそ
+さんそん
+さんち
+さんちょう
+さんま
+さんみ
+さんらん
+しあい
+しあげ
+しあさって
+しあわせ
+しいく
+しいん
+しうち
+しえい
+しお
+しおけ
+しか
+しかい
+しかく
+じかん
+した
+したぎ
+したて
+したみ
+しちょう
+しちょうそん
+しちりん
+じつじ
+してい
+してき
+してつ
+してん
+しとう
+じどう
+しなぎれ
+しなもの
+しなん
+しねま
+しねん
+しのぐ
+しのぶ
+しはい
+しばかり
+しはつ
+じはつ
+しはらい
+しはん
+しひょう
+じふ
+しふく
+じぶん
+しへい
+しほう
+しほん
+しま
+しまう
+しまる
+しみ
+じみ
+しみん
+じむ
+しむける
+しめい
+しめる
+しもん
+しゃいん
+しゃうん
+しゃおん
+しゃかい
+じゃがいも
+しやくしょ
+しゃくほう
+しゃけん
+しゃこ
+しゃこう
+しゃざい
+しゃしん
+しゃせん
+しゃそう
+しゃたい
+しゃたく
+しゃちょう
+しゃっきん
+じゃま
+じゃり
+しゃりょう
+しゃりん
+しゃれい
+しゅうえん
+しゅうかい
+しゅうきん
+しゅうけい
+しゅうりょう
+しゅらば
+しょうか
+しょうかい
+しょうきん
+しょうじき
+しょくざい
+しょくたく
+しょっけん
+しょどう
+しょもつ
+しん
+しんか
+しんこう
+しんせいじ
+しんちく
+しんりん
+すあげ
+すあし
+すあな
+ずあん
+すいか
+すいとう
+すう
+すうがく
+すうじつ
+すうせん
+すおどり
+すき
+すきま
+すく
+すくう
+すくない
+すける
+すこし
+ずさん
+すし
+すずしい
+すすめる
+すそ
+ずっしり
+ずっと
+すで
+すてき
+すてる
+すな
+すなっく
+すなっぷ
+すね
+すねる
+すのこ
+すはだ
+すばらしい
+ずひょう
+ずぶぬれ
+すぶり
+すふれ
+すべて
+すべる
+ずほう
+すぼん
+すまい
+すみ
+すむ
+すめし
+すもう
+すやき
+すらいす
+すらいど
+すらすら
+すり
+する
+するめ
+すれちがう
+すろっと
+すわる
+すんぜん
+すんぽう
+せあぶら
+せいか
+せいかい
+せいかつ
+せおう
+せかい
+せかいかん
+せかいし
+せかいじゅう
+せき
+せきにん
+せきむ
+せきゆ
+せきらんうん
+せけん
+せこう
+せすじ
+せたい
+せたけ
+せっかい
+せっかく
+せっき
+せっきゃく
+せっきょく
+せっきん
+ぜっく
+せっけん
+せっこつ
+せっさたくま
+せつぞく
+せつだん
+せつでん
+せっぱん
+せつび
+せつぶん
+せつめい
+せつりつ
+せと
+せなか
+せのび
+せはば
+せぼね
+せまい
+せまる
+せみ
+せめる
+せもたれ
+せりふ
+せわ
+せん
+ぜんあく
+せんい
+せんえい
+せんか
+せんきょ
+せんく
+せんけつ
+せんげん
+ぜんご
+せんさい
+せんし
+せんしゅ
+せんす
+せんすい
+せんせい
+せんぞ
+せんそう
+せんたく
+せんち
+せんちゃ
+せんちゃく
+せんちょう
+せんてい
+せんとう
+せんぬき
+せんねん
+ぜんぶ
+せんぷうき
+せんぷく
+ぜんぽう
+せんむ
+せんめい
+せんめんじょ
+せんもん
+せんやく
+せんゆう
+せんよう
+ぜんら
+ぜんりゃく
+せんりょく
+せんれい
+せんろ
+そあく
+そいとげる
+そいね
+そう
+ぞう
+そうがんきょう
+そうき
+そうご
+そうなん
+そうび
+そうひょう
+そうめん
+そうり
+そうりょ
+そえもの
+そえん
+そかい
+そがい
+そぐ
+そげき
+そこう
+そこそこ
+そざい
+そし
+そしな
+そせい
+そせん
+そそぐ
+そだてる
+そつう
+そつえん
+そっかん
+そつぎょう
+そっけつ
+そっこう
+そっせん
+そっと
+そで
+そと
+そとがわ
+そとづら
+そなえる
+そなた
+そば
+そふ
+そふぼ
+そぼ
+そぼく
+そぼろ
+そまつ
+そまる
+そむく
+そむりえ
+そめる
+そもそも
+そよかぜ
+そら
+そらまめ
+そり
+そる
+そろう
+そんかい
+そんけい
+そんざい
+そんしつ
+そんしょう
+そんぞく
+そんちょう
+ぞんび
+ぞんぶん
+そんみん
+たあい
+たいいん
+たいうん
+たいえき
+たいおう
+だいおう
+たいか
+たいかい
+たいき
+たいきけん
+たいぐう
+たいくつ
+たいけい
+たいけつ
+たいけん
+たいこ
+たいこう
+たいさ
+たいさん
+たいしゅつ
+だいじょうぶ
+たいしょく
+だいず
+だいすき
+たいせい
+たいせつ
+たいせん
+たいそう
+たいちょう
+だいちょう
+たいとう
+たいない
+たいねつ
+たいのう
+たいは
+たいはん
+たいひ
+たいふう
+たいへん
+たいほ
+たいまつばな
+たいまん
+たいみんぐ
+たいむ
+たいめん
+たいやき
+たいやく
+たいよう
+たいら
+たいりょう
+たいりょく
+たいる
+たいわ
+たいわん
+たうえ
+たえる
+たおす
+たおる
+たかい
+たかね
+たき
+たきび
+たくさん
+たけ
+たこ
+たこく
+たこやき
+たさい
+ださい
+たしざん
+たす
+たすける
+たそがれ
+たたかう
+たたく
+たちば
+たちばな
+たつ
+だっかい
+だっきゃく
+だっこ
+だっしめん
+だっしゅつ
+だったい
+たて
+たてる
+たとえる
+たな
+たにん
+たぬき
+たね
+たのしみ
+たはつ
+たび
+たぶん
+たべる
+たぼう
+たほうめん
+たま
+たまご
+たまる
+だむる
+ためいき
+ためす
+ためる
+たもつ
+たやすい
+たよる
+たら
+たらす
+たりきほんがん
+たりょう
+たりる
+たる
+たると
+たれる
+たれんと
+たろっと
+たわむれる
+たん
+だんあつ
+たんい
+たんおん
+たんか
+たんき
+たんけん
+たんご
+たんさく
+たんさん
+たんし
+たんしゅく
+たんじょうび
+だんせい
+たんそく
+たんたい
+たんち
+だんち
+たんちょう
+たんてい
+たんてき
+たんとう
+だんな
+たんにん
+だんねつ
+たんのう
+たんぴん
+たんまつ
+たんめい
+だんれつ
+だんろ
+だんわ
+ちあい
+ちあん
+ちい
+ちいき
+ちいさい
+ちえ
+ちえん
+ちか
+ちかい
+ちきゅう
+ちきん
+ちけい
+ちけいず
+ちけん
+ちこく
+ちさい
+ちしき
+ちしりょう
+ちず
+ちせい
+ちそう
+ちたい
+ちたん
+ちちおや
+ちつじょ
+ちてき
+ちてん
+ちぬき
+ちぬり
+ちのう
+ちひょう
+ちへいせん
+ちほう
+ちまた
+ちみつ
+ちみどろ
+ちめいど
+ちゅうい
+ちゅうおう
+ちゅうおうく
+ちゅうがっこう
+ちゅうごく
+ちゆりょく
+ちょうさ
+ちょうし
+ちらし
+ちらみ
+ちり
+ちりがみ
+ちる
+ちるど
+ちわわ
+ちんたい
+ちんもく
+ついか
+つうか
+つうじょう
+つうじる
+つうはん
+つうわ
+つえ
+つかう
+つかれる
+つき
+つく
+つくね
+つくる
+つけね
+つける
+つごう
+つた
+つたえる
+つち
+つつじ
+つとめる
+つな
+つながる
+つなみ
+つねづね
+つの
+つのる
+つば
+つぶ
+つぶす
+つぼ
+つま
+つまらない
+つまる
+つみ
+つみき
+つむ
+つめたい
+つもる
+つや
+つよい
+つり
+つるぼ
+つるみく
+つわもの
+つわり
+てあし
+てあて
+てあみ
+ていか
+ていき
+ていけい
+ていけつ
+ていけつあつ
+ていこく
+ていさつ
+ていし
+ていしゃ
+ていせい
+ていたい
+ていど
+ていねい
+ていひょう
+ていへん
+ていぼう
+てうち
+ておくれ
+てき
+てくび
+てこ
+てさぎょう
+てさげ
+でし
+てすり
+てそう
+てちがい
+てちょう
+てつがく
+てつづき
+てつや
+でぬかえ
+てぬき
+てぬぐい
+てのひら
+てはい
+てふだ
+てほどき
+てほん
+てま
+てまえ
+てまきずし
+てみじか
+てみやげ
+てら
+てらす
+でる
+てれび
+てろ
+てわけ
+てわたし
+でんあつ
+てんい
+てんいん
+てんかい
+てんき
+てんぐ
+てんけん
+でんげん
+てんごく
+てんさい
+てんすう
+でんち
+てんてき
+てんとう
+てんない
+てんぷ
+てんぷら
+てんぼうだい
+てんめつ
+てんらく
+てんらんかい
+でんりゅう
+でんりょく
+でんわ
+どあ
+どあい
+といれ
+とうむぎ
+とおい
+とおす
+とかい
+とかす
+ときおり
+ときどき
+とくい
+とくてい
+とくてん
+とくべつ
+とけい
+とける
+とさか
+とし
+としょかん
+とそう
+とたん
+とち
+とちゅう
+とつぜん
+とつにゅう
+ととのえる
+とない
+となえる
+となり
+とのさま
+とばす
+とぶ
+とほ
+とほう
+どま
+とまる
+とら
+とり
+とる
+とんかつ
+ない
+ないか
+ないかく
+ないこう
+ないしょ
+ないす
+ないせん
+ないそう
+ないぞう
+なおす
+なく
+なこうど
+なさけ
+なし
+なす
+なぜ
+なぞ
+なたでここ
+なつ
+なっとう
+なつやすみ
+ななおし
+なにごと
+なにもの
+なにわ
+なは
+なび
+なふだ
+なべ
+なまいき
+なまえ
+なまみ
+なみ
+なみだ
+なめらか
+なめる
+なやむ
+ならぶ
+なる
+なれる
+なわ
+なわとび
+なわばり
+にあう
+にいがた
+にうけ
+におい
+にかい
+にがて
+にきび
+にく
+にくしみ
+にくまん
+にげる
+にさんかたんそ
+にし
+にしき
+にす
+にせもの
+にちじ
+にちじょう
+にちようび
+にっか
+にっき
+にっけい
+にっこう
+にっさん
+にっしょく
+にっすう
+にっせき
+にってい
+になう
+にほん
+にまめ
+にもつ
+にやり
+にゅういん
+にゅうか
+にゅうし
+にゅうしゃ
+にゅうだん
+にゅうぶ
+にら
+にりんしゃ
+にる
+にわ
+にわとり
+にんい
+にんか
+にんき
+にんげん
+にんしき
+にんしょう
+にんしん
+にんずう
+にんそう
+にんたい
+にんち
+にんてい
+にんにく
+にんぷ
+にんまり
+にんむ
+にんめい
+にんよう
+ぬう
+ぬか
+ぬく
+ぬくもり
+ぬし
+ぬの
+ぬま
+ぬめり
+ぬらす
+ぬる
+ぬんちゃく
+ねあげ
+ねいき
+ねいる
+ねいろ
+ねぎ
+ねぐせ
+ねくたい
+ねくら
+ねこ
+ねこぜ
+ねこむ
+ねさげ
+ねすごす
+ねそべる
+ねつい
+ねつぞう
+ねったい
+ねったいぎょ
+ねぶそく
+ねふだ
+ねぼう
+ねほりはほり
+ねまき
+ねまわし
+ねみみ
+ねむい
+ねもと
+ねらう
+ねる
+ねわざ
+ねんいり
+ねんおし
+ねんかん
+ねんき
+ねんきん
+ねんぐ
+ねんざ
+ねんし
+ねんちゃく
+ねんちょう
+ねんど
+ねんぴ
+ねんぶつ
+ねんまく
+ねんまつ
+ねんりき
+ねんりょう
+ねんれい
+のいず
+のう
+のおづま
+のがす
+のきなみ
+のこぎり
+のこす
+のせる
+のぞく
+のぞむ
+のたまう
+のちほど
+のっく
+のばす
+のはら
+のべる
+のぼる
+のむ
+のやま
+のらいぬ
+のらねこ
+のり
+のる
+のれん
+のんき
+ばあい
+はあく
+ばあさん
+はい
+ばいか
+ばいく
+はいけん
+はいご
+はいこう
+はいし
+はいしゅつ
+はいしん
+はいすい
+はいせつ
+はいせん
+はいそう
+はいち
+ばいばい
+はう
+はえ
+はえる
+はおる
+はか
+ばか
+はかい
+はかる
+はき
+はく
+はくしゅ
+はけん
+はこ
+はこぶ
+はさみ
+はさん
+はし
+はしご
+はしる
+ばす
+はせる
+ぱそこん
+はそん
+はたん
+はち
+はちみつ
+はっか
+はっかく
+はっき
+はっきり
+はっくつ
+はっけん
+はっこう
+はっさん
+はっしゃ
+はっしん
+はったつ
+はっちゃく
+はっちゅう
+はってん
+はっぴょう
+はっぽう
+はて
+はな
+はなす
+はなび
+はにかむ
+はね
+はは
+はぶらし
+はま
+はみがき
+はむ
+はむかう
+はめつ
+はやい
+はら
+はらう
+はり
+はる
+はれ
+はろうぃん
+はわい
+はんい
+はんえい
+はんえん
+はんおん
+はんかく
+はんかち
+はんきょう
+はんこ
+はんこう
+はんしゃ
+はんしん
+はんすう
+はんたい
+はんだん
+ぱんち
+ぱんつ
+はんてい
+はんてん
+はんとし
+はんのう
+はんぱ
+はんぶん
+はんぺん
+はんぼうき
+はんめい
+はんめん
+はんらん
+はんろん
+ひいき
+ひうん
+ひえる
+ひかく
+ひかり
+ひかん
+ひく
+ひくい
+ひけつ
+ひこうき
+ひこく
+ひざ
+ぴざ
+ひさい
+ひさしぶり
+ひさん
+ひし
+ひじ
+ひしょ
+ひじょう
+ひそか
+ひそむ
+ひたむき
+ひたる
+ひつぎ
+ひっこし
+ひっし
+ひっす
+ひつぜん
+ひつよう
+ひてい
+ひと
+ひとごみ
+ひな
+ひなん
+ひねる
+ひはん
+ひびく
+ひひょう
+ひふ
+ひほう
+ひま
+ひまん
+ひみつ
+ひめ
+ひめい
+ひめじし
+ひも
+ひやけ
+ひやす
+ひゆ
+ひよう
+びょうき
+ひらく
+ひりつ
+ひりょう
+ひる
+ひれい
+ひろい
+ひろう
+ひわ
+ひんかく
+ひんけつ
+ひんこん
+ひんし
+ひんしつ
+ひんしゅ
+ひんそう
+ぴんち
+ひんぱん
+びんぼう
+ふあん
+ふいうち
+ふうけい
+ふうせん
+ふうとう
+ふうふ
+ふえ
+ふえる
+ふおん
+ふか
+ふかい
+ふきん
+ふく
+ふくざつ
+ふこう
+ふさい
+ふざい
+ふしぎ
+ふじみ
+ふすま
+ふせい
+ふせぐ
+ふそく
+ふた
+ふたん
+ふち
+ふちょう
+ふつう
+ふっかつ
+ふっき
+ふっきん
+ふっこく
+ふとる
+ふとん
+ふね
+ふのう
+ふはい
+ふひょう
+ふへん
+ふまん
+ふみん
+ふむ
+ふめつ
+ふめん
+ふゆ
+ふよう
+ふりこ
+ふりる
+ふる
+ふるい
+ふろ
+ふんいき
+ふんか
+ぶんか
+ぶんぐ
+ふんしつ
+ぶんせき
+ふんそう
+へい
+へいき
+へいさ
+へいわ
+へきが
+へこむ
+へそ
+へた
+べつ
+べっど
+ぺっと
+へび
+へや
+へる
+へんか
+へんかん
+へんきゃく
+へんきん
+へんさい
+へんたい
+ほあん
+ほいく
+ほうほう
+ほえる
+ほおん
+ほかん
+ほきょう
+ぼきん
+ほくろ
+ほけつ
+ほけん
+ほこう
+ほこる
+ほさ
+ほし
+ほしつ
+ほしゅ
+ほしょう
+ほす
+ほせい
+ぼせい
+ほそい
+ほそく
+ほたて
+ほたる
+ぼち
+ほっきょく
+ほっさ
+ほったん
+ほとんど
+ほめる
+ほる
+ほんい
+ほんき
+ほんけ
+ほんしつ
+まいにち
+まう
+まかい
+まかせる
+まく
+まける
+まこと
+まさつ
+ますく
+まぜる
+まち
+まつ
+まつり
+まとめ
+まなぶ
+まぬけ
+まね
+まねく
+まひ
+まほう
+まめ
+まもる
+まゆげ
+まよう
+まる
+まろやか
+まわす
+まわり
+まんが
+まんかい
+まんきつ
+まんぞく
+みいら
+みうち
+みかた
+みかん
+みぎ
+みけん
+みこん
+みすい
+みすえる
+みせ
+みそ
+みち
+みてい
+みとめる
+みなみかさい
+みねらる
+みのう
+みほん
+みみ
+みもと
+みやげ
+みらい
+みりょく
+みる
+みわく
+むえき
+むえん
+むかし
+むく
+むこ
+むさぼる
+むし
+むすこ
+むすめ
+むせる
+むせん
+むだ
+むち
+むなしい
+むね
+むのう
+むやみ
+むよう
+むら
+むり
+むりょう
+むれ
+むろん
+もうどうけん
+もえる
+もぎ
+もくし
+もくてき
+もし
+もんく
+もんだい
+やすい
+やすみ
+やそう
+やたい
+やちん
+やね
+やぶる
+やま
+やみ
+やめる
+ややこしい
+やよい
+やり
+やわらかい
+ゆけつ
+ゆしゅつ
+ゆせん
+ゆそう
+ゆたか
+ゆちゃく
+ゆでる
+ゆび
+ゆびわ
+ゆめ
+ゆれる
+よう
+よかぜ
+よかん
+よきん
+よくせい
+よくぼう
+よけい
+よさん
+よそう
+よそく
+よち
+よてい
+よどがわく
+よねつ
+よむ
+よめ
+よやく
+よゆう
+よる
+よろこぶ
+らいう
+らくがき
+らくご
+らくさつ
+らくだ
+らくたん
+らしんばん
+らせん
+らぞく
+らたい
+らち
+らっか
+らっかせい
+られつ
+りえき
+りか
+りかい
+りきさく
+りきせつ
+りく
+りくぐん
+りくつ
+りけん
+りこう
+りし
+りす
+りせい
+りそう
+りそく
+りてん
+りねん
+りゅう
+りゆう
+りゅうがく
+りゅうこう
+りゅうし
+りゅうねん
+りよう
+りょうかい
+りょうきん
+りょうしん
+りょうて
+りょうど
+りょうほう
+りょうり
+りりく
+りれき
+りろん
+りんご
+るいじ
+るす
+れいかん
+れいぎ
+れいせい
+れいぞうこ
+れいとう
+れきし
+れきだい
+れんあい
+れんけい
+れんけつ
+れんこう
+れんこん
+れんさ
+れんさい
+れんさく
+れんしゃ
+れんしゅう
+れんぞく
+ろうか
+ろうご
+ろうじん
+ろうそく
+ろか
+ろくが
+ろこつ
+ろしゅつ
+ろせん
+ろてん
+ろめん
+ろれつ
+ろんぎ
+ろんぱ
+ろんぶん
+ろんり
+わじまし

From 2248c1dc74dd6c251473039561d63bdf811c1261 Mon Sep 17 00:00:00 2001
From: bip39jp 
Date: Sat, 16 Aug 2014 01:51:56 +0900
Subject: [PATCH 150/181] Moved wordlists to separate file.

---
 bip-0039.mediawiki             | 15 +--------------
 bip-0039/bip-0039-wordlists.md | 17 +++++++++++++++++
 2 files changed, 18 insertions(+), 14 deletions(-)
 create mode 100644 bip-0039/bip-0039-wordlists.md

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index 56bb9aa8..5c71fa06 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -111,20 +111,7 @@ will make the desired wallet available.
 
 ==Wordlists==
 
-* [[bip-0039/english.txt|English]]
-* [[bip-0039/japanese.txt|Japanese]]
-
-===Wordlists (Special Considerations)===
-
-====Japanese====
-1. Users will most likely separate the words with UTF-8 ideographic space.
-(UTF-8 bytes: 0xE38080) When splitting for validation or joining for generation, replace
-all instances of ascii space with the ideographic space, and in case of a mixture of space
-types, also replace just before seed generation.
-
-2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the
-ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily
-for two smaller words (This would be a problem with any of the 3 character sets in Japanese)
+* [[bip-0039/bip-0039-wordlists.md|Moved to separate document]]
 
 ==Test vectors==
 
diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md
new file mode 100644
index 00000000..1fc9e60d
--- /dev/null
+++ b/bip-0039/bip-0039-wordlists.md
@@ -0,0 +1,17 @@
+#Wordlists
+
+* [English](bip-0039/english.txt)
+* [Japanese](bip-0039/japanese.txt)
+
+##Wordlists (Special Considerations)
+
+###Japanese
+
+1. Users will most likely separate the words with UTF-8 ideographic space.  
+(UTF-8 bytes: 0xE38080) When splitting for validation or joining for generation, replace  
+all instances of ascii space with the ideographic space, and in case of a mixture of space  
+types, also replace just before seed generation.
+
+2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the  
+ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily  
+for two smaller words (This would be a problem with any of the 3 character sets in Japanese)
\ No newline at end of file

From 96c3b102fe7d309e66fe9f7533a15f103124c823 Mon Sep 17 00:00:00 2001
From: Perlover 
Date: Sat, 16 Aug 2014 22:14:00 +0200
Subject: [PATCH 151/181] Added two BIP44 compatible wallets in Android

Subj :)
Please update info, not only the Trezor is copatible with BIP44 standard :)
---
 bip-0044.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index 4a8b3219..c8077820 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -263,6 +263,8 @@ is required. This can be done [[https://github.com/satoshilabs/docs/blob/master/
 ==Compatible wallets==
 
 * [[https://mytrezor.com|myTREZOR web wallet]] ([[https://github.com/trezor/webwallet|source]])
+* [[https://play.google.com/store/apps/details?id=com.bonsai.wallet32|Wallet32 @ Android]] ([[https://github.com/ksedgwic/Wallet32|source]])
+* [[https://play.google.com/store/apps/details?id=com.bonsai.btcreceive|BTCReceive (Watch-only wallet) @ Android]] ([[https://github.com/ksedgwic/BTCReceive|source]])
 
 ==Reference==
 

From c12b7ad7c32aca147cd73c7542643afe58ea7166 Mon Sep 17 00:00:00 2001
From: Perlover 
Date: Sun, 17 Aug 2014 20:01:46 +0200
Subject: [PATCH 152/181] BTCReceive works only with one account

It seems that it is only compatible with BIP32
---
 bip-0044.mediawiki | 1 -
 1 file changed, 1 deletion(-)

diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index c8077820..e9d6e385 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -264,7 +264,6 @@ is required. This can be done [[https://github.com/satoshilabs/docs/blob/master/
 
 * [[https://mytrezor.com|myTREZOR web wallet]] ([[https://github.com/trezor/webwallet|source]])
 * [[https://play.google.com/store/apps/details?id=com.bonsai.wallet32|Wallet32 @ Android]] ([[https://github.com/ksedgwic/Wallet32|source]])
-* [[https://play.google.com/store/apps/details?id=com.bonsai.btcreceive|BTCReceive (Watch-only wallet) @ Android]] ([[https://github.com/ksedgwic/BTCReceive|source]])
 
 ==Reference==
 

From 3000cd57380ee3b1caaf4c5eac5d25cd27ca0964 Mon Sep 17 00:00:00 2001
From: jurov 
Date: Thu, 21 Aug 2014 21:58:06 +0200
Subject: [PATCH 153/181] Added Haskell implemetation.

Tested it and confirm it's functional.
---
 bip-0032.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index 3ef2d9ec..db13b065 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -275,6 +275,8 @@ A PHP implemetation is available at https://github.com/Bit-Wasp/bitcoin-lib-php
 
 A C# implementation is available at https://github.com/NicolasDorier/NBitcoin (ExtKey, ExtPubKey)
 
+A Haskell implementation is available at https://github.com/haskoin/haskoin
+
 ==Acknowledgements==
 
 * Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.

From 2402e67d8b003353543b3d735196326799072363 Mon Sep 17 00:00:00 2001
From: jurov 
Date: Thu, 21 Aug 2014 23:18:05 +0200
Subject: [PATCH 154/181] Passphrase for test vectors + haskell implementation

---
 bip-0039.mediawiki | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index eb60fffd..c849d93a 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -115,7 +115,8 @@ will make the desired wallet available.
 
 ==Test vectors==
 
-See https://github.com/trezor/python-mnemonic/blob/master/vectors.json
+These vectors use "TREZOR" string as passphrase - see
+https://github.com/trezor/python-mnemonic/blob/master/vectors.json 
 
 ==Reference Implementation==
 
@@ -127,3 +128,5 @@ http://github.com/trezor/python-mnemonic
 
 Objective-C - https://github.com/nybex/NYMnemonic
 
+Haskell - https://github.com/haskoin/haskoin
+

From 12b2dc08a4402ccd8611fe0489a9e09530a3b580 Mon Sep 17 00:00:00 2001
From: Andreas Schildbach 
Date: Sat, 16 Aug 2014 10:14:55 +0200
Subject: [PATCH 155/181] BIP43: Block usage 0 because it's already used in
 BIP32. It would be unfortunate if BIP32 wallets would at one day overlap
 BIP43 wallets.

---
 bip-0043.mediawiki | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bip-0043.mediawiki b/bip-0043.mediawiki
index 14936f63..8f20fc8c 100644
--- a/bip-0043.mediawiki
+++ b/bip-0043.mediawiki
@@ -41,6 +41,9 @@ from overlapping BIP32 spaces.
 
 Example: Scheme described in BIP44 should use 44' (or 0x8000002C) as purpose.
 
+Note that m / 0' / * is already taken by BIP32 (default account), which
+preceded this BIP.
+
 Not all wallets may want to support the full range of features and possibilities
 described in these BIPs. Instead of choosing arbitrary subset of defined features
 and calling themselves BIPxx compatible, we suggest that software which needs

From 1901f2c80752369517b0d0f9273ac86dd26c445a Mon Sep 17 00:00:00 2001
From: bip39JP 
Date: Tue, 26 Aug 2014 02:11:11 +0900
Subject: [PATCH 156/181] Fixed wordlist links to account for new document

---
 bip-0039/bip-0039-wordlists.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md
index 1fc9e60d..01a0d62b 100644
--- a/bip-0039/bip-0039-wordlists.md
+++ b/bip-0039/bip-0039-wordlists.md
@@ -1,7 +1,7 @@
 #Wordlists
 
-* [English](bip-0039/english.txt)
-* [Japanese](bip-0039/japanese.txt)
+* [English](english.txt)
+* [Japanese](japanese.txt)
 
 ##Wordlists (Special Considerations)
 
@@ -14,4 +14,4 @@ types, also replace just before seed generation.
 
 2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the  
 ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily  
-for two smaller words (This would be a problem with any of the 3 character sets in Japanese)
\ No newline at end of file
+for two smaller words (This would be a problem with any of the 3 character sets in Japanese)

From af052992200c6492d92f4c62e3641c044b5347a3 Mon Sep 17 00:00:00 2001
From: bip39JP 
Date: Tue, 26 Aug 2014 02:17:55 +0900
Subject: [PATCH 157/181] Clarify the normalization will fix mixed space use

---
 bip-0039/bip-0039-wordlists.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md
index 01a0d62b..05b3aab9 100644
--- a/bip-0039/bip-0039-wordlists.md
+++ b/bip-0039/bip-0039-wordlists.md
@@ -8,9 +8,9 @@
 ###Japanese
 
 1. Users will most likely separate the words with UTF-8 ideographic space.  
-(UTF-8 bytes: 0xE38080) When splitting for validation or joining for generation, replace  
-all instances of ascii space with the ideographic space, and in case of a mixture of space  
-types, also replace just before seed generation.
+(UTF-8 bytes: 0xE38080) When generating the seed, normalization as per the spec will
+automatically change these into normal ASCII spaces. Depending on the font, displaying the
+words should use the UTF-8 ideographic space if it looks like the symbols are too close.
 
 2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the  
 ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily  

From a2029e165b2c1031f4212210d0320725ee1c3ec2 Mon Sep 17 00:00:00 2001
From: Andrew Poelstra 
Date: Tue, 26 Aug 2014 19:56:17 -0700
Subject: [PATCH 158/181] Clarify identifier serialization

I had a tough time interpreting "serialization of the public key", which is hashed to get the extended key identifier. Since the very next section is "Serialization format [for extended keys]" I thought that I was supposed to use the serialization of the /extended/ public key. Then I noticed "ignoring the chain code", so I tried skipping that part of the extended key serialization. Then I realized that what was meant was "the `K` half of `(K, c)`".
---
 bip-0032.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index db13b065..01e1c835 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -113,7 +113,7 @@ Each leaf node in the tree corresponds to an actual key, while the internal node
 
 ===Key identifiers===
 
-Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself).
+Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized ECSDA public key K, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself).
 
 The first 32 bits of the identifier are called the key fingerprint.
 

From 8d90ebe9dbbda967e9e973ac7376c3cff4d10f42 Mon Sep 17 00:00:00 2001
From: jurov 
Date: Mon, 1 Sep 2014 22:36:16 +0200
Subject: [PATCH 159/181] Reverted test vectors passphrase info.

There's pull request for it already.
---
 bip-0039.mediawiki | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index c849d93a..2658685d 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -115,8 +115,7 @@ will make the desired wallet available.
 
 ==Test vectors==
 
-These vectors use "TREZOR" string as passphrase - see
-https://github.com/trezor/python-mnemonic/blob/master/vectors.json 
+See https://github.com/trezor/python-mnemonic/blob/master/vectors.json 
 
 ==Reference Implementation==
 

From 3675b3aa02e87dbcb2f25ec81bd57368ae1836a1 Mon Sep 17 00:00:00 2001
From: jurov 
Date: Mon, 1 Sep 2014 22:37:06 +0200
Subject: [PATCH 160/181] Removed spurious space.

---
 bip-0039.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index 2658685d..b0642e8a 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -115,7 +115,7 @@ will make the desired wallet available.
 
 ==Test vectors==
 
-See https://github.com/trezor/python-mnemonic/blob/master/vectors.json 
+See https://github.com/trezor/python-mnemonic/blob/master/vectors.json
 
 ==Reference Implementation==
 

From 2272a1fc9e1e2f3d6283e6c5f954856bbe21dd79 Mon Sep 17 00:00:00 2001
From: Y75QMO 
Date: Tue, 2 Sep 2014 20:56:50 +0200
Subject: [PATCH 161/181] Create spanish.txt

---
 bip-0039/spanish.txt | 2048 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 2048 insertions(+)
 create mode 100644 bip-0039/spanish.txt

diff --git a/bip-0039/spanish.txt b/bip-0039/spanish.txt
new file mode 100644
index 00000000..d0900c2c
--- /dev/null
+++ b/bip-0039/spanish.txt
@@ -0,0 +1,2048 @@
+ábaco
+abdomen
+abeja
+abierto
+abogado
+abono
+aborto
+abrazo
+abrir
+abuelo
+abuso
+acabar
+academia
+acceso
+acción
+aceite
+acelga
+acento
+aceptar
+ácido
+aclarar
+acné
+acoger
+acoso
+activo
+acto
+actriz
+actuar
+acudir
+acuerdo
+acusar
+adicto
+admitir
+adoptar
+adorno
+aduana
+adulto
+aéreo
+afectar
+afición
+afinar
+afirmar
+ágil
+agitar
+agonía
+agosto
+agotar
+agregar
+agrio
+agua
+agudo
+águila
+aguja
+ahogo
+ahorro
+aire
+aislar
+ajedrez
+ajeno
+ajuste
+alacrán
+alambre
+alarma
+alba
+álbum
+alcalde
+aldea
+alegre
+alejar
+alerta
+aleta
+alfiler
+alga
+algodón
+aliado
+aliento
+alivio
+alma
+almeja
+almíbar
+altar
+alteza
+altivo
+alto
+altura
+alumno
+alzar
+amable
+amante
+amapola
+amargo
+amasar
+ámbar
+ámbito
+ameno
+amigo
+amistad
+amor
+amparo
+amplio
+ancho
+anciano
+ancla
+andar
+andén
+anemia
+ángulo
+anillo
+ánimo
+anís
+anotar
+antena
+antiguo
+antojo
+anual
+anular
+anuncio
+añadir
+añejo
+año
+apagar
+aparato
+apetito
+apio
+aplicar
+apodo
+aporte
+apoyo
+aprender
+aprobar
+apuesta
+apuro
+arado
+araña
+arar
+árbitro
+árbol
+arbusto
+archivo
+arco
+arder
+ardilla
+arduo
+área
+árido
+aries
+armonía
+arnés
+aroma
+arpa
+arpón
+arreglo
+arroz
+arruga
+arte
+artista
+asa
+asado
+asalto
+ascenso
+asegurar
+aseo
+asesor
+asiento
+asilo
+asistir
+asno
+asombro
+áspero
+astilla
+astro
+astuto
+asumir
+asunto
+atajo
+ataque
+atar
+atento
+ateo
+ático
+atleta
+átomo
+atraer
+atroz
+atún
+audaz
+audio
+auge
+aula
+aumento
+ausente
+autor
+aval
+avance
+avaro
+ave
+avellana
+avena
+avestruz
+avión
+aviso
+ayer
+ayuda
+ayuno
+azafrán
+azar
+azote
+azúcar
+azufre
+azul
+baba
+babor
+bache
+bahía
+baile
+bajar
+balanza
+balcón
+balde
+bambú
+banco
+banda
+baño
+barba
+barco
+barniz
+barro
+báscula
+bastón
+basura
+batalla
+batería
+batir
+batuta
+baúl
+bazar
+bebé
+bebida
+bello
+besar
+beso
+bestia
+bicho
+bien
+bingo
+blanco
+bloque
+blusa
+boa
+bobina
+bobo
+boca
+bocina
+boda
+bodega
+boina
+bola
+bolero
+bolsa
+bomba
+bondad
+bonito
+bono
+bonsái
+borde
+borrar
+bosque
+bote
+botín
+bóveda
+bozal
+bravo
+brazo
+brecha
+breve
+brillo
+brinco
+brisa
+broca
+broma
+bronce
+brote
+bruja
+brusco
+bruto
+buceo
+bucle
+bueno
+buey
+bufanda
+bufón
+búho
+buitre
+bulto
+burbuja
+burla
+burro
+buscar
+butaca
+buzón
+caballo
+cabeza
+cabina
+cabra
+cacao
+cadáver
+cadena
+caer
+café
+caída
+caimán
+caja
+cajón
+cal
+calamar
+calcio
+caldo
+calidad
+calle
+calma
+calor
+calvo
+cama
+cambio
+camello
+camino
+campo
+cáncer
+candil
+canela
+canguro
+canica
+canto
+caña
+cañón
+caoba
+caos
+capaz
+capitán
+capote
+captar
+capucha
+cara
+carbón
+cárcel
+careta
+carga
+cariño
+carne
+carpeta
+carro
+carta
+casa
+casco
+casero
+caspa
+castor
+catorce
+catre
+caudal
+causa
+cazo
+cebolla
+ceder
+cedro
+celda
+célebre
+celoso
+célula
+cemento
+ceniza
+centro
+cerca
+cerdo
+cereza
+cero
+cerrar
+certeza
+césped
+cetro
+chacal
+chaleco
+champú
+chancla
+chapa
+charla
+chico
+chiste
+chivo
+choque
+choza
+chuleta
+chupar
+ciclón
+ciego
+cielo
+cien
+cierto
+cifra
+cigarro
+cima
+cinco
+cine
+cinta
+ciprés
+circo
+ciruela
+cisne
+cita
+ciudad
+clamor
+clan
+claro
+clase
+clave
+cliente
+clima
+clínica
+cobre
+cocción
+cochino
+cocina
+coco
+código
+codo
+cofre
+coger
+cohete
+cojín
+cojo
+cola
+colcha
+colegio
+colgar
+colina
+collar
+colmo
+columna
+combate
+comer
+comida
+cómodo
+compra
+conde
+conejo
+conga
+conocer
+consejo
+contar
+copa
+copia
+corazón
+corbata
+corcho
+cordón
+corona
+correr
+coser
+cosmos
+costa
+cráneo
+cráter
+crear
+crecer
+creído
+crema
+cría
+crimen
+cripta
+crisis
+cromo
+crónica
+croqueta
+crudo
+cruz
+cuadro
+cuarto
+cuatro
+cubo
+cubrir
+cuchara
+cuello
+cuento
+cuerda
+cuesta
+cueva
+cuidar
+culebra
+culpa
+culto
+cumbre
+cumplir
+cuna
+cuneta
+cuota
+cupón
+cúpula
+curar
+curioso
+curso
+curva
+cutis
+dama
+danza
+dar
+dardo
+dátil
+deber
+débil
+década
+decir
+dedo
+defensa
+definir
+dejar
+delfín
+delgado
+delito
+demora
+denso
+dental
+deporte
+derecho
+derrota
+desayuno
+deseo
+desfile
+desnudo
+destino
+desvío
+detalle
+detener
+deuda
+día
+diablo
+diadema
+diamante
+diana
+diario
+dibujo
+dictar
+diente
+dieta
+diez
+difícil
+digno
+dilema
+diluir
+dinero
+directo
+dirigir
+disco
+diseño
+disfraz
+diva
+divino
+doble
+doce
+dolor
+domingo
+don
+donar
+dorado
+dormir
+dorso
+dos
+dosis
+dragón
+droga
+ducha
+duda
+duelo
+dueño
+dulce
+dúo
+duque
+durar
+dureza
+duro
+ébano
+ebrio
+echar
+eco
+ecuador
+edad
+edición
+edificio
+editor
+educar
+efecto
+eficaz
+eje
+ejemplo
+elefante
+elegir
+elemento
+elevar
+elipse
+élite
+elixir
+elogio
+eludir
+embudo
+emitir
+emoción
+empate
+empeño
+empleo
+empresa
+enano
+encargo
+enchufe
+encía
+enemigo
+enero
+enfado
+enfermo
+engaño
+enigma
+enlace
+enorme
+enredo
+ensayo
+enseñar
+entero
+entrar
+envase
+envío
+época
+equipo
+erizo
+escala
+escena
+escolar
+escribir
+escudo
+esencia
+esfera
+esfuerzo
+espada
+espejo
+espía
+esposa
+espuma
+esquí
+estar
+este
+estilo
+estufa
+etapa
+eterno
+ética
+etnia
+evadir
+evaluar
+evento
+evitar
+exacto
+examen
+exceso
+excusa
+exento
+exigir
+exilio
+existir
+éxito
+experto
+explicar
+exponer
+extremo
+fábrica
+fábula
+fachada
+fácil
+factor
+faena
+faja
+falda
+fallo
+falso
+faltar
+fama
+familia
+famoso
+faraón
+farmacia
+farol
+farsa
+fase
+fatiga
+fauna
+favor
+fax
+febrero
+fecha
+feliz
+feo
+feria
+feroz
+fértil
+fervor
+festín
+fiable
+fianza
+fiar
+fibra
+ficción
+ficha
+fideo
+fiebre
+fiel
+fiera
+fiesta
+figura
+fijar
+fijo
+fila
+filete
+filial
+filtro
+fin
+finca
+fingir
+finito
+firma
+flaco
+flauta
+flecha
+flor
+flota
+fluir
+flujo
+flúor
+fobia
+foca
+fogata
+fogón
+folio
+folleto
+fondo
+forma
+forro
+fortuna
+forzar
+fosa
+foto
+fracaso
+frágil
+franja
+frase
+fraude
+freír
+freno
+fresa
+frío
+frito
+fruta
+fuego
+fuente
+fuerza
+fuga
+fumar
+función
+funda
+furgón
+furia
+fusil
+fútbol
+futuro
+gacela
+gafas
+gaita
+gajo
+gala
+galería
+gallo
+gamba
+ganar
+gancho
+ganga
+ganso
+garaje
+garza
+gasolina
+gastar
+gato
+gavilán
+gemelo
+gemir
+gen
+género
+genio
+gente
+geranio
+gerente
+germen
+gesto
+gigante
+gimnasio
+girar
+giro
+glaciar
+globo
+gloria
+gol
+golfo
+goloso
+golpe
+goma
+gordo
+gorila
+gorra
+gota
+goteo
+gozar
+grada
+gráfico
+grano
+grasa
+gratis
+grave
+grieta
+grillo
+gripe
+gris
+grito
+grosor
+grúa
+grueso
+grumo
+grupo
+guante
+guapo
+guardia
+guerra
+guía
+guiño
+guion
+guiso
+guitarra
+gusano
+gustar
+haber
+hábil
+hablar
+hacer
+hacha
+hada
+hallar
+hamaca
+harina
+haz
+hazaña
+hebilla
+hebra
+hecho
+helado
+helio
+hembra
+herir
+hermano
+héroe
+hervir
+hielo
+hierro
+hígado
+higiene
+hijo
+himno
+historia
+hocico
+hogar
+hoguera
+hoja
+hombre
+hongo
+honor
+honra
+hora
+hormiga
+horno
+hostil
+hoyo
+hueco
+huelga
+huerta
+hueso
+huevo
+huida
+huir
+humano
+húmedo
+humilde
+humo
+hundir
+huracán
+hurto
+icono
+ideal
+idioma
+ídolo
+iglesia
+iglú
+igual
+ilegal
+ilusión
+imagen
+imán
+imitar
+impar
+imperio
+imponer
+impulso
+incapaz
+índice
+inerte
+infiel
+informe
+ingenio
+inicio
+inmenso
+inmune
+innato
+insecto
+instante
+interés
+íntimo
+intuir
+inútil
+invierno
+ira
+iris
+ironía
+isla
+islote
+jabalí
+jabón
+jamón
+jarabe
+jardín
+jarra
+jaula
+jazmín
+jefe
+jeringa
+jinete
+jornada
+joroba
+joven
+joya
+juerga
+jueves
+juez
+jugador
+jugo
+juguete
+juicio
+junco
+jungla
+junio
+juntar
+júpiter
+jurar
+justo
+juvenil
+juzgar
+kilo
+koala
+labio
+lacio
+lacra
+lado
+ladrón
+lagarto
+lágrima
+laguna
+laico
+lamer
+lámina
+lámpara
+lana
+lancha
+langosta
+lanza
+lápiz
+largo
+larva
+lástima
+lata
+látex
+latir
+laurel
+lavar
+lazo
+leal
+lección
+leche
+lector
+leer
+legión
+legumbre
+lejano
+lengua
+lento
+leña
+león
+leopardo
+lesión
+letal
+letra
+leve
+leyenda
+libertad
+libro
+licor
+líder
+lidiar
+lienzo
+liga
+ligero
+lima
+límite
+limón
+limpio
+lince
+lindo
+línea
+lingote
+lino
+linterna
+líquido
+liso
+lista
+litera
+litio
+litro
+llaga
+llama
+llanto
+llave
+llegar
+llenar
+llevar
+llorar
+llover
+lluvia
+lobo
+loción
+loco
+locura
+lógica
+logro
+lombriz
+lomo
+lonja
+lote
+lucha
+lucir
+lugar
+lujo
+luna
+lunes
+lupa
+lustro
+luto
+luz
+maceta
+macho
+madera
+madre
+maduro
+maestro
+mafia
+magia
+mago
+maíz
+maldad
+maleta
+malla
+malo
+mamá
+mambo
+mamut
+manco
+mando
+manejar
+manga
+maniquí
+manjar
+mano
+manso
+manta
+mañana
+mapa
+máquina
+mar
+marco
+marea
+marfil
+margen
+marido
+mármol
+marrón
+martes
+marzo
+masa
+máscara
+masivo
+matar
+materia
+matiz
+matriz
+máximo
+mayor
+mazorca
+mecha
+medalla
+medio
+médula
+mejilla
+mejor
+melena
+melón
+memoria
+menor
+mensaje
+mente
+menú
+mercado
+merengue
+mérito
+mes
+mesón
+meta
+meter
+método
+metro
+mezcla
+miedo
+miel
+miembro
+miga
+mil
+milagro
+militar
+millón
+mimo
+mina
+minero
+mínimo
+minuto
+miope
+mirar
+misa
+miseria
+misil
+mismo
+mitad
+mito
+mochila
+moción
+moda
+modelo
+moho
+mojar
+molde
+moler
+molino
+momento
+momia
+monarca
+moneda
+monja
+monto
+moño
+morada
+morder
+moreno
+morir
+morro
+morsa
+mortal
+mosca
+mostrar
+motivo
+mover
+móvil
+mozo
+mucho
+mudar
+mueble
+muela
+muerte
+muestra
+mugre
+mujer
+mula
+muleta
+multa
+mundo
+muñeca
+mural
+muro
+músculo
+museo
+musgo
+música
+muslo
+nácar
+nación
+nadar
+naipe
+naranja
+nariz
+narrar
+nasal
+natal
+nativo
+natural
+náusea
+naval
+nave
+navidad
+necio
+néctar
+negar
+negocio
+negro
+neón
+nervio
+neto
+neutro
+nevar
+nevera
+nicho
+nido
+niebla
+nieto
+niñez
+niño
+nítido
+nivel
+nobleza
+noche
+nómina
+noria
+norma
+norte
+nota
+noticia
+novato
+novela
+novio
+nube
+nuca
+núcleo
+nudillo
+nudo
+nuera
+nueve
+nuez
+nulo
+número
+nutria
+oasis
+obeso
+obispo
+objeto
+obra
+obrero
+observar
+obtener
+obvio
+oca
+ocaso
+océano
+ochenta
+ocho
+ocio
+ocre
+octavo
+octubre
+oculto
+ocupar
+ocurrir
+odiar
+odio
+odisea
+oeste
+ofensa
+oferta
+oficio
+ofrecer
+ogro
+oído
+oír
+ojo
+ola
+oleada
+olfato
+olivo
+olla
+olmo
+olor
+olvido
+ombligo
+onda
+onza
+opaco
+opción
+ópera
+opinar
+oponer
+optar
+óptica
+opuesto
+oración
+orador
+oral
+órbita
+orca
+orden
+oreja
+órgano
+orgía
+orgullo
+oriente
+origen
+orilla
+oro
+orquesta
+oruga
+osadía
+oscuro
+osezno
+oso
+ostra
+otoño
+otro
+oveja
+óvulo
+óxido
+oxígeno
+oyente
+ozono
+pacto
+padre
+paella
+página
+pago
+país
+pájaro
+palabra
+palco
+paleta
+pálido
+palma
+paloma
+palpar
+pan
+panal
+pánico
+pantera
+pañuelo
+papá
+papel
+papilla
+paquete
+parar
+parcela
+pared
+parir
+paro
+párpado
+parque
+párrafo
+parte
+pasar
+paseo
+pasión
+paso
+pasta
+pata
+patio
+patria
+pausa
+pauta
+pavo
+payaso
+peatón
+pecado
+pecera
+pecho
+pedal
+pedir
+pegar
+peine
+pelar
+peldaño
+pelea
+peligro
+pellejo
+pelo
+peluca
+pena
+pensar
+peñón
+peón
+peor
+pepino
+pequeño
+pera
+percha
+perder
+pereza
+perfil
+perico
+perla
+permiso
+perro
+persona
+pesa
+pesca
+pésimo
+pestaña
+pétalo
+petróleo
+pez
+pezuña
+picar
+pichón
+pie
+piedra
+pierna
+pieza
+pijama
+pilar
+piloto
+pimienta
+pino
+pintor
+pinza
+piña
+piojo
+pipa
+pirata
+pisar
+piscina
+piso
+pista
+pitón
+pizca
+placa
+plan
+plata
+playa
+plaza
+pleito
+pleno
+plomo
+pluma
+plural
+pobre
+poco
+poder
+podio
+poema
+poesía
+poeta
+polen
+policía
+pollo
+polvo
+pomada
+pomelo
+pomo
+pompa
+poner
+porción
+portal
+posada
+poseer
+posible
+poste
+potencia
+potro
+pozo
+prado
+precoz
+pregunta
+premio
+prensa
+preso
+previo
+primo
+príncipe
+prisión
+privar
+proa
+probar
+proceso
+producto
+proeza
+profesor
+programa
+prole
+promesa
+pronto
+propio
+próximo
+prueba
+público
+puchero
+pudor
+pueblo
+puerta
+puesto
+pulga
+pulir
+pulmón
+pulpo
+pulso
+puma
+punto
+puñal
+puño
+pupa
+pupila
+puré
+quedar
+queja
+quemar
+querer
+queso
+quieto
+química
+quince
+quitar
+rábano
+rabia
+rabo
+ración
+radical
+raíz
+rama
+rampa
+rancho
+rango
+rapaz
+rápido
+rapto
+rasgo
+raspa
+rato
+rayo
+raza
+razón
+reacción
+realidad
+rebaño
+rebote
+recaer
+receta
+rechazo
+recoger
+recreo
+recto
+recurso
+red
+redondo
+reducir
+reflejo
+reforma
+refrán
+refugio
+regalo
+regir
+regla
+regreso
+rehén
+reino
+reír
+reja
+relato
+relevo
+relieve
+relleno
+reloj
+remar
+remedio
+remo
+rencor
+rendir
+renta
+reparto
+repetir
+reposo
+reptil
+res
+rescate
+resina
+respeto
+resto
+resumen
+retiro
+retorno
+retrato
+reunir
+revés
+revista
+rey
+rezar
+rico
+riego
+rienda
+riesgo
+rifa
+rígido
+rigor
+rincón
+riñón
+río
+riqueza
+risa
+ritmo
+rito
+rizo
+roble
+roce
+rociar
+rodar
+rodeo
+rodilla
+roer
+rojizo
+rojo
+romero
+romper
+ron
+ronco
+ronda
+ropa
+ropero
+rosa
+rosca
+rostro
+rotar
+rubí
+rubor
+rudo
+rueda
+rugir
+ruido
+ruina
+ruleta
+rulo
+rumbo
+rumor
+ruptura
+ruta
+rutina
+sábado
+saber
+sabio
+sable
+sacar
+sagaz
+sagrado
+sala
+saldo
+salero
+salir
+salmón
+salón
+salsa
+salto
+salud
+salvar
+samba
+sanción
+sandía
+sanear
+sangre
+sanidad
+sano
+santo
+sapo
+saque
+sardina
+sartén
+sastre
+satán
+sauna
+saxofón
+sección
+seco
+secreto
+secta
+sed
+seguir
+seis
+sello
+selva
+semana
+semilla
+senda
+sensor
+señal
+señor
+separar
+sepia
+sequía
+ser
+serie
+sermón
+servir
+sesenta
+sesión
+seta
+setenta
+severo
+sexo
+sexto
+sidra
+siesta
+siete
+siglo
+signo
+sílaba
+silbar
+silencio
+silla
+símbolo
+simio
+sirena
+sistema
+sitio
+situar
+sobre
+socio
+sodio
+sol
+solapa
+soldado
+soledad
+sólido
+soltar
+solución
+sombra
+sondeo
+sonido
+sonoro
+sonrisa
+sopa
+soplar
+soporte
+sordo
+sorpresa
+sorteo
+sostén
+sótano
+suave
+subir
+suceso
+sudor
+suegra
+suelo
+sueño
+suerte
+sufrir
+sujeto
+sultán
+sumar
+superar
+suplir
+suponer
+supremo
+sur
+surco
+sureño
+surgir
+susto
+sutil
+tabaco
+tabique
+tabla
+tabú
+taco
+tacto
+tajo
+talar
+talco
+talento
+talla
+talón
+tamaño
+tambor
+tango
+tanque
+tapa
+tapete
+tapia
+tapón
+taquilla
+tarde
+tarea
+tarifa
+tarjeta
+tarot
+tarro
+tarta
+tatuaje
+tauro
+taza
+tazón
+teatro
+techo
+tecla
+técnica
+tejado
+tejer
+tejido
+tela
+teléfono
+tema
+temor
+templo
+tenaz
+tender
+tener
+tenis
+tenso
+teoría
+terapia
+terco
+término
+ternura
+terror
+tesis
+tesoro
+testigo
+tetera
+texto
+tez
+tibio
+tiburón
+tiempo
+tienda
+tierra
+tieso
+tigre
+tijera
+tilde
+timbre
+tímido
+timo
+tinta
+tío
+típico
+tipo
+tira
+tirón
+titán
+títere
+título
+tiza
+toalla
+tobillo
+tocar
+tocino
+todo
+toga
+toldo
+tomar
+tono
+tonto
+topar
+tope
+toque
+tórax
+torero
+tormenta
+torneo
+toro
+torpedo
+torre
+torso
+tortuga
+tos
+tosco
+toser
+tóxico
+trabajo
+tractor
+traer
+tráfico
+trago
+traje
+tramo
+trance
+trato
+trauma
+trazar
+trébol
+tregua
+treinta
+tren
+trepar
+tres
+tribu
+trigo
+tripa
+triste
+triunfo
+trofeo
+trompa
+tronco
+tropa
+trote
+trozo
+truco
+trueno
+trufa
+tubería
+tubo
+tuerto
+tumba
+tumor
+túnel
+túnica
+turbina
+turismo
+turno
+tutor
+ubicar
+úlcera
+umbral
+unidad
+unir
+universo
+uno
+untar
+uña
+urbano
+urbe
+urgente
+urna
+usar
+usuario
+útil
+utopía
+uva
+vaca
+vacío
+vacuna
+vagar
+vago
+vaina
+vajilla
+vale
+válido
+valle
+valor
+válvula
+vampiro
+vara
+variar
+varón
+vaso
+vecino
+vector
+vehículo
+veinte
+vejez
+vela
+velero
+veloz
+vena
+vencer
+venda
+veneno
+vengar
+venir
+venta
+venus
+ver
+verano
+verbo
+verde
+vereda
+verja
+verso
+verter
+vía
+viaje
+vibrar
+vicio
+víctima
+vida
+vídeo
+vidrio
+viejo
+viernes
+vigor
+vil
+villa
+vinagre
+vino
+viñedo
+violín
+viral
+virgo
+virtud
+visor
+víspera
+vista
+vitamina
+viudo
+vivaz
+vivero
+vivir
+vivo
+volcán
+volumen
+volver
+voraz
+votar
+voto
+voz
+vuelo
+vulgar
+yacer
+yate
+yegua
+yema
+yerno
+yeso
+yodo
+yoga
+yogur
+zafiro
+zanja
+zapato
+zarza
+zona
+zorro
+zumo
+zurdo

From 0d0520e31269e1dd7e31a2543bc88c88cfddea13 Mon Sep 17 00:00:00 2001
From: bip39jp 
Date: Wed, 3 Sep 2014 23:49:33 +0900
Subject: [PATCH 162/181] Added Japanese test vectors

---
 bip-0039.mediawiki | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index 5c71fa06..2d2f0850 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -117,6 +117,9 @@ will make the desired wallet available.
 
 See https://github.com/trezor/python-mnemonic/blob/master/vectors.json
 
+Also see https://github.com/bip32JP/bip32JP.github.io/blob/master/test_JP_BIP39.json
+(Japanese wordlist test with heavily normalized symbols as passphrase)
+
 ==Reference Implementation==
 
 Reference implementation including wordlists is available from

From 213b67e8f81967a265b6c29e0612b578e4994a3c Mon Sep 17 00:00:00 2001
From: bip39jp 
Date: Wed, 3 Sep 2014 23:52:24 +0900
Subject: [PATCH 163/181] formatting

---
 bip-0039.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index 2d2f0850..0518d227 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -118,6 +118,7 @@ will make the desired wallet available.
 See https://github.com/trezor/python-mnemonic/blob/master/vectors.json
 
 Also see https://github.com/bip32JP/bip32JP.github.io/blob/master/test_JP_BIP39.json
+
 (Japanese wordlist test with heavily normalized symbols as passphrase)
 
 ==Reference Implementation==

From a95598390e49d2525382b2363fad07ecbe22168a Mon Sep 17 00:00:00 2001
From: Pavol Rusnak 
Date: Fri, 5 Sep 2014 22:21:50 +0200
Subject: [PATCH 164/181] bip-0044.mediawiki: fix typo

---
 bip-0044.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index 4a8b3219..bbdce65b 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -147,7 +147,7 @@ All these constants are used as hardened derivation.
 |}
 
 This BIP is not a central directory for the registered coin types, please
-visit Satoshi Labs that maintains the full list:
+visit SatoshiLabs that maintains the full list:
 
 [[http://doc.satoshilabs.com/slips/slip-0044.html|SLIP-0044 : Registered coin types for BIP-0044]]
 

From cce1e10dc86186e99f135777c137a4cc61f63e33 Mon Sep 17 00:00:00 2001
From: Jean-Pierre Rupp 
Date: Mon, 8 Sep 2014 17:17:24 +0100
Subject: [PATCH 165/181] Changed left angles for HTML entity

---
 bip-0037.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki
index 81793934..f1561be3 100644
--- a/bip-0037.mediawiki
+++ b/bip-0037.mediawiki
@@ -195,7 +195,7 @@ When loading a filter with the filterload command, there are two pa
 
 Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable.
 
-The size S of the filter in bytes is given by (-1 / pow(log(2), 2) * N * log(P)) / 8. Of course you must ensure it does not go over the maximum size (36,000: selected as it represents a filter of 20,000 items with false positive rate of < 0.1% or 10,000 items and a false positive rate of < 0.0001%).
+The size S of the filter in bytes is given by (-1 / pow(log(2), 2) * N * log(P)) / 8. Of course you must ensure it does not go over the maximum size (36,000: selected as it represents a filter of 20,000 items with false positive rate of < 0.1% or 10,000 items and a false positive rate of < 0.0001%).
 
 The number of hash functions required is given by S * 8 / N * log(2).
 

From 68c801d18b613f7745e6be3cbb7d8242ebe7b2b3 Mon Sep 17 00:00:00 2001
From: Derren Desouza 
Date: Fri, 12 Sep 2014 08:11:39 +1000
Subject: [PATCH 166/181] Update bip-0070.mediawiki

Clarification regarding the signature field in payment details and which key should be used for signing.
---
 bip-0070.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 03baf5bd..c2f77254 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -126,7 +126,7 @@ A PaymentRequest is PaymentDetails optionally tied to a merchant's identity:
 |-
 | signature || digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message,
 with all serialized fields serialized in numerical order (all current protocol buffer implementations serialize
-fields in numerical order) and signed using the public key in pki_data. Optional fields that are not set
+fields in numerical order) and signed using the private key that corresponds to the public key in pki_data. Optional fields that are not set
 are not serialized (however, setting a field to its default value will cause it to be serialized and will affect
 the signature). Before serialization, the signature field must be set to an empty value so that the field is included in the signed PaymentRequest hash but contains no data.
 |}

From 9625a83f7069e1cb5f69268892574f61ea9f2ad5 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Sun, 7 Sep 2014 23:17:12 +0200
Subject: [PATCH 167/181] BIP62: Reorder rules and clarify

---
 bip-0062.mediawiki | 66 ++++++++++++++++++++++++++++------------------
 1 file changed, 40 insertions(+), 26 deletions(-)

diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki
index 4fd29c3f..9d5bfe57 100644
--- a/bip-0062.mediawiki
+++ b/bip-0062.mediawiki
@@ -22,39 +22,38 @@ This is a problem for multiple reasons:
 
 Several sources of malleability are known:
 
-# '''Inherent ECDSA signature malleability''' ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.
 # '''Non-DER encoded ECDSA signatures''' Right now, the Bitcoin reference client uses OpenSSL to validate signatures. As OpenSSL accepts more than serializations that strictly adhere to the DER standard, this is a source of malleability. Since v0.8.0, non-DER signatures are no longer relayed already.
-# '''Superfluous scriptSig operations''' Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.
 # '''Non-push operations in scriptSig''' Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.
 # '''Push operations in scriptSig of non-standard size type''' The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_PUSHDATA1, OP_PUSHDATA2, OP_PUSHDATA4). As the later ones have the same result as the former ones, they result in additional possibilities.
 # '''Zero-padded number pushes''' In cases where scriptPubKey opcodes use inputs that are interpreted as numbers, they can be zero padded.
+# '''Inherent ECDSA signature malleability''' ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.
+# '''Superfluous scriptSig operations''' Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.
 # '''Inputs ignored by scripts''' If a scriptPubKey starts with an OP_DROP, for example, the last data push of the corresponding scriptSig will always be ignored.
 # '''Sighash flags based masking''' Sighash flags can be used to ignore certain parts of a script when signing.
 # '''New signatures by the sender''' The sender (or anyone with access to the relevant private keys) is always able to create new signatures that spend the same inputs to the same outputs.
-The first six and part of the seventh can be fixed by extra consensus rules. The last two can't, but are always under control of the (original) sender.
+The first six and part of the seventh can be fixed by extra consensus rules, but the last two can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable. However, when restricted to using a safe set of output scripts, extra consensus rules can make spending transactions optionally non-malleable (if the spender chooses to; as he can always bypass #8 and #9 himself).
 
 ==Specification==
 
 ===New rules===
 
 Seven extra rules are introduced, to combat exactly the seven first sources of malleability listed above:
-# '''Inherent ECDSA signature malleability''' We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). To convert another signature, simply take the complement of the S value (modulo the curve order).
-# '''Non-DER encoded ECDSA signatures''' All ECDSA signatures must be encoded using strict DER encoding.
-# '''Superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the result is invalid.
-# '''Non-push operations in scriptSig''' Any non-push operation in a scriptSig invalidates it.
-# '''Push operations in scriptSig of non-standard size type''' The smallest possible push operation (including OP_0 for an empty byte vector, or the direct pushes of a single byte) must be used when possible. Using any push operation that could be encoded in a shorter way invalidates it.
-# '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed.
-# '''Inputs ignored by scripts''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script invalid.
+# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]].
+# '''Non-push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
+# '''Push operations in scriptSig of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
+# '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]].
+# '''Inherent ECDSA signature malleability''' We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). See reference: [[#low-s-values-in-signatures|Low S values in signatures]].
+# '''Superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the script evaluates to false.
+# '''Inputs ignored by scripts''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script evaluate to false.
 
 ===Block validity===
 
-To introduce these new rules in the network, we add both nVersion=3 blocks and nVersion=3 transactions (nVersion=2 is skipped for transactions in order to keep the version numbers synchronized with block version numbers).
-The same mechanism as in BIP 0034 is used to introduce nVersion=3 blocks. When 75% of the past 1000 blocks are nVersion=3, a new consensus rule is activated which requires:
-* All transactions in such blocks are required to follow rules #2 and #4.
-* nVersion>=3 transactions in such blocks are required to follow all the above rules.
-
-When 95% of the past 1000 blocks are nVersion>=3, nVersion=2 blocks become invalid entirely. Note however that nVersion=1 transactions remain valid forever.
+To introduce these new rules in the network, we add both v3 blocks and v3 transactions. v2 is skipped for transactions to keep the version numbers between transaction and block rules in sync. v2 transactions are treated identically to v1 transactions.
+The same mechanism as in BIP 0034 is used to introduce v3 blocks. When 75% of the past 1000 blocks are v3, a new consensus rule is activated:
+* All transactions in v3 blocks are required to follow rules #1-#2.
+* v3 (and higher) transactions in v3 blocks are required to follow rules #3-#7 as well.
 
+When 95% of the past 1000 blocks are v3 or higher, v2 blocks become invalid entirely. Note however that v1 (and v2) transactions remain valid forever.
 
 ===References===
 
@@ -80,18 +79,33 @@ This is already enforced by the reference client as of version 0.8.0 (only as re
 
 This rule, combined with the low S requirement above, results in S-length being at most 32 (and R-length at most 33), and the total signature size being at most 72 bytes (and on average 71.494 bytes).
 
-====Shortest possible data pushes====
-For reference:
-* Pushing an empty byte sequence (or the number 0) must use OP_0.
-* Pushing a single byte sequence of byte 0x01 through 0x10 (or the numbers 1 through 16) must use OP_n.
-* Pushing the byte 0x81 (or the number -1) must use OP_1NEGATE.
+====Push operators====
+
+* Pushing an empty byte sequence must use OP_0.
+* Pushing a 1-byte sequence of byte 0x01 through 0x10 must use OP_n.
+* Pushing the byte 0x81 must use OP_1NEGATE.
 * Pushing any other byte sequence up to 75 bytes must use the normal data push (opcode byte n, with n the number of bytes, followed n bytes of data being pushed).
-* Only pushes of more than 75 bytes can use OP_PUSHDATA1.
-* Only pushes of more than 255 bytes can use OP_PUSHDATA2.
-* OP_PUSHDATA4 can never be used, as pushes over 520 bytes are not allowed, and those below can be done using OP_PUSHDATA2.
+* Pushing 76 to 255 bytes must use OP_PUSHDATA1.
+* Pushing 256 to 520 bytes must use OP_PUSHDATA2.
+* OP_PUSHDATA4 can never be used, as pushes over 520 bytes are not allowed, and those below can be done using other operators.
+* Any other operation is not considered to be a push.
+
+====Numbers====
+
+The native data type of stack elements is byte arrays, but some operations interpret arguments as integers. The used encoding is little endian with an explicit sign bit (the highest bit of the last byte). The shortest encodings for numbers are (with the range boundaries encodings given in hex between ()).
+* 0: OP_0; (00)
+* 1..16: OP_1..OP_16; (51)..(60)
+* -1: OP_1NEGATE; (79)
+* -127..-2 and 17..127: normal 1-byte data push; (01 FF)..(01 82) and (01 11)..(01 7F)
+* -32767..-128 and 128..32767: normal 2-byte data push; (02 FF FF)..(02 80 80) and (02 80 00)..(02 FF 7F)
+* -8388607..-32768 and 32768..8388607: normal 3-byte data push; (03 FF FF FF)..(03 00 80 80) and (03 00 80 00)..(03 FF FF 7F)
+* -2147483647..-8388608 and 8388608..2147483647: normal 4-byte data push; (04 FF FF FF FF)..(04 00 00 80 80) and (04 00 00 80 00)..(04 FF FF FF 7F)
+* Any other numbers cannot be encoded.
+
+In particular, note that zero could be encoded as (01 80) (negative zero) if using the non-shortest form is allowed.
 
 ==Compatibility==
 
-'''Relay of transactions''' A new node software version is released which makes nVersion=3 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of nVersion=1 transactions is unaffected. An nVersion=1 transaction spending an output created by an nVersion=3 transaction is also unaffected.
+'''Relay of transactions''' A new node software version is released which makes v3 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of v1 transactions is unaffected. A v1 transaction spending an output created by a v3 transaction is also unaffected.
 
-'''Wallet updates''' As nVersion=3 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but setting nVersion=3 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software.
+'''Wallet updates''' As v3 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but using v3 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software.

From 98cc66a8698d07bad288145abdbd206aa5b6e6a1 Mon Sep 17 00:00:00 2001
From: vstoykovbg 
Date: Thu, 25 Sep 2014 03:55:33 +0300
Subject: [PATCH 168/181] double "are"

---
 bip-0039.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index eb60fffd..70547912 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -38,7 +38,7 @@ initial entropy length as ENT. The recommended size of ENT is 128-256 bits.
 
 First, an initial entropy of ENT bits is generated. A checksum is generated by
 taking the first 
ENT / 32
 bits of its SHA256 hash. This checksum is
-appended to the end of the initial entropy. Next, these concatenated bits are
+appended to the end of the initial entropy. Next, these concatenated bits
 are split into groups of 11 bits, each encoding a number from 0-2047, serving
 as an index to a wordlist. Later, we will convert these numbers into words and
 use the joined words as a mnemonic sentence.

From 9fda3dbf20638a36b281a788fd83f821c4958457 Mon Sep 17 00:00:00 2001
From: bip39JP 
Date: Sun, 28 Sep 2014 18:15:26 +0900
Subject: [PATCH 169/181] Wordlist update.

Brushed up wordlist:
1. First 3 characters are unique for every word.
2. No more words less than 3 characters.
---
 bip-0039/japanese.txt | 1138 ++++++++++++++++++++---------------------
 1 file changed, 569 insertions(+), 569 deletions(-)

diff --git a/bip-0039/japanese.txt b/bip-0039/japanese.txt
index aa7673fc..c4c9dca4 100644
--- a/bip-0039/japanese.txt
+++ b/bip-0039/japanese.txt
@@ -1,83 +1,129 @@
-あい
 あいこくしん
-あう
-あお
+あいさつ
+あいだ
 あおぞら
-あか
 あかちゃん
-あき
 あきる
-あく
-あさ
+あけがた
+あける
+あこがれる
+あさい
 あさひ
-あし
+あしあと
+あじわう
+あずかる
 あずき
-あせ
 あそぶ
+あたえる
+あたためる
+あたりまえ
 あたる
 あつい
-あな
-あに
-あね
+あつかう
+あっしゅく
+あつまり
+あつめる
+あてな
+あてはまる
 あひる
+あぶら
+あぶる
+あふれる
 あまい
-あみ
-あめ
+あまど
+あまやかす
+あまり
+あみもの
 あめりか
 あやまる
 あゆむ
 あらいぐま
 あらし
-あり
-ある
-あれ
-あわ
+あらすじ
+あらためる
+あらゆる
+あらわす
+ありがとう
+あわせる
+あわてる
+あんい
+あんがい
 あんこ
-いう
-いえ
+あんぜん
+あんてい
+あんない
+あんまり
+いいだす
 いおん
-いか
 いがい
-いかいよう
-いけ
+いがく
+いきおい
+いきなり
+いきもの
+いきる
+いくじ
+いくぶん
+いけばな
 いけん
+いこう
 いこく
 いこつ
+いさましい
 いさん
-いし
+いしき
 いじゅう
-いす
+いじょう
+いじわる
+いずみ
+いずれ
 いせい
 いせえび
 いせかい
 いせき
+いぜん
 いそうろう
 いそがしい
+いだい
+いだく
+いたずら
+いたみ
 いたりあ
+いちおう
+いちじ
+いちど
+いちば
+いちぶ
+いちりゅう
+いつか
+いっしゅん
+いっせい
+いっそう
+いったん
+いっち
+いってい
+いっぽう
 いてざ
 いてん
-いと
+いどう
+いとこ
 いない
 いなか
-いぬ
-いね
+いねむり
 いのち
 いのる
 いはつ
+いばる
 いはん
 いびき
 いひん
 いふく
 いへん
 いほう
-いま
-いみ
 いみん
-いも
 いもうと
 いもたれ
 いもり
-いや
+いやがる
 いやす
 いよかん
 いよく
@@ -85,132 +131,248 @@
 いらすと
 いりぐち
 いりょう
-いりょうひ
-いる
 いれい
 いれもの
 いれる
-いろ
 いろえんぴつ
-いわ
+いわい
 いわう
 いわかん
+いわば
+いわゆる
 いんげんまめ
-うえ
+いんさつ
+いんしょう
+いんよう
+うえき
+うえる
 うおざ
+うがい
 うかぶ
+うかべる
 うきわ
-うく
 うくらいな
 うくれれ
-うけつぐ
+うけたまわる
 うけつけ
+うけとる
+うけもつ
 うける
+うごかす
 うごく
 うこん
 うさぎ
-うし
 うしなう
-うしろ
 うしろがみ
 うすい
 うすぎ
+うすぐらい
+うすめる
 うせつ
-うそ
-うた
 うちあわせ
 うちがわ
 うちき
-うつ
+うちゅう
+うっかり
+うつくしい
+うったえる
+うつる
+うどん
 うなぎ
 うなじ
-うに
+うなずく
+うなる
 うねる
 うのう
 うぶげ
 うぶごえ
-うま
 うまれる
-うみ
-うむ
-うめ
 うめる
 うもう
 うやまう
 うよく
-うら
+うらがえす
+うらぐち
 うらない
-うる
+うりあげ
+うりきれ
 うるさい
 うれしい
+うれゆき
+うれる
 うろこ
 うわき
 うわさ
-えい
+うんこう
+うんちん
+うんてん
+うんどう
 えいえん
 えいが
-えいぎょう
+えいきょう
 えいご
+えいせい
+えいぶん
+えいよう
+えいわ
 えおり
-えき
+えがお
+えがく
 えきたい
 えくせる
-えさ
 えしゃく
 えすて
 えつらん
-えと
 えのぐ
-えび
 えほうまき
 えほん
-えま
 えまき
 えもじ
 えもの
 えらい
 えらぶ
-えり
 えりあ
-える
-えん
 えんえん
+えんかい
+えんぎ
+えんげき
+えんしゅう
+えんぜつ
+えんそく
+えんちょう
+えんとつ
+おいかける
+おいこす
+おいしい
+おいつく
+おうえん
+おうさま
+おうじ
+おうせつ
+おうたい
+おうふく
+おうべい
+おうよう
+おえる
+おおい
+おおう
+おおどおり
+おおや
+おおよそ
+おかえり
+おかず
+おがむ
+おかわり
+おぎなう
 おきる
-おく
-おけ
+おくさま
+おくじょう
+おくりがな
+おくる
+おくれる
+おこす
+おこなう
 おこる
+おさえる
+おさない
+おさめる
+おしいれ
 おしえる
+おじぎ
+おじさん
+おしゃれ
+おそらく
+おそわる
+おたがい
+おたく
+おだやか
+おちつく
+おっと
+おつり
+おでかけ
+おとしもの
+おとなしい
+おどり
+おどろかす
+おばさん
+おまいり
+おめでとう
+おもいで
+おもう
+おもたい
+おもちゃ
+おやつ
 おやゆび
+およぼす
 おらんだ
+おろす
+おんがく
+おんけい
+おんしゃ
+おんせん
+おんだん
+おんちゅう
+おんどけい
 かあつ
-かい
-かう
-かお
+かいが
+がいき
+がいけん
+がいこう
+かいさつ
+かいしゃ
+かいすいよく
+かいぜん
+かいぞうど
+かいつう
+かいてん
+かいとう
+かいふく
+がいへき
+かいほう
+かいよう
+がいらい
+かいわ
+かえる
+かおり
+かかえる
+かがく
 かがし
-かき
-かく
-かこ
-かさ
-かす
-かち
-かつ
+かがみ
+かくご
+かくとく
+かざる
+がぞう
+かたい
+かたち
+がちょう
+がっきゅう
+がっこう
+がっさん
+がっしょう
 かなざわし
-かに
-かね
 かのう
+がはく
+かぶか
 かほう
 かほご
+かまう
 かまぼこ
-かみ
-かむ
 かめれおん
-かも
 かゆい
+かようび
 からい
 かるい
 かろう
-かわ
+かわく
 かわら
+がんか
+かんけい
+かんこう
+かんしゃ
+かんそう
+かんたん
+かんち
+がんばる
 きあい
 きあつ
 きいろ
@@ -222,17 +384,12 @@
 きおく
 きおち
 きおん
-きか
 きかい
 きかく
-きかん
 きかんしゃ
-きぎ
 ききて
-きく
 きくばり
 きくらげ
-きけん
 きけんせい
 きこう
 きこえる
@@ -241,24 +398,22 @@
 きさく
 きさま
 きさらぎ
-きし
-きしゅ
-きす
+ぎじかがく
+ぎしき
+ぎじたいけん
+ぎじにってい
+ぎじゅつしゃ
 きすう
 きせい
 きせき
 きせつ
-きそ
 きそう
-きそく
 きぞく
-ぎそく
 きぞん
-きた
 きたえる
-きち
 きちょう
 きつえん
+ぎっちり
 きつつき
 きつね
 きてい
@@ -266,140 +421,132 @@
 きどく
 きない
 きなが
-きぬ
+きなこ
 きぬごし
 きねん
 きのう
+きのした
 きはく
 きびしい
 きひん
-きふ
-ぎふ
 きふく
-ぎぼ
-きほう
+きぶん
 きぼう
 きほん
 きまる
-きみ
 きみつ
-ぎむ
 きむずかしい
-きめ
 きめる
 きもだめし
 きもち
+きもの
+きゃく
 きやく
+ぎゅうにく
 きよう
+きょうりゅう
 きらい
 きらく
-きり
-きる
+きりん
 きれい
 きれつ
 きろく
 ぎろん
 きわめる
+ぎんいろ
+きんかくじ
+きんじょ
+きんようび
 ぐあい
-くい
 くいず
 くうかん
 くうき
 くうぐん
 くうこう
+ぐうせい
 くうそう
+ぐうたら
 くうふく
 くうぼ
 くかん
-くき
 くきょう
 くげん
 ぐこう
-くさ
 くさい
 くさき
 くさばな
 くさる
-くし
 くしゃみ
 くしょう
 くすのき
-くすり
 くすりゆび
-くせ
 くせげ
 くせん
+ぐたいてき
+くださる
 くたびれる
-くち
 くちこみ
 くちさき
-くつ
 くつした
+ぐっすり
 くつろぐ
 くとうてん
 くどく
 くなん
-くに
 くねくね
 くのう
 くふう
-くま
 くみあわせ
 くみたてる
-くむ
 くめる
 くやくしょ
 くらす
-くり
+くらべる
+くるま
 くれる
-くろ
 くろう
 くわしい
-ぐんじょ
+ぐんかん
+ぐんしょく
+ぐんたい
+ぐんて
 けあな
+けいかく
 けいけん
 けいこ
-けいさい
 けいさつ
+げいじゅつ
+けいたい
 げいのうじん
 けいれき
-けいれつ
-けいれん
 けいろ
 けおとす
 けおりもの
-けが
-げき
 げきか
 げきげん
 げきだん
 げきちん
-げきど
+げきとつ
 げきは
 げきやく
 げこう
 げこくじょう
-けさ
 げざい
 けさき
 げざん
 けしき
 けしごむ
 けしょう
-けす
 げすと
-けた
-げた
 けたば
-けち
 けちゃっぷ
 けちらす
-けつ
 けつあつ
 けつい
 けつえき
 けっこん
 けつじょ
+けっせき
 けってい
 けつまつ
 げつようび
@@ -424,8 +571,6 @@
 けむり
 けもの
 けらい
-ける
-げろ
 けろけろ
 けわしい
 けんい
@@ -433,25 +578,14 @@
 けんお
 けんか
 げんき
-けんきゅう
-けんきょ
-けんけい
-けんけつ
 けんげん
 けんこう
-けんさ
 けんさく
 けんしゅう
-けんしゅつ
-けんしん
 けんすう
-けんそう
 げんそう
-けんそん
-げんち
 けんちく
 けんてい
-げんてい
 けんとう
 けんない
 けんにん
@@ -461,51 +595,49 @@
 けんめい
 けんらん
 けんり
-けんりつ
 こあくま
-こい
-ごい
+こいぬ
 こいびと
-こうい
+ごうい
 こうえん
-こうか
-こうかい
+こうおん
 こうかん
+ごうきゅう
+ごうけい
+こうこう
 こうさい
-こうさん
-こうしん
-こうず
+こうじ
 こうすい
-こうせん
-こうそう
+ごうせい
 こうそく
 こうたい
 こうちゃ
 こうつう
 こうてい
-こうとうぶ
+こうどう
 こうない
 こうはい
-こうはん
+ごうほう
+ごうまん
 こうもく
-こえ
+こうりつ
 こえる
 こおり
+ごかい
 ごがつ
-こかん
-こく
+ごかん
 こくご
+こくさい
+こくとう
 こくない
 こくはく
+こぐま
 こけい
 こける
-ここ
+ここのか
 こころ
-ごさ
 こさめ
-こし
 こしつ
-こす
 こすう
 こせい
 こせき
@@ -521,34 +653,30 @@
 こつぶ
 こてい
 こてん
-こと
 ことがら
 ことし
+ことば
+ことり
 こなごな
 こねこね
 このまま
 このみ
 このよ
-こはん
 ごはん
-ごび
 こひつじ
 こふう
 こふん
 こぼれる
-ごま
+ごまあぶら
 こまかい
-こまつし
+ごますり
 こまつな
 こまる
-こむ
 こむぎこ
-こめ
 こもじ
 こもち
 こもの
 こもん
-こや
 こやく
 こやま
 こゆう
@@ -556,65 +684,69 @@
 こよい
 こよう
 こりる
-こる
 これくしょん
 ころっけ
 こわもて
 こわれる
-こん
 こんいん
 こんかい
 こんき
 こんしゅう
-こんしゅん
 こんすい
 こんだて
-こんだん
 こんとん
 こんなん
 こんびに
-こんぽう
 こんぽん
 こんまけ
 こんや
-こんやく
 こんれい
 こんわく
+ざいえき
 さいかい
-さいがい
 さいきん
-さいご
-さいこん
+ざいげん
+ざいこ
 さいしょ
+さいせい
+ざいたく
+ざいちゅう
+さいてき
+ざいりょう
 さうな
-さお
 さかいし
+さがす
 さかな
 さかみち
-さき
-さく
+さがる
+さぎょう
 さくし
-さくじょ
 さくひん
 さくら
-さけ
 さこく
 さこつ
+さずかる
+ざせき
 さたん
 さつえい
-さっか
+ざつおん
+ざっか
+ざつがく
 さっきょく
+ざっし
 さつじん
+ざっそう
 さつたば
 さつまいも
 さてい
 さといも
 さとう
 さとおや
+さとし
 さとる
 さのう
-さば
 さばく
+さびしい
 さべつ
 さほう
 さほど
@@ -622,15 +754,13 @@
 さみしい
 さみだれ
 さむけ
-さめ
 さめる
 さやえんどう
 さゆう
 さよう
 さよく
-さら
 さらだ
-さる
+ざるそば
 さわやか
 さわる
 さんいん
@@ -638,13 +768,11 @@
 さんきゃく
 さんこう
 さんさい
-さんざん
+ざんしょ
 さんすう
 さんせい
 さんそ
-さんそん
 さんち
-さんちょう
 さんま
 さんみ
 さんらん
@@ -656,25 +784,26 @@
 しいん
 しうち
 しえい
-しお
 しおけ
-しか
 しかい
 しかく
 じかん
-した
+しごと
+しすう
+じだい
+したうけ
 したぎ
 したて
 したみ
 しちょう
-しちょうそん
 しちりん
-じつじ
+しっかり
+しつじ
+しつもん
 してい
 してき
 してつ
-してん
-しとう
+じてん
 じどう
 しなぎれ
 しなもの
@@ -686,68 +815,58 @@
 しはい
 しばかり
 しはつ
-じはつ
 しはらい
 しはん
 しひょう
-じふ
 しふく
 じぶん
 しへい
 しほう
 しほん
-しま
 しまう
 しまる
-しみ
-じみ
 しみん
-じむ
 しむける
+じむしょ
 しめい
 しめる
 しもん
 しゃいん
 しゃうん
 しゃおん
-しゃかい
 じゃがいも
 しやくしょ
 しゃくほう
 しゃけん
 しゃこ
-しゃこう
 しゃざい
 しゃしん
 しゃせん
 しゃそう
 しゃたい
-しゃたく
 しゃちょう
 しゃっきん
 じゃま
-じゃり
-しゃりょう
 しゃりん
 しゃれい
-しゅうえん
-しゅうかい
-しゅうきん
-しゅうけい
-しゅうりょう
+じゆう
+じゅうしょ
+しゅくはく
+じゅしん
+しゅっせき
+しゅみ
 しゅらば
-しょうか
+じゅんばん
 しょうかい
-しょうきん
-しょうじき
-しょくざい
 しょくたく
 しょっけん
 しょどう
 しょもつ
-しん
+しらせる
+しらべる
 しんか
 しんこう
+じんじゃ
 しんせいじ
 しんちく
 しんりん
@@ -755,34 +874,30 @@
 すあし
 すあな
 ずあん
+すいえい
 すいか
 すいとう
-すう
+ずいぶん
+すいようび
 すうがく
 すうじつ
 すうせん
 すおどり
-すき
 すきま
-すく
 すくう
 すくない
 すける
+すごい
 すこし
 ずさん
-すし
 すずしい
+すすむ
 すすめる
-すそ
+すっかり
 ずっしり
 ずっと
-すで
 すてき
 すてる
-すな
-すなっく
-すなっぷ
-すね
 すねる
 すのこ
 すはだ
@@ -796,16 +911,10 @@
 ずほう
 すぼん
 すまい
-すみ
-すむ
 すめし
 すもう
 すやき
-すらいす
-すらいど
 すらすら
-すり
-する
 するめ
 すれちがう
 すろっと
@@ -813,15 +922,12 @@
 すんぜん
 すんぽう
 せあぶら
-せいか
-せいかい
 せいかつ
+せいげん
+せいじ
+せいよう
 せおう
-せかい
 せかいかん
-せかいし
-せかいじゅう
-せき
 せきにん
 せきむ
 せきゆ
@@ -831,12 +937,8 @@
 せすじ
 せたい
 せたけ
-せっかい
 せっかく
-せっき
 せっきゃく
-せっきょく
-せっきん
 ぜっく
 せっけん
 せっこつ
@@ -849,51 +951,39 @@
 せつぶん
 せつめい
 せつりつ
-せと
 せなか
 せのび
 せはば
+せびろ
 せぼね
 せまい
 せまる
-せみ
 せめる
 せもたれ
 せりふ
-せわ
-せん
 ぜんあく
 せんい
 せんえい
 せんか
 せんきょ
 せんく
-せんけつ
 せんげん
 ぜんご
 せんさい
-せんし
 せんしゅ
-せんす
 せんすい
 せんせい
 せんぞ
-せんそう
 せんたく
-せんち
-せんちゃ
-せんちゃく
 せんちょう
 せんてい
 せんとう
 せんぬき
 せんねん
+せんぱい
 ぜんぶ
-せんぷうき
-せんぷく
 ぜんぽう
 せんむ
-せんめい
 せんめんじょ
 せんもん
 せんやく
@@ -901,33 +991,27 @@
 せんよう
 ぜんら
 ぜんりゃく
-せんりょく
 せんれい
 せんろ
 そあく
 そいとげる
 そいね
-そう
-ぞう
 そうがんきょう
 そうき
 そうご
+そうしん
+そうだん
 そうなん
 そうび
-そうひょう
 そうめん
 そうり
-そうりょ
 そえもの
 そえん
-そかい
 そがい
-そぐ
 そげき
 そこう
 そこそこ
 そざい
-そし
 そしな
 そせい
 そせん
@@ -941,16 +1025,11 @@
 そっこう
 そっせん
 そっと
-そで
-そと
 そとがわ
 そとづら
 そなえる
 そなた
-そば
-そふ
 そふぼ
-そぼ
 そぼく
 そぼろ
 そまつ
@@ -960,16 +1039,12 @@
 そめる
 そもそも
 そよかぜ
-そら
 そらまめ
-そり
-そる
 そろう
 そんかい
 そんけい
 そんざい
 そんしつ
-そんしょう
 そんぞく
 そんちょう
 ぞんび
@@ -980,100 +1055,75 @@
 たいうん
 たいえき
 たいおう
-だいおう
-たいか
-たいかい
+だいがく
 たいき
-たいきけん
 たいぐう
-たいくつ
-たいけい
-たいけつ
 たいけん
 たいこ
-たいこう
-たいさ
-たいさん
-たいしゅつ
+たいざい
 だいじょうぶ
-たいしょく
-だいず
 だいすき
-たいせい
 たいせつ
-たいせん
 たいそう
+だいたい
 たいちょう
-だいちょう
-たいとう
+たいてい
+だいどころ
 たいない
 たいねつ
 たいのう
-たいは
 たいはん
-たいひ
+だいひょう
 たいふう
 たいへん
 たいほ
 たいまつばな
-たいまん
 たいみんぐ
 たいむ
 たいめん
 たいやき
-たいやく
 たいよう
 たいら
-たいりょう
 たいりょく
 たいる
-たいわ
 たいわん
 たうえ
 たえる
 たおす
 たおる
+たおれる
 たかい
 たかね
-たき
 たきび
 たくさん
-たけ
-たこ
 たこく
 たこやき
 たさい
-ださい
 たしざん
-たす
+だじゃれ
 たすける
+たずさわる
 たそがれ
 たたかう
 たたく
-たちば
+ただしい
+たたみ
 たちばな
-たつ
 だっかい
 だっきゃく
 だっこ
-だっしめん
 だっしゅつ
 だったい
-たて
 たてる
 たとえる
-たな
+たなばた
 たにん
 たぬき
-たね
 たのしみ
 たはつ
-たび
 たぶん
 たべる
 たぼう
-たほうめん
-たま
 たまご
 たまる
 だむる
@@ -1083,18 +1133,15 @@
 たもつ
 たやすい
 たよる
-たら
 たらす
 たりきほんがん
 たりょう
 たりる
-たる
 たると
 たれる
 たれんと
 たろっと
 たわむれる
-たん
 だんあつ
 たんい
 たんおん
@@ -1102,25 +1149,20 @@
 たんき
 たんけん
 たんご
-たんさく
 たんさん
-たんし
-たんしゅく
 たんじょうび
 だんせい
 たんそく
 たんたい
-たんち
 だんち
-たんちょう
 たんてい
-たんてき
 たんとう
 だんな
 たんにん
 だんねつ
 たんのう
 たんぴん
+だんぼう
 たんまつ
 たんめい
 だんれつ
@@ -1128,23 +1170,19 @@
 だんわ
 ちあい
 ちあん
-ちい
 ちいき
 ちいさい
-ちえ
 ちえん
-ちか
 ちかい
+ちから
 ちきゅう
 ちきん
-ちけい
 ちけいず
 ちけん
 ちこく
 ちさい
 ちしき
 ちしりょう
-ちず
 ちせい
 ちそう
 ちたい
@@ -1163,65 +1201,49 @@
 ちみつ
 ちみどろ
 ちめいど
+ちゃんこなべ
 ちゅうい
-ちゅうおう
-ちゅうおうく
-ちゅうがっこう
-ちゅうごく
 ちゆりょく
-ちょうさ
 ちょうし
+ちょさくけん
 ちらし
 ちらみ
-ちり
 ちりがみ
-ちる
+ちりょう
 ちるど
 ちわわ
 ちんたい
 ちんもく
 ついか
+ついたち
 つうか
 つうじょう
-つうじる
 つうはん
 つうわ
-つえ
 つかう
 つかれる
-つき
-つく
 つくね
 つくる
 つけね
 つける
 つごう
-つた
 つたえる
-つち
+つづく
 つつじ
+つつむ
 つとめる
-つな
 つながる
 つなみ
 つねづね
-つの
 つのる
-つば
-つぶ
 つぶす
-つぼ
-つま
 つまらない
 つまる
-つみ
 つみき
-つむ
 つめたい
+つもり
 つもる
-つや
 つよい
-つり
 つるぼ
 つるみく
 つわもの
@@ -1229,15 +1251,13 @@
 てあし
 てあて
 てあみ
+ていおん
 ていか
 ていき
 ていけい
-ていけつ
-ていけつあつ
 ていこく
 ていさつ
 ていし
-ていしゃ
 ていせい
 ていたい
 ていど
@@ -1247,144 +1267,139 @@
 ていぼう
 てうち
 ておくれ
-てき
+てきとう
 てくび
-てこ
+でこぼこ
 てさぎょう
 てさげ
-でし
 てすり
 てそう
 てちがい
 てちょう
 てつがく
 てつづき
+でっぱ
+てつぼう
 てつや
 でぬかえ
 てぬき
 てぬぐい
 てのひら
 てはい
+てぶくろ
 てふだ
 てほどき
 てほん
-てま
 てまえ
 てまきずし
 てみじか
 てみやげ
-てら
 てらす
-でる
 てれび
-てろ
 てわけ
 てわたし
 でんあつ
-てんい
 てんいん
 てんかい
 てんき
 てんぐ
 てんけん
-でんげん
 てんごく
 てんさい
+てんし
 てんすう
 でんち
 てんてき
 てんとう
 てんない
-てんぷ
 てんぷら
 てんぼうだい
 てんめつ
-てんらく
 てんらんかい
-でんりゅう
 でんりょく
 でんわ
-どあ
 どあい
 といれ
+どうかん
+とうきゅう
+どうぐ
+とうし
 とうむぎ
 とおい
+とおか
+とおく
 とおす
+とおる
 とかい
 とかす
 ときおり
 ときどき
 とくい
-とくてい
+とくしゅう
 とくてん
+とくに
 とくべつ
 とけい
 とける
+とこや
 とさか
-とし
 としょかん
 とそう
 とたん
-とち
 とちゅう
+とっきゅう
+とっくん
 とつぜん
 とつにゅう
+とどける
 ととのえる
 とない
 となえる
 となり
 とのさま
 とばす
-とぶ
-とほ
+どぶがわ
 とほう
-どま
 とまる
-とら
-とり
-とる
+とめる
+ともだち
+ともる
+どようび
+とらえる
 とんかつ
-ない
-ないか
+どんぶり
 ないかく
 ないこう
 ないしょ
 ないす
 ないせん
 ないそう
-ないぞう
 なおす
-なく
+ながい
+なくす
+なげる
 なこうど
 なさけ
-なし
-なす
-なぜ
-なぞ
 なたでここ
-なつ
 なっとう
 なつやすみ
 ななおし
 なにごと
 なにもの
 なにわ
-なは
-なび
+なのか
 なふだ
-なべ
 なまいき
 なまえ
 なまみ
-なみ
 なみだ
 なめらか
 なめる
 なやむ
+ならう
+ならび
 ならぶ
-なる
 なれる
-なわ
 なわとび
 なわばり
 にあう
@@ -1394,16 +1409,12 @@
 にかい
 にがて
 にきび
-にく
 にくしみ
 にくまん
 にげる
 にさんかたんそ
-にし
 にしき
-にす
 にせもの
-にちじ
 にちじょう
 にちようび
 にっか
@@ -1421,23 +1432,13 @@
 にもつ
 にやり
 にゅういん
-にゅうか
-にゅうし
-にゅうしゃ
-にゅうだん
-にゅうぶ
-にら
 にりんしゃ
-にる
-にわ
 にわとり
 にんい
 にんか
 にんき
 にんげん
 にんしき
-にんしょう
-にんしん
 にんずう
 にんそう
 にんたい
@@ -1449,34 +1450,32 @@
 にんむ
 にんめい
 にんよう
-ぬう
-ぬか
-ぬく
+ぬいくぎ
+ぬかす
+ぬぐいとる
+ぬぐう
 ぬくもり
-ぬし
-ぬの
-ぬま
+ぬすむ
+ぬまえび
 ぬめり
 ぬらす
-ぬる
 ぬんちゃく
 ねあげ
 ねいき
 ねいる
 ねいろ
-ねぎ
 ねぐせ
 ねくたい
 ねくら
-ねこ
 ねこぜ
 ねこむ
 ねさげ
 ねすごす
 ねそべる
+ねだん
 ねつい
+ねっしん
 ねつぞう
-ねったい
 ねったいぎょ
 ねぶそく
 ねふだ
@@ -1486,35 +1485,31 @@
 ねまわし
 ねみみ
 ねむい
+ねむたい
 ねもと
 ねらう
-ねる
 ねわざ
 ねんいり
 ねんおし
 ねんかん
-ねんき
 ねんきん
 ねんぐ
 ねんざ
 ねんし
 ねんちゃく
-ねんちょう
 ねんど
 ねんぴ
 ねんぶつ
-ねんまく
 ねんまつ
-ねんりき
 ねんりょう
 ねんれい
 のいず
-のう
 のおづま
 のがす
 のきなみ
 のこぎり
 のこす
+のこる
 のせる
 のぞく
 のぞむ
@@ -1525,113 +1520,85 @@
 のはら
 のべる
 のぼる
-のむ
+のみもの
 のやま
 のらいぬ
 のらねこ
-のり
-のる
+のりもの
+のりゆき
 のれん
 のんき
 ばあい
 はあく
 ばあさん
-はい
 ばいか
 ばいく
 はいけん
 はいご
-はいこう
-はいし
-はいしゅつ
 はいしん
 はいすい
-はいせつ
 はいせん
 はいそう
 はいち
 ばいばい
-はう
-はえ
+はいれつ
 はえる
 はおる
-はか
-ばか
 はかい
+ばかり
 はかる
-はき
-はく
 はくしゅ
 はけん
-はこ
 はこぶ
 はさみ
 はさん
-はし
 はしご
+ばしょ
 はしる
-ばす
 はせる
 ぱそこん
 はそん
 はたん
-はち
 はちみつ
-はっか
+はつおん
 はっかく
-はっき
+はづき
 はっきり
 はっくつ
 はっけん
 はっこう
 はっさん
-はっしゃ
 はっしん
 はったつ
-はっちゃく
 はっちゅう
 はってん
 はっぴょう
 はっぽう
-はて
-はな
 はなす
 はなび
 はにかむ
-はね
-はは
 はぶらし
-はま
 はみがき
-はむ
 はむかう
 はめつ
 はやい
-はら
+はやし
 はらう
-はり
-はる
-はれ
 はろうぃん
 はわい
 はんい
 はんえい
-はんえん
 はんおん
 はんかく
-はんかち
 はんきょう
+ばんぐみ
 はんこ
-はんこう
 はんしゃ
-はんしん
 はんすう
-はんたい
 はんだん
 ぱんち
 ぱんつ
 はんてい
-はんてん
 はんとし
 はんのう
 はんぱ
@@ -1639,7 +1606,6 @@
 はんぺん
 はんぼうき
 はんめい
-はんめん
 はんらん
 はんろん
 ひいき
@@ -1647,67 +1613,63 @@
 ひえる
 ひかく
 ひかり
+ひかる
 ひかん
-ひく
 ひくい
 ひけつ
 ひこうき
 ひこく
-ひざ
-ぴざ
 ひさい
 ひさしぶり
 ひさん
-ひし
-ひじ
+びじゅつかん
 ひしょ
-ひじょう
 ひそか
 ひそむ
 ひたむき
+ひだり
 ひたる
 ひつぎ
 ひっこし
 ひっし
+ひつじゅひん
 ひっす
 ひつぜん
+ぴったり
+ぴっちり
 ひつよう
 ひてい
-ひと
 ひとごみ
-ひな
+ひなまつり
 ひなん
 ひねる
 ひはん
 ひびく
 ひひょう
-ひふ
 ひほう
-ひま
+ひまわり
 ひまん
 ひみつ
-ひめ
 ひめい
 ひめじし
-ひも
 ひやけ
 ひやす
-ひゆ
 ひよう
 びょうき
+ひらがな
 ひらく
 ひりつ
 ひりょう
-ひる
+ひるま
+ひるやすみ
 ひれい
 ひろい
 ひろう
-ひわ
+ひろき
+ひろゆき
 ひんかく
 ひんけつ
 ひんこん
-ひんし
-ひんしつ
 ひんしゅ
 ひんそう
 ぴんち
@@ -1717,83 +1679,86 @@
 ふいうち
 ふうけい
 ふうせん
+ぷうたろう
 ふうとう
 ふうふ
-ふえ
 ふえる
 ふおん
-ふか
 ふかい
 ふきん
-ふく
 ふくざつ
+ふくぶくろ
 ふこう
 ふさい
-ふざい
 ふしぎ
 ふじみ
 ふすま
 ふせい
 ふせぐ
 ふそく
-ふた
+ぶたにく
 ふたん
-ふち
 ふちょう
 ふつう
+ふつか
 ふっかつ
 ふっき
-ふっきん
 ふっこく
+ぶどう
 ふとる
 ふとん
-ふね
 ふのう
 ふはい
 ふひょう
 ふへん
 ふまん
 ふみん
-ふむ
 ふめつ
 ふめん
-ふゆ
 ふよう
 ふりこ
 ふりる
-ふる
 ふるい
-ふろ
 ふんいき
-ふんか
-ぶんか
+ぶんがく
 ぶんぐ
 ふんしつ
 ぶんせき
 ふんそう
-へい
+ぶんぽう
+へいあん
+へいおん
+へいがい
 へいき
+へいげん
+へいこう
 へいさ
+へいしゃ
+へいせつ
+へいそ
+へいたく
+へいてん
+へいねつ
 へいわ
 へきが
 へこむ
-へそ
-へた
-べつ
-べっど
-ぺっと
-へび
-へや
-へる
-へんか
+べにいろ
+べにしょうが
+へらす
 へんかん
-へんきゃく
-へんきん
+べんきょう
+べんごし
 へんさい
 へんたい
+べんり
 ほあん
 ほいく
+ぼうぎょ
+ほうこく
+ほうそう
 ほうほう
+ほうもん
+ほうりつ
 ほえる
 ほおん
 ほかん
@@ -1804,131 +1769,166 @@
 ほけん
 ほこう
 ほこる
-ほさ
-ほし
+ほしい
 ほしつ
 ほしゅ
 ほしょう
-ほす
 ほせい
-ぼせい
 ほそい
 ほそく
 ほたて
 ほたる
-ぼち
+ぽちぶくろ
 ほっきょく
 ほっさ
 ほったん
 ほとんど
 ほめる
-ほる
 ほんい
 ほんき
 ほんけ
 ほんしつ
+ほんやく
 まいにち
-まう
 まかい
 まかせる
-まく
+まがる
 まける
 まこと
 まさつ
+まじめ
 ますく
 まぜる
-まち
-まつ
 まつり
 まとめ
 まなぶ
 まぬけ
-まね
 まねく
-まひ
 まほう
-まめ
 まもる
 まゆげ
 まよう
-まる
 まろやか
 まわす
 まわり
+まわる
 まんが
-まんかい
 まんきつ
 まんぞく
+まんなか
 みいら
 みうち
+みえる
+みがく
 みかた
 みかん
-みぎ
 みけん
 みこん
+みじかい
 みすい
 みすえる
-みせ
-みそ
-みち
+みせる
+みっか
+みつかる
+みつける
 みてい
 みとめる
+みなと
 みなみかさい
 みねらる
 みのう
+みのがす
 みほん
-みみ
 みもと
 みやげ
 みらい
 みりょく
-みる
 みわく
+みんか
+みんぞく
+むいか
 むえき
 むえん
+むかい
+むかう
+むかえ
 むかし
-むく
-むこ
+むぎちゃ
+むける
+むげん
 むさぼる
-むし
+むしあつい
+むしば
+むじゅん
+むしろ
+むすう
 むすこ
+むすぶ
 むすめ
 むせる
 むせん
-むだ
-むち
+むちゅう
 むなしい
-むね
 むのう
 むやみ
 むよう
-むら
-むり
+むらさき
 むりょう
-むれ
 むろん
+めいあん
+めいうん
+めいえん
+めいかく
+めいきょく
+めいさい
+めいし
+めいそう
+めいぶつ
+めいれい
+めいわく
+めぐまれる
+めざす
+めした
+めずらしい
+めだつ
+めまい
+めやす
+めんきょ
+めんせき
+めんどう
+もうしあげる
 もうどうけん
 もえる
-もぎ
 もくし
 もくてき
-もし
+もくようび
+もちろん
+もどる
+もらう
 もんく
 もんだい
+やおや
+やける
+やさい
+やさしい
 やすい
+やすたろう
 やすみ
+やせる
 やそう
 やたい
 やちん
-やね
+やっと
+やっぱり
 やぶる
-やま
-やみ
 やめる
 ややこしい
 やよい
-やり
 やわらかい
+ゆうき
+ゆうびんきょく
+ゆうべ
+ゆうめい
 ゆけつ
 ゆしゅつ
 ゆせん
@@ -1936,106 +1936,98 @@
 ゆたか
 ゆちゃく
 ゆでる
-ゆび
+ゆにゅう
 ゆびわ
-ゆめ
+ゆらい
 ゆれる
-よう
+ようい
+ようか
+ようきゅう
+ようじ
+ようす
+ようちえん
 よかぜ
 よかん
 よきん
 よくせい
 よくぼう
 よけい
+よごれる
 よさん
+よしゅう
 よそう
 よそく
-よち
+よっか
 よてい
 よどがわく
 よねつ
-よむ
-よめ
 よやく
 よゆう
-よる
 よろこぶ
+よろしい
 らいう
 らくがき
 らくご
 らくさつ
 らくだ
-らくたん
 らしんばん
 らせん
 らぞく
 らたい
-らち
 らっか
-らっかせい
 られつ
 りえき
-りか
 りかい
 りきさく
 りきせつ
-りく
 りくぐん
 りくつ
 りけん
 りこう
-りし
-りす
 りせい
 りそう
 りそく
 りてん
 りねん
-りゅう
 りゆう
 りゅうがく
-りゅうこう
-りゅうし
-りゅうねん
 りよう
-りょうかい
-りょうきん
-りょうしん
-りょうて
-りょうど
-りょうほう
 りょうり
+りょかん
+りょくちゃ
+りょこう
 りりく
 りれき
 りろん
 りんご
+るいけい
+るいさい
 るいじ
-るす
+るいせき
+るすばん
+るりがわら
 れいかん
 れいぎ
 れいせい
 れいぞうこ
 れいとう
+れいぼう
 れきし
 れきだい
 れんあい
 れんけい
-れんけつ
-れんこう
 れんこん
-れんさ
 れんさい
-れんさく
-れんしゃ
 れんしゅう
 れんぞく
+れんらく
 ろうか
 ろうご
 ろうじん
 ろうそく
-ろか
 ろくが
 ろこつ
+ろじうら
 ろしゅつ
 ろせん
 ろてん
@@ -2045,4 +2037,12 @@
 ろんぱ
 ろんぶん
 ろんり
+わかす
+わかめ
+わかやま
+わかれる
+わしつ
 わじまし
+わすれもの
+わらう
+われる

From a1f0af0418a149e932c4f743788ad139d65ca5bb Mon Sep 17 00:00:00 2001
From: Soroush Pour 
Date: Mon, 6 Oct 2014 14:43:11 -0400
Subject: [PATCH 170/181] Updated README statuses with most recent status
 published to respective BIP document

---
 README.mediawiki | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index d5e3fb19..2d2a0c0a 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -53,13 +53,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Aliases
 | Amir Taaki
 | Standard
-| Withdrawn
+| Deferred
 |- style="background-color: #cfffcf"
 | [[bip-0016.mediawiki|16]]
 | Pay To Script Hash
 | Gavin Andresen
 | Standard
-| Accepted
+| Final
 |- style="background-color: #ffcfcf"
 | [[bip-0017.mediawiki|17]]
 | OP_CHECKHASHVERIFY (CHV)
@@ -107,7 +107,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Duplicate transactions
 | Pieter Wuille
 | Standard
-| Accepted
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0031.mediawiki|31]]
 | Pong message
@@ -210,7 +210,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | "reject" P2P message
 | Gavin Andresen
 | Standard
-| Draft
+| Final
 |-
 | [[bip-0062.mediawiki|62]]
 | Dealing with malleability
@@ -234,19 +234,19 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Payment protocol
 | Gavin Andresen
 | Standard
-| Draft
+| Final
 |-
 | [[bip-0071.mediawiki|71]]
 | Payment protocol MIME types
 | Gavin Andresen
 | Standard
-| Draft
+| Final
 |-
 | [[bip-0072.mediawiki|72]]
 | Payment protocol URIs
 | Gavin Andresen
 | Standard
-| Draft
+| Final
 |-
 | [[bip-0073.mediawiki|73]]
 | Use "Accept" header with Payment Request URLs

From 719d56860fe19ad18ffc68c4fdad60902f8fd015 Mon Sep 17 00:00:00 2001
From: Rob Johnson 
Date: Wed, 15 Oct 2014 08:00:20 -0500
Subject: [PATCH 171/181] Compatible wallet

Added mycelium
---
 bip-0044.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index 540c3a48..8f8f48eb 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -264,6 +264,7 @@ is required. This can be done [[https://github.com/satoshilabs/docs/blob/master/
 
 * [[https://mytrezor.com|myTREZOR web wallet]] ([[https://github.com/trezor/webwallet|source]])
 * [[https://play.google.com/store/apps/details?id=com.bonsai.wallet32|Wallet32 @ Android]] ([[https://github.com/ksedgwic/Wallet32|source]])
+* [[https://play.google.com/store/apps/details?id=com.mycelium.wallet|Mycelium Bitcoin Wallet (Android)]] ([[https://github.com/mycelium-com/wallet|source]])
 
 ==Reference==
 

From f081dad3adaa3ea64d3bb6f99c266a376e036073 Mon Sep 17 00:00:00 2001
From: ThomasV 
Date: Wed, 15 Oct 2014 19:07:30 +0200
Subject: [PATCH 172/181] removing myself from bip39 authors

---
 bip-0039.mediawiki | 1 -
 1 file changed, 1 deletion(-)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index 52b4df73..e5c9686b 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -3,7 +3,6 @@
   Title:   Mnemonic code for generating deterministic keys
   Authors: Marek Palatinus 
            Pavol Rusnak 
-           ThomasV 
            Aaron Voisine 
            Sean Bowe 
   Status:  Draft

From 6e848f30dc3c40eeedefaed66725b70f0d36195b Mon Sep 17 00:00:00 2001
From: Y75QMO 
Date: Thu, 16 Oct 2014 09:55:08 +0200
Subject: [PATCH 173/181] Update bip-0039-wordlists.md

Added Spanish wordlist.
---
 bip-0039/bip-0039-wordlists.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md
index 05b3aab9..28cd97ae 100644
--- a/bip-0039/bip-0039-wordlists.md
+++ b/bip-0039/bip-0039-wordlists.md
@@ -2,6 +2,7 @@
 
 * [English](english.txt)
 * [Japanese](japanese.txt)
+* [Spanish](spanish.txt)
 
 ##Wordlists (Special Considerations)
 
@@ -15,3 +16,11 @@ words should use the UTF-8 ideographic space if it looks like the symbols are to
 2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the  
 ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily  
 for two smaller words (This would be a problem with any of the 3 character sets in Japanese)
+
+###Spanish
+
+1. Words can be uniquely determined typing the first 4 characters (sometimes less).
+
+2. Special Spanish characters like 'ñ', 'ü', 'á', etc... are considered equal to 'n', 'u', 'a', etc... in terms of identifying a word. Therefore, there is no need to use a Spanish keyboard to introduce the passphrase, an application with the Spanish wordlist will be able to identify the words after the first 4 chars have been typed even if the chars with accents have been replaced with the equivalent without accents.
+
+3. There are no words in common between the Spanish wordlist and any other language wordlist, therefore it is possible to detect the language with just one word.

From bd0da6f44a9a66ccbd76f709b03b5d9d405dabc3 Mon Sep 17 00:00:00 2001
From: Manuel Araoz 
Date: Mon, 28 Apr 2014 16:04:16 -0300
Subject: [PATCH 174/181] Add BIP 45 for "Structure for Deterministic P2SH
 Multisignature Wallets"

---
 README.mediawiki   |   6 ++
 bip-0045.mediawiki | 256 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 262 insertions(+)
 create mode 100644 bip-0045.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index 2d2a0c0a..ea9783a7 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -193,6 +193,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0045.mediawiki|45]]
+| Structure for Deterministic P2SH Multisignature Wallets
+| Manuel Araoz
+| Standard
+| Draft
+|-
 | [[bip-0050.mediawiki|50]]
 | March 2013 Chain Fork Post-Mortem
 | Gavin Andresen
diff --git a/bip-0045.mediawiki b/bip-0045.mediawiki
new file mode 100644
index 00000000..3710ce85
--- /dev/null
+++ b/bip-0045.mediawiki
@@ -0,0 +1,256 @@
+
+  BIP:     BIP-0045
+  Title:   Structure for Deterministic P2SH Multisignature Wallets
+  Authors: Manuel Araoz 
+           Ryan X. Charles 
+           Matias Alejo Garcia 
+  Status:  Draft
+  Type:    Standards Track
+  Created: 2014-04-25
+

+
+==Abstract==
+
+This BIP defines a structure for hierarchical deterministic P2SH multi-party
+multi-signature wallets (HDPM wallets from now on) based on the algorithm
+described in BIP-0032 (BIP32 from now on) and purpose scheme described in 
+BIP-0043 (BIP43 from now on).
+This BIP is a particular application of BIP43.
+
+==Motivation==
+
+The structure proposed in this document allows for standard ways to create,
+use, import, and store HDPM wallets. It allows to handle multiple parties sharing
+an m-of-n wallet, on the following assumptions:
+* n parties share an m-of-n wallet.
+* Each party generates their master private keys independently.
+* Multisig P2SH is used for all addresses.
+* BIP32 is used to derive public keys, then create a multisig script, and the corresponding P2SH address for that script.
+* Address generation should not require communication between parties. (Thus, all parties must be able to generate all public keys)
+* Transaction creation and signing requires communication between parties.
+
+This BIP will allow interoperability between various HDPM wallet implementations.
+
+==Specification==
+
+We define the following levels in BIP32 path:
+
+
+m / purpose' / cosigner_index / change / address_index
+
+
+Apostrophe in the path indicates that BIP32 hardened derivation is used.
+
+Each level has special meaning described in the chapters below.
+
+===Purpose===
+
+Purpose is a constant set to 45, following the BIP43 recommendation.
+It indicates that the subtree of this node is used according to this specification.
+
+
+m / purpose' / *
+
+
+Hardened derivation is used at this level.
+
+
+===Cosigner Index===
+
+The index of the party creating a P2SH multisig address. The indices can
+be determined independently by lexicographically sorting the purpose public
+keys of each cosigner. Each cosigner creates addresses on it's own branch,
+even though they have independent extended master public key, as explained 
+in the "Address generation" section.
+
+Note that the master public key is not shared amongst the cosigners. Only the
+hardened purpose extended public key is shared, and this is what is used to
+derive child extended public keys.
+
+Software should only use indices corresponding to each of the N cosigners
+sequentially. For example, for a 2-of-3 HDPM wallet, having the following
+purpose public keys:
+
+03a473275a750a20b7b71ebeadfec83130c014da4b53f1c4743fcf342af6589a38
+039863fb5f07b667d9b1ca68773c6e6cdbcac0088ffba9af46f6f6acd153d44463
+03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13
+

+
+it should use `m / purpose ' / 0 / *` for 
+`039863fb5f07b667d9b1ca68773c6e6cdbcac0088ffba9af46f6f6acd153d44463`, 
+`m / purpose ' / 1 / *` for
+`03a473275a750a20b7b71ebeadfec83130c014da4b53f1c4743fcf342af6589a38`,
+and `m / purpose ' / 2 / *` for
+`03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13`,
+as dictated by their lexicographical order.
+
+
+Software needs to discover all used indexes when importing the seed from
+an external source. Such algorithm is described in "Address discovery" chapter.
+
+Non-hardened derivation is used at this level.
+
+===Change===
+
+Constant 0 is used for external chain and constant 1 for internal chain (also
+known as change addresses). External chain is used for addresses that are meant
+to be visible outside of the wallet (e.g. for receiving payments). Internal
+chain is used for addresses which are not meant to be visible outside of the
+wallet and is used for return transaction change.
+
+For example, if cosigner 2 wants to generate a change address, he would use
+`m / purpose ' / 2 / 1 / *`, and `m / purpose ' / 2 / 0 / *` for a receive
+address.
+
+Non-hardened derivation is used at this level.
+
+===Address Index===
+
+Addresses are numbered from index 0 in sequentially increasing manner.
+This number is used as child index in BIP32 derivation.
+
+Non-hardened derivation is used at this level.
+
+===HDPM Wallet High-level Description===
+Each party generates their own extended master keypair and shares the
+extended purpose' public key with the others, which is stored encrypted.
+Each party can generate any of the other's derived public keys, but only
+his own private keys. 
+
+===Address Generation Procedure===
+When generating an address, each party can independently generate the N needed
+public keys. They do this by deriving the public key in each of the different
+trees, but using the same path. They can then generate the multisig script (by
+lexicographically sorting the public keys) and the corresponding p2sh address.
+In this way, each path corresponds to an address, but the public keys for that
+address come from different trees.
+
+====Receive address case====
+Each cosigner generates addresses only on his own branch. One of the n
+cosigners wants to receive a payment, and the others are offline. He
+knows the last used index in his own branch, because only he generates
+addresses there. Thus, he can generate the public keys for all of the
+others using the next index, and calculate the needed script for the address.
+
+Example: Cosigner #2 wants to receive a payment to the shared wallet. His last
+used index on his own branch is 4. Then, the path for the next receive
+address is `m/$purpose/2/1/5`. He uses this same path in all of the cosigners
+trees to generate a public key for each one, and from that he gets the new
+p2sh address.
+====Change address case====
+Again, each cosigner generates addresses only on his own branch. One of the
+n cosigners wants to create an outgoing payment, for which he'll need a change
+address. He generates a new address using the same procedure as above, but
+using a separate index to track the used change addresses. 
+
+Example: Cosigner #5 wants to send a payment from the shared wallet, for which
+he'll need a change address. His last used change index on his own branch is
+11. Then, the path for the next change address is `m/$purpose/5/0/12`. He uses
+this same path in all of the cosigners trees to generate a public key for each
+one, and from that he gets the new p2sh address.
+
+
+===Transaction creation and signing===
+When creating a transaction, first one of the parties creates a Transaction
+Proposal. This is a transaction that spends some output stored in any of the
+p2sh multisig addresses (corresponding to any of the copayers' branches).
+This proposal is sent to the other parties, who decide if they want to sign.
+If they approve the proposal, they can generate their needed private key for
+that specific address (using the same path that generated the public key in
+that address, but deriving the private key instead), and sign it. Once the
+proposal reaches m signatures, any cosigner can broadcast it to the network,
+becoming final. The specifics of how this proposal is structured, and the
+protocol to accept or reject it, belong to another BIP, in my opinion. 
+
+===Address discovery===
+
+When the master seed is imported from an external source the software should
+start to discover the accounts in the following manner:
+
+# derive the first account's node (index = 0)
+# derive the external chain node of this account
+# scan addresses of the external chain; respect the gap limit described below
+# if no transactions are found on the external chain stop discovery
+# if there are some transactions, increase the account index and go to step 1
+
+This algorithm is correct, because software should disallow creation of new
+accounts if previous one has no transaction history as described in chapter
+"Account" above.
+
+Please note that the algorithm works with the transaction history, not account
+balances, so you can have account with total 0 coins and the algorithm will
+still continue with discovery.
+
+===Address gap limit===
+
+Address gap limit is currently set to 20. If the software hits 20 unused
+addresses in a row, it expects there are no used addresses beyond this point
+and stops searching the address chain.
+
+Wallet software should warn when user is trying to exceed the gap limit on
+an external chain by generating a new address.
+
+
+===Rationale===
+
+This stucture provides a general way of doing HDPM wallets between m-of-n
+parties. Here are some explanations about the design decisions made.
+
+The reason for using separate branches for each cosigner is we don't want
+two of them generating the same address and receiving simultaneous payments
+to it. The ideal case is that each address receives at most one payment,
+requested by the corresponding cosigner. 
+
+==Examples==
+
+{|
+!cosigner_index
+!change
+!address_index
+!path
+|-
+|first
+|receive
+|first
+| m / 45' / 0 / 0 / 0
+|-
+|first
+|receive
+|second
+| m / 45' / 0 / 0 / 1
+|-
+|first
+|receive
+|fifth
+| m / 45' / 0 / 0 / 4
+|-
+|first
+|change
+|first
+| m / 45' / 0 / 1 / 0
+|-
+|first
+|change
+|second
+| m / 45' / 0 / 1 / 1
+|-
+|second
+|receive
+|first
+| m / 45' / 1 / 0 / 0
+|-
+|third
+|change
+|tenth
+| m / 45' / 2 / 1 / 9
+|}
+
+==Compatible walets==
+
+* [[https://copay.io|Copay wallet]] ([[https://github.com/bitpay/copay|source]])
+
+==Reference==
+
+* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
+* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
+* [[https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05156.html|Original mailing list discussion]]

From 47b050ac98969054848db7caa4a55a19aaf3a20f Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Fri, 17 Oct 2014 14:00:46 -0700
Subject: [PATCH 175/181] Instead of repeating some problem names, give the
 rules meaningful ones

---
 bip-0062.mediawiki | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki
index 9d5bfe57..5acf5fc8 100644
--- a/bip-0062.mediawiki
+++ b/bip-0062.mediawiki
@@ -38,13 +38,13 @@ The first six and part of the seventh can be fixed by extra consensus rules, but
 ===New rules===
 
 Seven extra rules are introduced, to combat exactly the seven first sources of malleability listed above:
-# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]].
-# '''Non-push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
-# '''Push operations in scriptSig of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
-# '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]].
-# '''Inherent ECDSA signature malleability''' We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). See reference: [[#low-s-values-in-signatures|Low S values in signatures]].
-# '''Superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the script evaluates to false.
-# '''Inputs ignored by scripts''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script evaluate to false.
+# '''Require DER encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]].
+# '''Only push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
+# '''No push operations of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
+# '''No zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]].
+# '''Require low S in ECDSA signatures''' We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). See reference: [[#low-s-values-in-signatures|Low S values in signatures]].
+# '''No superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the script evaluates to false.
+# '''Inputs ignored by scripts are 0''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script evaluate to false.
 
 ===Block validity===
 

From bb863dc6d83db63dc36a8d290bab09d566a75c4c Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Sun, 26 Oct 2014 00:44:23 -0700
Subject: [PATCH 176/181] BIP62 rule 6 and P2SH

Clarify that BIP62 rule 6 (clean stack) only applies after potential P2SH redeemscript evaluation.
Applying it before the redeemscript evaluation means that every P2SH script will fail it,
as P2SH by definition uses an unclean stack (to specify the redeemscript inputs).
---
 bip-0062.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki
index 5acf5fc8..06a328c6 100644
--- a/bip-0062.mediawiki
+++ b/bip-0062.mediawiki
@@ -43,7 +43,7 @@ Seven extra rules are introduced, to combat exactly the seven first sources of m
 # '''No push operations of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
 # '''No zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]].
 # '''Require low S in ECDSA signatures''' We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). See reference: [[#low-s-values-in-signatures|Low S values in signatures]].
-# '''No superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the script evaluates to false.
+# '''No superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the script evaluates to false. For P2SH scripts, this check is only done after the redeemscript evaluation, not after the actual script evaluation.
 # '''Inputs ignored by scripts are 0''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script evaluate to false.
 
 ===Block validity===

From 72475226e76b6de1068bd050bc13685dfcdc855b Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Tue, 4 Nov 2014 23:38:27 -0800
Subject: [PATCH 177/181] Clarify that correct hashtypes are not required.

---
 bip-0062.mediawiki | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki
index 06a328c6..c564ea46 100644
--- a/bip-0062.mediawiki
+++ b/bip-0062.mediawiki
@@ -38,7 +38,7 @@ The first six and part of the seventh can be fixed by extra consensus rules, but
 ===New rules===
 
 Seven extra rules are introduced, to combat exactly the seven first sources of malleability listed above:
-# '''Require DER encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]].
+# '''Require DER encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding, though the hashtype byte that follows it can be anything. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]].
 # '''Only push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
 # '''No push operations of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
 # '''No zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]].
@@ -63,18 +63,20 @@ Below is a summary of the effects on signatures, their encoding and data pushes.
 
 The value S in signatures must be between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive). If S is too high, simply replace it by S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S.
 
-The constraints on the value R is unchanged w.r.t. ECDSA, and can be between 0x1 and 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140 (inclusive). 
+The constraints on the value R is unchanged w.r.t. ECDSA, and can be between 0x1 and 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140 (inclusive).
 
 ====DER encoding====
 For reference, here is how to encode signatures correctly in DER format.
 
-0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash-type]
+0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S]
 * total-length: 1-byte length descriptor of everything that follows, excluding the sighash byte.
 * R-length: 1-byte length descriptor of the R value that follows.
 * R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required.
 * S-length: 1-byte length descriptor of the S value that follows.
 * S: arbitrary-length big-endian encoded S value. The same rules apply as for R.
-* sighash-type: 1-byte hashtype flag (only 0x01, 0x02, 0x03, 0x81, 0x82 and 0x83 are allowed).
+
+The DER signature is followed by a 1-byte hashtype flag, which is Bitcoin-specific and not part of DER.
+
 This is already enforced by the reference client as of version 0.8.0 (only as relay policy, not as a consensus rule).
 
 This rule, combined with the low S requirement above, results in S-length being at most 32 (and R-length at most 33), and the total signature size being at most 72 bytes (and on average 71.494 bytes).

From 3b9d5df9f10a0e31cafe56df51ae461c50f380b5 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Tue, 4 Nov 2014 23:42:21 -0800
Subject: [PATCH 178/181] Use v2 transactions instead of v3, and apply the
 optional rules only to exactly v2.

---
 bip-0062.mediawiki | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki
index c564ea46..a92ae993 100644
--- a/bip-0062.mediawiki
+++ b/bip-0062.mediawiki
@@ -48,12 +48,12 @@ Seven extra rules are introduced, to combat exactly the seven first sources of m
 
 ===Block validity===
 
-To introduce these new rules in the network, we add both v3 blocks and v3 transactions. v2 is skipped for transactions to keep the version numbers between transaction and block rules in sync. v2 transactions are treated identically to v1 transactions.
+To introduce these new rules in the network, we add both v3 blocks and v2 transactions.
 The same mechanism as in BIP 0034 is used to introduce v3 blocks. When 75% of the past 1000 blocks are v3, a new consensus rule is activated:
-* All transactions in v3 blocks are required to follow rules #1-#2.
-* v3 (and higher) transactions in v3 blocks are required to follow rules #3-#7 as well.
+* All transactions in v3 blocks are required to follow rules #1 and #2.
+* v2 transactions in v3 blocks are required to follow rules #3-#7 as well. Transactions with version 1 or a version higher than 2 do not have this requirement, even when in a v3 block.
 
-When 95% of the past 1000 blocks are v3 or higher, v2 blocks become invalid entirely. Note however that v1 (and v2) transactions remain valid forever.
+When 95% of the past 1000 blocks are v3 or higher, v2 blocks become invalid entirely. Note however that v1 transactions remain valid forever.
 
 ===References===
 
@@ -108,6 +108,6 @@ In particular, note that zero could be encoded as (01 80) (negative zero) if usi
 
 ==Compatibility==
 
-'''Relay of transactions''' A new node software version is released which makes v3 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of v1 transactions is unaffected. A v1 transaction spending an output created by a v3 transaction is also unaffected.
+'''Relay of transactions''' A new node software version is released which makes v2 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of v1 transactions is unaffected. A v1 transaction spending an output created by a v2 transaction is also unaffected.
 
-'''Wallet updates''' As v3 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but using v3 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software.
+'''Wallet updates''' As v2 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but using v2 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software.

From 7eaf5714c3a288a015b8dd5d04cde80758751923 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Wed, 5 Nov 2014 00:14:52 -0800
Subject: [PATCH 179/181] typo

---
 bip-0062.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki
index a92ae993..2aee1f96 100644
--- a/bip-0062.mediawiki
+++ b/bip-0062.mediawiki
@@ -110,4 +110,4 @@ In particular, note that zero could be encoded as (01 80) (negative zero) if usi
 
 '''Relay of transactions''' A new node software version is released which makes v2 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of v1 transactions is unaffected. A v1 transaction spending an output created by a v2 transaction is also unaffected.
 
-'''Wallet updates''' As v2 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but using v2 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software.
+'''Wallet updates''' As v2 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to comply to the new rules of course, but using v2 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software.

From 7fb7b7d2117cd4f10c8f8d02b09d20641eca4970 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Sat, 8 Nov 2014 08:46:07 -0800
Subject: [PATCH 180/181] Strict DER is also required for non-evaluated
 CHECKMULTISIG inputs

---
 bip-0062.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki
index 2aee1f96..ac307da5 100644
--- a/bip-0062.mediawiki
+++ b/bip-0062.mediawiki
@@ -38,7 +38,7 @@ The first six and part of the seventh can be fixed by extra consensus rules, but
 ===New rules===
 
 Seven extra rules are introduced, to combat exactly the seven first sources of malleability listed above:
-# '''Require DER encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding, though the hashtype byte that follows it can be anything. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]].
+# '''Require DER encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding, though the hashtype byte that follows it can be anything. Doing a verification with any non-DER signature passed to it makes the entire script evaluate to False, even when an invalid signature is encountered before (which would otherwise make the opcode evaluate to False, but not necessarily the entire script). See reference: [[#der-encoding|DER encoding]].
 # '''Only push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
 # '''No push operations of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
 # '''No zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]].

From 516384603e15926d18692404ca1011c631b424b5 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Sun, 9 Nov 2014 01:18:29 -0500
Subject: [PATCH 181/181] Add signature reordering to list of malleability
 sources

---
 bip-0062.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki
index ac307da5..4cca4cdf 100644
--- a/bip-0062.mediawiki
+++ b/bip-0062.mediawiki
@@ -31,7 +31,8 @@ Several sources of malleability are known:
 # '''Inputs ignored by scripts''' If a scriptPubKey starts with an OP_DROP, for example, the last data push of the corresponding scriptSig will always be ignored.
 # '''Sighash flags based masking''' Sighash flags can be used to ignore certain parts of a script when signing.
 # '''New signatures by the sender''' The sender (or anyone with access to the relevant private keys) is always able to create new signatures that spend the same inputs to the same outputs.
-The first six and part of the seventh can be fixed by extra consensus rules, but the last two can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable. However, when restricted to using a safe set of output scripts, extra consensus rules can make spending transactions optionally non-malleable (if the spender chooses to; as he can always bypass #8 and #9 himself).
+# '''Signature reordering''' If a signature is valid for more than one pubkey, for instance due to a CHECKMULTISIG where two or more of the keys are equivalent, the order of signatures can be changed.
+The first six and part of the seventh can be fixed by extra consensus rules, but the last three can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable. However, when restricted to using a safe set of output scripts, extra consensus rules can make spending transactions optionally non-malleable (if the spender chooses to; as he can always bypass #8 and #9 himself).
 
 ==Specification==