From 9bb5acaec764b41c23d5d4364bc2d5bba87910d4 Mon Sep 17 00:00:00 2001 From: Thomas Kerin Date: Tue, 9 Feb 2016 18:52:38 +0000 Subject: [PATCH 01/27] Typo --- bip-0050.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki index 31070700..dbec7aaf 100644 --- a/bip-0050.mediawiki +++ b/bip-0050.mediawiki @@ -41,7 +41,7 @@ This would be an issue even if the entire network was running version 0.7.2. It ===Immediately=== '''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules: -# Reject blocks that would probably could cause more than 10,000 locks to be taken. +# Reject blocks that would probably cause more than 10,000 locks to be taken. # Limit the maximum block-size created to 500,000 bytes # Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 537,000 # Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 537,000 locks if they absolutely cannot. From 7509fae0be1f0f0effa1d6a1109a4a03afed8850 Mon Sep 17 00:00:00 2001 From: Sandro Machado Date: Tue, 16 Feb 2016 22:18:45 +0000 Subject: [PATCH 02/27] Update bip-0021.mediawiki --- bip-0021.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki index e7094e58..92a05890 100644 --- a/bip-0021.mediawiki +++ b/bip-0021.mediawiki @@ -122,3 +122,5 @@ Characters must be URI encoded properly. === Bitcoin clients === * Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858. +=== Bitcoin libraries === +* [[BitcoinPaymentURI|https://github.com/SandroMachado/BitcoinPaymentURI]] Java library to process and generate Bitcoin payment URI's. From 717228b8fdf4ab0f97d73531603b6c24244bf360 Mon Sep 17 00:00:00 2001 From: Sjors Provoost Date: Mon, 22 Feb 2016 15:10:48 +0800 Subject: [PATCH 03/27] BIP 39: link BitcoinJS & blockchain.info implementation BIP 39 mnemonics are featured quite prominently in the UI as well. --- bip-0039.mediawiki | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index c44ad3e8..a0ec74bb 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -139,4 +139,6 @@ Haskell - https://github.com/haskoin/haskoin .NET C# (PCL) - https://github.com/NicolasDorier/NBitcoin -JavaScript - https://github.com/bitpay/bitcore-mnemonic +JavaScript: +* https://github.com/bitpay/bitcore-mnemonic +* https://github.com/bitcoinjs/bip39 (used by [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/hd-wallet.js#L121-L146|blockchain.info public beta]]) From de90683130e346bd43abf62030f4434179aa91af Mon Sep 17 00:00:00 2001 From: Sjors Provoost Date: Tue, 23 Feb 2016 11:24:29 +0800 Subject: [PATCH 04/27] BIP 39: prettier formatting of implementation list --- bip-0039.mediawiki | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index a0ec74bb..ad78ed62 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -131,13 +131,17 @@ http://github.com/trezor/python-mnemonic ==Other Implementations== -Objective-C - https://github.com/nybex/NYMnemonic +Objective-C: +* https://github.com/nybex/NYMnemonic -Haskell - https://github.com/haskoin/haskoin +Haskell: +* https://github.com/haskoin/haskoin -.NET C# (PCL) - https://github.com/Thashiznets/BIP39.NET +.NET C# (PCL): +* https://github.com/Thashiznets/BIP39.NET -.NET C# (PCL) - https://github.com/NicolasDorier/NBitcoin +.NET C# (PCL): +* https://github.com/NicolasDorier/NBitcoin JavaScript: * https://github.com/bitpay/bitcore-mnemonic From 9ce2c4d3516f9d9989e7536a0bfe2601d566e89e Mon Sep 17 00:00:00 2001 From: Robert Jesionek Date: Thu, 17 Mar 2016 18:12:15 +0100 Subject: [PATCH 05/27] Update bip-0032.mediawiki Added a new Java implementation. --- bip-0032.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 8692c6d5..0c660ad8 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -257,7 +257,7 @@ Two Python implementations exist: PyCoin (https://github.com/richardkiss/pycoin) is a suite of utilities for dealing with Bitcoin that includes BIP0032 wallet features. BIP32Utils (https://github.com/jmcorgan/bip32utils) is a library and command line interface specifically focused on BIP0032 wallets and scripting. -A Java implementation is available at https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java +2 Java implementations exist: https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java and https://github.com/bushidowallet/bushido-java-core/tree/master/src/main/java/com/bushidowallet/core/bitcoin/bip32 A C++ implementation is available at https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinCore/src/hdkeys.h From d34877f48228d6007825ac3dd947b351a6c01fc0 Mon Sep 17 00:00:00 2001 From: Johnson Lau Date: Tue, 7 Jun 2016 01:34:19 +0800 Subject: [PATCH 06/27] BIP141 script failure clarifications Footnotes to clarify some special conditions which witness scripts will fail --- bip-0141.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index ed025ace..6694a68b 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -98,9 +98,9 @@ If the version byte is 0, and the witness program is 32 bytes: * The witnessScript is deserialized, and executed after normal script evaluation with the remaining witness stack (≤ 520 bytes for each stack item). * The script must not fail, and result in exactly a single TRUE on the stack. -If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail. +If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.For example, a scriptPubKey with OP_0 followed by a 40-byte non-zero data push will fail due to incorrect program size. However, a scriptPubKey with OP_0 followed by a 41-byte non-zero data push will pass, since it is not considered to be a witness program -If the version byte is 1 to 16, no further interpretation of the witness program or witness happens, and there is no size restriction for the witness. These versions are reserved for future extensions. +If the version byte is 1 to 16, no further interpretation of the witness program or witness happens, and there is no size restriction for the witness. These versions are reserved for future extensions.For backward compatibility, for any version byte from 0 to 16, the script must fail if the witness program has a CastToBool value of zero. However, having a hash like this is a successful preimage attack against the hash function, and the risk is negligible. === Other consensus critical limits === From 08c068ed0bd2b22da56006cd8483009c4855cc47 Mon Sep 17 00:00:00 2001 From: Matt Bell Date: Wed, 8 Jun 2016 01:41:53 -0700 Subject: [PATCH 07/27] Fixed CSV testnet state in BIP9 assignments list --- bip-0009/assignments.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0009/assignments.mediawiki b/bip-0009/assignments.mediawiki index ee56e17f..4237502c 100644 --- a/bip-0009/assignments.mediawiki +++ b/bip-0009/assignments.mediawiki @@ -18,11 +18,11 @@ State can be defined, active, failed. Dates are in UTC. | csv | 0 | 2016-05-01 00:00:00 -| 2017-05-01 00:00:00 +| 2017-05-01 00:00:00 | defined | 2016-03-01 00:00:00 | 2017-05-01 00:00:00 -| active since #770111 +| active since #770112 | [[/bip-0068.mediawiki|68]], [[/bip-0112.mediawiki|112]], [[/bip-0113.mediawiki|113]] |- | segwit From cb2952c05e6a06bb72642dd803f2ff0f94bbdaf6 Mon Sep 17 00:00:00 2001 From: Matt Bell Date: Wed, 8 Jun 2016 01:42:46 -0700 Subject: [PATCH 08/27] Updated segwit testnet state in BIP9 assignments list --- bip-0009/assignments.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0009/assignments.mediawiki b/bip-0009/assignments.mediawiki index 4237502c..6fcbcf01 100644 --- a/bip-0009/assignments.mediawiki +++ b/bip-0009/assignments.mediawiki @@ -32,6 +32,6 @@ State can be defined, active, failed. Dates are in UTC. | - | 2016-05-01 00:00:00 | 2017-05-01 00:00:00 -| defined +| active since #834624 | [[/bip-0141.mediawiki|141]], [[/bip-0143.mediawiki|143]] |} From 7304edc475a93a4add0320907b2fe61c4f331720 Mon Sep 17 00:00:00 2001 From: Johnson Lau Date: Fri, 10 Jun 2016 13:14:25 +0800 Subject: [PATCH 09/27] BIP141: clarify size restriction for witness stack --- bip-0141.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 6694a68b..f02acf97 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -100,7 +100,7 @@ If the version byte is 0, and the witness program is 32 bytes: If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.For example, a scriptPubKey with OP_0 followed by a 40-byte non-zero data push will fail due to incorrect program size. However, a scriptPubKey with OP_0 followed by a 41-byte non-zero data push will pass, since it is not considered to be a witness program -If the version byte is 1 to 16, no further interpretation of the witness program or witness happens, and there is no size restriction for the witness. These versions are reserved for future extensions.For backward compatibility, for any version byte from 0 to 16, the script must fail if the witness program has a CastToBool value of zero. However, having a hash like this is a successful preimage attack against the hash function, and the risk is negligible. +If the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack. These versions are reserved for future extensions.For backward compatibility, for any version byte from 0 to 16, the script must fail if the witness program has a CastToBool value of zero. However, having a hash like this is a successful preimage attack against the hash function, and the risk is negligible. === Other consensus critical limits === From c65874246a3ac5f55a9b10acc1aa22177c8d2050 Mon Sep 17 00:00:00 2001 From: Daniel Cousens Date: Fri, 29 Jan 2016 11:14:59 +1100 Subject: [PATCH 10/27] Add BIP21 Javascript library --- bip-0021.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki index e7094e58..1e78ebfb 100644 --- a/bip-0021.mediawiki +++ b/bip-0021.mediawiki @@ -122,3 +122,5 @@ Characters must be URI encoded properly. === Bitcoin clients === * Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858. +=== Libraries === +* Javascript - https://github.com/bitcoinjs/bip21 From 9ab38e9c1096e1e94bb28fe57620e56ad4045c96 Mon Sep 17 00:00:00 2001 From: Justus Ranvier Date: Wed, 22 Jun 2016 18:43:56 -0500 Subject: [PATCH 11/27] BIP-126: Best Practices for Heterogeneous Input Script Transactions When a Bitcoin transaction contains inputs that reference previous transaction outputs sent to different Bitcoin addresses, personally identifiable information of the user will leak into the blockchain in an uncontrolled manner. While undesirable, these transactions are frequently unavoidable due the natural fragmentation of wallet balances over time. This standard proposes a set of best practice guidelines which minimize the uncontrolled disclosure of personally identifiable information by defining standard forms for transactions containing heterogenous input scripts. --- bip-0126.mediawiki | 98 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 bip-0126.mediawiki diff --git a/bip-0126.mediawiki b/bip-0126.mediawiki new file mode 100644 index 00000000..dffe247d --- /dev/null +++ b/bip-0126.mediawiki @@ -0,0 +1,98 @@ +
+  BIP: 126
+  Title: Best Practices for Heterogeneous Input Script Transactions
+  Author: Kristov Atlas 
+  Status: Draft
+  Type: Informational
+  Created: 2016-02-10
+
+ +==Abstract== + +When a Bitcoin transaction contains inputs that reference previous transaction outputs sent to different Bitcoin addresses, personally identifiable information of the user will leak into the blockchain in an uncontrolled manner. While undesirable, these transactions are frequently unavoidable due the natural fragmentation of wallet balances over time. + +This document proposes a set of best practice guidelines which minimize the uncontrolled disclosure of personally identifiable information by defining standard forms for transactions containing heterogenous input scripts. + +==Copyright== + +This BIP is in the public domain. + +==Definitions== + +* '''Heterogenous input script transaction (HIT)''': A transaction containing multiple inputs where the scripts of the previous transaction outputs being consumed are not identical (e.g. a transaction spending outputs which were sent to more than one Bitcoin address) +* '''Unavoidable heterogenous input script transaction''': An HIT created as a result of a user’s desire to create a new output with a value larger than the value of his wallet's largest existing unspent output +* '''Intentional heterogenous input script transaction''': An HIT created as part of a user protection protocol for reducing uncontrolled disclosure of personally-identifying information (PII) + +Throughout this procedure, when input scripts are evaluated for uniqueness, "input script" should be interpreted to mean, "the script of the previous output referenced by an input to a transaction". + +==Motivations== + +The recommendations in this document are designed to accomplish three goals: + +# Maximise the effectiveness of user-protecting protocols: Users may find that protection protocols are counterproductive if such transactions have a distinctive fingerprint which renders them ineffective. +# Minimise the adverse consequences of unavoidable heterogenous input transactions: If unavoidable HITs are indistinguishable from intentional HITs, a user creating an unavoidable HIT benefits from ambiguity with respect to graph analysis. +# Limiting the effect on UTXO set growth: To date, non-standardized intentional HITs tend to increase the network's UTXO set with each transaction; this standard attempts to minimize this effect by standardizing unavoidable and intentional HITs to limit UTXO set growth. + +In order to achieve these goals, this specification proposes a set of best practices for heterogenous input script transaction creation. These practices accommodate all applicable requirements of both intentional and unavoidable HITs while maximising the effectiveness of both in terms of preventing uncontrolled disclosure of PII. + +In order to achieve this, two forms of HIT are proposed: Standard form and alternate form. + +==Standard form heterogenous input script transaction== + +===Rules=== + +An HIT is Standard form if it adheres to all of the following rules: + +# The number of unique output scripts must be equal to the number of unique inputs scripts (irrespective of the number of inputs and outputs). +# All output scripts must be unique. +# At least one pair of outputs must be of equal value. +# The largest output in the transaction is a member of a set containing at least two identically-sized outputs. + +===Rationale=== + +The requirement for equal numbers of unique input/output scripts instead of equal number of inputs/outputs accommodates user-protecting UTXO selection behavior. Wallets may contain spendable outputs with identical scripts due to intentional or accidental address reuse, or due to dusting attacks. In order to minimise the adverse consequences of address reuse, any time a UTXO is included in a transaction as an input, all UTXOs with the same spending script should also be included in the transaction. + +The requirement that all output scripts are unique prevents address reuse. Restricting the number of outputs to the number of unique input scripts prevents this policy from growing the network’s UTXO set. A standard form HIT transaction will always have a number of inputs greater than or equal to the number of outputs. + +The requirement for at least one pair of outputs in an intentional HIT to be of equal value results in optimal behavior, and causes intentional HITs to resemble unavoidable HITs. + +==Alternate form heterogenous input script transactions== + +The formation of a standard form HIT is not possible in the following cases: + +# The HIT is unavoidable, and the user’s wallet contains an insufficient number or size of UTXOs to create a standard form HIT. +# The user wishes to reduce the number of utxos in their wallet, and does not have any sets of utxos with identical scripts. + +When one of the following cases exist, a compliant implementation may create an alternate form HIT by constructing a transaction as follows: + +===Procedure=== + +# Find the smallest combination of inputs whose value is at least the value of the desired spend. +## Add these inputs to the transaction. +## Add a spend output to the transaction. +## Add a change output to the transaction containing the difference between the current set of inputs and the desired spend. +# Repeat step 1 to create a second spend output and change output. +# (optional) Repeat step 2 until the desired number of inputs have been consumed and/or the desired number outputs have been created. +# Adjust the change outputs as necessary to pay the desired transaction fee. + +Clients which create intentional HITs must have the capability to form alternate form HITs, and must do so for a non-zero fraction of the transactions they create. + +===Rules=== + +An HIT formed via the preceding procedure will adhere to the following conditions: + +# The number of unique inputs scripts must exceed the number of output scripts. +# All output scripts must be unique. +# At least one pair of outputs must be of equal value. +## "Standard outputs" refers to the set of outputs with equal value +## "Standard value" refers to the value of the standard outputs +## "Change outputs" refers to all outputs which are not standard outputs +# For a HIT containing n standard outputs, there must exist at least one possible way to organize the inputs and outputs into n sets, where all sets satisfy the following: +## The set contains one or more inputs, exactly one standard output, and exactly one change output +## An input or output that appears in one set must not appear in any other set +## The sum of the inputs in the set minus the value of the change output is equal to the standard value with a tolerance equal to the transaction fee. +## Change outputs with a value of zero (virtual change outputs) are permitted. The are defined for the purpose of testing whether or not a HIT adheres to this specification but are not present in the version of the transaction which is broadcast to the network. + +==Non-compliant heterogenous input script transactions== + +If a user wishes to create an output that is larger than half the total size of their spendable outputs, or if their inputs are not distributed in a manner in which the alternate form procedure can be completed, then the user can not create a transaction which is compliant with this procedure. From 05e96d2500258724f4d2cb04b1d803aea045c6bf Mon Sep 17 00:00:00 2001 From: Daniel Cousens Date: Thu, 23 Jun 2016 13:30:24 +1000 Subject: [PATCH 12/27] grammar fix --- bip-0126.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0126.mediawiki b/bip-0126.mediawiki index dffe247d..295b582b 100644 --- a/bip-0126.mediawiki +++ b/bip-0126.mediawiki @@ -9,7 +9,7 @@ ==Abstract== -When a Bitcoin transaction contains inputs that reference previous transaction outputs sent to different Bitcoin addresses, personally identifiable information of the user will leak into the blockchain in an uncontrolled manner. While undesirable, these transactions are frequently unavoidable due the natural fragmentation of wallet balances over time. +When a Bitcoin transaction contains inputs that reference previous transaction outputs sent to different Bitcoin addresses, personally identifiable information of the user will leak into the blockchain in an uncontrolled manner. While undesirable, these transactions are frequently unavoidable due to the natural fragmentation of wallet balances over time. This document proposes a set of best practice guidelines which minimize the uncontrolled disclosure of personally identifiable information by defining standard forms for transactions containing heterogenous input scripts. From f51a8e1d0eb4870069cccde1f739964aeca93515 Mon Sep 17 00:00:00 2001 From: Daniel Cousens Date: Thu, 23 Jun 2016 13:42:03 +1000 Subject: [PATCH 13/27] further grammar, not An Hit --- bip-0126.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0126.mediawiki b/bip-0126.mediawiki index 295b582b..42881e5e 100644 --- a/bip-0126.mediawiki +++ b/bip-0126.mediawiki @@ -20,8 +20,8 @@ This BIP is in the public domain. ==Definitions== * '''Heterogenous input script transaction (HIT)''': A transaction containing multiple inputs where the scripts of the previous transaction outputs being consumed are not identical (e.g. a transaction spending outputs which were sent to more than one Bitcoin address) -* '''Unavoidable heterogenous input script transaction''': An HIT created as a result of a user’s desire to create a new output with a value larger than the value of his wallet's largest existing unspent output -* '''Intentional heterogenous input script transaction''': An HIT created as part of a user protection protocol for reducing uncontrolled disclosure of personally-identifying information (PII) +* '''Unavoidable heterogenous input script transaction''': A HIT created as a result of a user’s desire to create a new output with a value larger than the value of his wallet's largest existing unspent output +* '''Intentional heterogenous input script transaction''': A HIT created as part of a user protection protocol for reducing uncontrolled disclosure of personally-identifying information (PII) Throughout this procedure, when input scripts are evaluated for uniqueness, "input script" should be interpreted to mean, "the script of the previous output referenced by an input to a transaction". @@ -41,7 +41,7 @@ In order to achieve this, two forms of HIT are proposed: Standard form and alter ===Rules=== -An HIT is Standard form if it adheres to all of the following rules: +A HIT is Standard form if it adheres to all of the following rules: # The number of unique output scripts must be equal to the number of unique inputs scripts (irrespective of the number of inputs and outputs). # All output scripts must be unique. From b33ca0c97b6aa78cc938b74400956ad05a11b7ee Mon Sep 17 00:00:00 2001 From: Justus Ranvier Date: Thu, 23 Jun 2016 09:52:16 -0500 Subject: [PATCH 14/27] revise wording of alternate HIT procedure --- bip-0126.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0126.mediawiki b/bip-0126.mediawiki index dffe247d..31008371 100644 --- a/bip-0126.mediawiki +++ b/bip-0126.mediawiki @@ -71,7 +71,7 @@ When one of the following cases exist, a compliant implementation may create an ## Add these inputs to the transaction. ## Add a spend output to the transaction. ## Add a change output to the transaction containing the difference between the current set of inputs and the desired spend. -# Repeat step 1 to create a second spend output and change output. +# Repeat step 1 to create a second pair of outputs, where one output has the same value as the spend output of the previous step. # (optional) Repeat step 2 until the desired number of inputs have been consumed and/or the desired number outputs have been created. # Adjust the change outputs as necessary to pay the desired transaction fee. From 95947c5d771007d5b638a08d06381edb933e2975 Mon Sep 17 00:00:00 2001 From: Matt Bell Date: Tue, 5 Jul 2016 09:43:34 -0700 Subject: [PATCH 15/27] Added CSV mainnet activation to BIP9 assignments list --- bip-0009/assignments.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0009/assignments.mediawiki b/bip-0009/assignments.mediawiki index 6fcbcf01..e145ceb0 100644 --- a/bip-0009/assignments.mediawiki +++ b/bip-0009/assignments.mediawiki @@ -19,7 +19,7 @@ State can be defined, active, failed. Dates are in UTC. | 0 | 2016-05-01 00:00:00 | 2017-05-01 00:00:00 -| defined +| active since #419328 | 2016-03-01 00:00:00 | 2017-05-01 00:00:00 | active since #770112 From 9c7fde09aac630aee8abaa1fe1c1e6c244ae6b1a Mon Sep 17 00:00:00 2001 From: Daniel Cousens Date: Tue, 12 Jul 2016 12:15:35 +1000 Subject: [PATCH 16/27] bip141: clarify that marker is 1 byte --- bip-0141.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index ed025ace..27a59f9a 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -48,7 +48,7 @@ A new wtxid is defined: the double SHA256 of the new serialization Format of nVersion, txins, txouts, and nLockTime are same as traditional serialization. -The marker MUST be 0x00. +The marker MUST be a 1-byte zero value: 0x00. The flag MUST be a 1-byte non-zero value. Currently, 0x01 MUST be used. From 529c7cddb7f313c4c4043d6b918fa69eb73761cf Mon Sep 17 00:00:00 2001 From: Jonas Schnelli Date: Wed, 13 Jul 2016 13:09:24 +0200 Subject: [PATCH 17/27] [BIP151] Switch from plain HMAC_SHA512 KDF to HKDF --- bip-0151.mediawiki | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index 18d39017..cc797121 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -36,17 +36,22 @@ Encryption initialization must happen before sending any other messages to the r === Symmetric Encryption Cipher Keys === -The symmetric encryption cipher keys will be calculated with ECDH by sharing the pubkeys of a ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be calculated with HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key"). +The symmetric encryption cipher keys will be calculated with ECDH/HKDF by sharing the pubkeys of a ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be derived with HKDF [2] after the following specification: -K_1 must be the left 32bytes of the HMAC_SHA512 hash. +1. HKDF extraction +PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinechd", ikm=ecdh_secret|cipher-type). -K_2 must be the right 32bytes of the HMAC_SHA512 hash. +2. Derive Key1 +K_1 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK1", L=32) -It is important to include the cipher-type into the symmetric cipher key to avoid weak-cipher-attacks. +3. Derive Key2 +K_2 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK2", L=32) + +It is important to include the cipher-type into the symmetric cipher key derivation to avoid weak-cipher-attacks. === Session ID === -Both sides must also calculate the 256bit session-id using HMAC_SHA256(key=ecdh_secret,msg="session id"). The session-id can be used for linking the encryption-session to an identity check. +Both sides must also calculate the 256bit session-id using SID = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinSessionID", L=32). The session-id can be used for linking the encryption-session to an identity check. === The encinit message type === @@ -69,19 +74,19 @@ Possible symmetric key ciphers types === ChaCha20-Poly1305 Cipher Suite === -ChaCha20 is a stream cipher designed by Daniel Bernstein [2]. It operates by permuting 128 fixed bits, 128 or 256 bits of key, +ChaCha20 is a stream cipher designed by Daniel Bernstein [3]. It operates by permuting 128 fixed bits, 128 or 256 bits of key, a 64 bit nonce and a 64 bit counter into 64 bytes of output. This output is used as a keystream, with any unused bytes simply discarded. -Poly1305, also by Daniel Bernstein [3], is a one-time Carter-Wegman MAC that computes a 128 bit integrity tag given a message and a single-use +Poly1305, also by Daniel Bernstein [4], is a one-time Carter-Wegman MAC that computes a 128 bit integrity tag given a message and a single-use 256 bit secret key. -The chacha20-poly1305@openssh.com specified and defined by openssh [4] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [5], but differs in the layout of data passed to the MAC and in the addition of encyption of the packet lengths. +The chacha20-poly1305@openssh.com specified and defined by openssh [5] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [6], but differs in the layout of data passed to the MAC and in the addition of encyption of the packet lengths. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. K_2 must be used in conjunction with poly1305 to build an AEAD. -Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per bytes then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304 [5]. +Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per bytes then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304. === The encack message type === @@ -164,10 +169,11 @@ This proposal is backward compatible. Non-supporting peers will ignore the Date: Fri, 15 Jul 2016 14:53:44 +0000 Subject: [PATCH 18/27] Update README for BIP 126 --- README.mediawiki | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/README.mediawiki b/README.mediawiki index ee7b0d8b..b745f51d 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -446,6 +446,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0126.mediawiki|126]] +| Best Practices for Heterogeneous Input Script Transactions +| Kristov Atlas +| Informational +| Draft +|- | [[bip-0130.mediawiki|130]] | sendheaders message | Suhas Daftuar From 83596de8ca76a3873ea993fc806ede761b07d874 Mon Sep 17 00:00:00 2001 From: "Wladimir J. van der Laan" Date: Mon, 18 Jul 2016 08:13:15 +0200 Subject: [PATCH 19/27] bip141: Change 'block cost' to 'block weight' The term 'block cost' led to confusion about the unit that it is expressed in, in that it expressed monetary cost. Change it to a more general term 'block weight'. This was discussed in the [2016-07-14 Bitcoin Core developer meeting](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-14-19.00.html). --- bip-0141.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 8fdc795f..497cf7e1 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -108,13 +108,13 @@ If the version byte is 1 to 16, no further interpretation of the witness program Blocks are currently limited to 1,000,000 bytes (1MB) total size. We change this restriction as follows: -''Block cost'' is defined as ''Base size'' * 3 + ''Total size''. (rationaleRationale of using a single composite constraint, instead of two separate limits such as 1MB base data and 3MB witness data: Using two separate limits would make mining and fee estimation nearly impossible. Miners would need to solve a complex non-linear optimization problem to find the set of transactions that maximize fees given both constraints, and wallets would not be able to know what to pay as it depends on which of the two conditions is most constrained by the time miners try to produce blocks with their transactions in. Another problem with such an approach is freeloading. Once a set of transactions hit the base data 1MB constraint, up to 3MB extra data could be added to the witness by just minimally increasing the fee. The marginal cost for extra witness space effectively becomes zero in that case.) +''Block weight'' is defined as ''Base size'' * 3 + ''Total size''. (rationaleRationale of using a single composite constraint, instead of two separate limits such as 1MB base data and 3MB witness data: Using two separate limits would make mining and fee estimation nearly impossible. Miners would need to solve a complex non-linear optimization problem to find the set of transactions that maximize fees given both constraints, and wallets would not be able to know what to pay as it depends on which of the two conditions is most constrained by the time miners try to produce blocks with their transactions in. Another problem with such an approach is freeloading. Once a set of transactions hit the base data 1MB constraint, up to 3MB extra data could be added to the witness by just minimally increasing the fee. The marginal cost for extra witness space effectively becomes zero in that case.) ''Base size'' is the block size in bytes with the original transaction serialization without any witness-related data, as seen by a non-upgraded node. ''Total size'' is the block size in bytes with transactions serialized as described in [[bip-0144.mediawiki|BIP144]], including base data and witness data. -The new rule is ''block cost'' ≤ 4,000,000. +The new rule is ''block weight'' ≤ 4,000,000. ==== Sigops ==== From 55c3d8068adbddd1cb9f97e4bc5e78500ce363bd Mon Sep 17 00:00:00 2001 From: jl2012 Date: Tue, 19 Jul 2016 00:11:30 +0800 Subject: [PATCH 20/27] BIP141 terms fix --- bip-0141.mediawiki | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 8fdc795f..1934e594 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -123,14 +123,13 @@ Sigops per block is currently limited to 20,000. We change this restriction as f Sigops in the current pubkey script, signature script, and P2SH check script are counted at 4 times their previous value. The sigop limit is likewise quadrupled to ≤ 80,000. -In addition, opcodes within the witness program are counted identical to as previously within the P2SH check script. -That is, CHECKSIG in a witness program is counted as only 1 sigop, and CHECKMULTISIG in a witness program is counted as 1 to 20 sigops according to the arguments. This rule applies to both native witness program and P2SH witness program. +Each P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH witnessScript are counted identically as previously within the P2SH redeemScript. That is, CHECKSIG is counted as only 1 sigop, and CHECKMULTISIG is counted as 1 to 20 sigops according to the arguments. This rule applies to both native witness program and P2SH witness program. == Examples == -=== P2WPKH witness program === +=== P2WPKH === -The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH) witness program: +The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH): witness: scriptSig: (empty) @@ -147,7 +146,7 @@ Comparing with a traditional P2PKH output, the P2WPKH equivalent occupies 3 less === P2WPKH nested in BIP16 P2SH === -The following example is the same P2WPKH witness program, but nested in a BIP16 P2SH output. +The following example is the same P2WPKH, but nested in a BIP16 P2SH output. witness: scriptSig: <0 <20-byte-key-hash>> @@ -159,13 +158,13 @@ The only item in scriptSig is hashed with HASH160, compared against the 20-byte- 0 <20-byte-key-hash> -The P2WPKH witness program is then executed as described in the previous example. +The public key and signature are then verified as described in the previous example. Comparing with the previous example, the scriptPubKey is 1 byte bigger and the scriptSig is 23 bytes bigger. Although a nested witness program is less efficient, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0. -=== P2WSH witness program === +=== P2WSH === -The following example is an 1-of-2 multi-signature version 0 pay-to-witness-script-hash (P2WSH) witness program. +The following example is an 1-of-2 multi-signature version 0 pay-to-witness-script-hash (P2WSH). witness: 0 <1 2 CHECKMULTISIG> scriptSig: (empty) @@ -180,13 +179,13 @@ The script is executed with the remaining data from witness: 0 1 2 CHECKMULTISIG -A P2WSH witness program allows arbitrarily large script as the 520-byte push limit is bypassed. +P2WSH allows maximum script size of 10,000 bytes, as the 520-byte push limit is bypassed. The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of BIP16 P2SH. The increased size improves security against possible collision attacks, as 280 work is not infeasible anymore (By the end of 2015, 284 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent BIP16 P2SH output but is moved to witness. === P2WSH nested in BIP16 P2SH === -The following example is the same 1-of-2 multi-signature P2WSH witness program, but nested in a BIP16 P2SH output. +The following example is the same 1-of-2 multi-signature P2WSH script, but nested in a BIP16 P2SH output. witness: 0 <1 2 CHECKMULTISIG> scriptSig: <0 <32-byte-hash>> @@ -198,7 +197,7 @@ The only item in scriptSig is hashed with HASH160, compared against the 20-byte- 0 <32-byte-hash> -The P2WSH witness program is then executed as described in the previous example. +The P2WSH witnessScript is then executed as described in the previous example. Comparing with the previous example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig. @@ -249,8 +248,6 @@ Since a version byte is pushed before a witness program, and programs with unkno Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity. -The 32-byte limitation for witness program could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable through a softfork. - === Per-input lock-time and relative-lock-time === Currently there is only one nLockTime field in a transaction and all inputs must share the same value. [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68] enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution. From 34be169fe360c1f6109022bbf350440dc0fc1612 Mon Sep 17 00:00:00 2001 From: Sjors Provoost Date: Mon, 18 Jul 2016 20:43:23 +0200 Subject: [PATCH 21/27] BIP 39: remove "public beta" from blockchain.info link This is now in the default wallet. --- bip-0039.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index ad78ed62..0d05d819 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -145,4 +145,4 @@ Haskell: JavaScript: * https://github.com/bitpay/bitcore-mnemonic -* https://github.com/bitcoinjs/bip39 (used by [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/hd-wallet.js#L121-L146|blockchain.info public beta]]) +* https://github.com/bitcoinjs/bip39 (used by [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/hd-wallet.js#L121-L146|blockchain.info]]) From c98859fe20617df141da0dd08d399921c7097be9 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Mon, 18 Jul 2016 23:37:42 +0000 Subject: [PATCH 22/27] Promote Draft->Final BIPs: 68, 112, and 113 Softforks are deployed by miners and enforced on the network --- README.mediawiki | 12 ++++++------ bip-0068.mediawiki | 2 +- bip-0112.mediawiki | 2 +- bip-0113.mediawiki | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/README.mediawiki b/README.mediawiki index b745f51d..239294f0 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -271,12 +271,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0068.mediawiki|68]] | Relative lock-time using consensus-enforced sequence numbers | Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona | Standard -| Draft +| Final |- | [[bip-0069.mediawiki|69]] | Lexicographical Indexing of Transaction Inputs and Outputs @@ -391,18 +391,18 @@ Those proposing changes should consider that ultimately consent may rest with th | Matt Corallo, Peter Todd | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0112.mediawiki|112]] | CHECKSEQUENCEVERIFY | BtcDrak, Mark Friedenbach, Eric Lombrozo | Standard -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0113.mediawiki|113]] | Median time-past as endpoint for lock-time calculations | Thomas Kerin, Mark Friedenbach | Standard -| Draft +| Final |- | [[bip-0114.mediawiki|114]] | Merkelized Abstract Syntax Tree diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki index 03039242..923441ec 100644 --- a/bip-0068.mediawiki +++ b/bip-0068.mediawiki @@ -5,7 +5,7 @@ BtcDrak Nicolas Dorier kinoshitajona - Status: Draft + Status: Final Type: Standards Track Created: 2015-05-28 diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index e19e0e92..0397332a 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -4,7 +4,7 @@ Author: BtcDrak Mark Friedenbach Eric Lombrozo - Status: Draft + Status: Final Type: Standards Track Created: 2015-08-10 diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki index 8290c137..1c402aa0 100644 --- a/bip-0113.mediawiki +++ b/bip-0113.mediawiki @@ -3,7 +3,7 @@ Title: Median time-past as endpoint for lock-time calculations Author: Thomas Kerin Mark Friedenbach - Status: Draft + Status: Final Type: Standards Track Created: 2015-08-10 From 6fb5aaf1366099c7107de58b55159986cdc2549e Mon Sep 17 00:00:00 2001 From: Elias Rodrigues Date: Fri, 22 Jul 2016 14:52:15 -0300 Subject: [PATCH 23/27] Minor link fix --- bip-0021.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki index a3c2d4ef..daf4cf81 100644 --- a/bip-0021.mediawiki +++ b/bip-0021.mediawiki @@ -124,4 +124,4 @@ Characters must be URI encoded properly. === Libraries === * Javascript - https://github.com/bitcoinjs/bip21 -* [[BitcoinPaymentURI|https://github.com/SandroMachado/BitcoinPaymentURI]] Java library to process and generate Bitcoin payment URI's. +* https://github.com/SandroMachado/BitcoinPaymentURI Java library to process and generate Bitcoin payment URI's. From d8928eb85a641b3ad5efa956a512adb88a02d10b Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Sat, 23 Jul 2016 20:35:56 +0000 Subject: [PATCH 24/27] BIP 145: Update s/cost/weight/ --- bip-0145.mediawiki | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki index b04c9e6e..cac838df 100644 --- a/bip-0145.mediawiki +++ b/bip-0145.mediawiki @@ -22,7 +22,7 @@ The template Object is revised to include a new key: |- ! Key !! Required !! Type !! Description |- -| costlimit || No || Number || total cost allowed in blocks +| weightlimit || No || Number || total weight allowed in blocks |} The '!' rule prefix MUST be enabled on the "segwit" rule for templates including transactions with witness data. @@ -40,7 +40,7 @@ The Objects listed in the response's "transactions" key is revised to include th |- | txid || String || transaction id encoded in hexadecimal; required for transactions with witness data |- -| cost || Number || numeric cost of the transaction, as counted for purposes of the block's costlimit; if key is not present, cost is unknown and clients MUST NOT assume it is zero, although they MAY choose to calculate it themselves +| weight || Number || numeric weight of the transaction, as counted for purposes of the block's weightlimit; if key is not present, weight is unknown and clients MUST NOT assume it is zero, although they MAY choose to calculate it themselves |- | hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal |} @@ -66,12 +66,12 @@ It additionally also adds a new way of counting resource limits, and so GBT must ==Rationale== -Why doesn't "costlimit" simply redefine the existing "sizelimit"? +Why doesn't "weightlimit" simply redefine the existing "sizelimit"? * "sizelimit" is already enforced by clients by counting the sum of bytes in transactions' "data" keys. -* Servers may wish to limit the overall size of a block, independently from the "cost" of the block. +* Servers may wish to limit the overall size of a block, independently from the "weight" of the block. -Why is "sigoplimit" redefined instead of a new "sigopcostlimit" being added? -* The old limit was already arbitrarily defined, and could not be counted by clients on their own anyway. The concept of "sigop cost" is merely a change in the arbitrary formula used. +Why is "sigoplimit" redefined instead of a new "sigopweightlimit" being added? +* The old limit was already arbitrarily defined, and could not be counted by clients on their own anyway. The concept of "sigop weight" is merely a change in the arbitrary formula used. Why is "sigoplimit" divided by 4? * To resemble the previous values. (FIXME: is this a good reason? maybe we shouldn't divide it?) From d49512e612039193b2085353133073992e47d2a0 Mon Sep 17 00:00:00 2001 From: Janus Troelsen Date: Mon, 25 Jul 2016 10:05:55 +0200 Subject: [PATCH 25/27] Link to permanent PR of reference implementation analogue to https://github.com/bitcoin/bips/commit/ecfb7ebbca3488cd4c1e11210cbc5914a9228c67 --- bip-0141.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 4b4a0aa5..ccf18b62 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -287,7 +287,7 @@ Special thanks to Gregory Maxwell for originating many of the ideas in this BIP == Reference Implementation == -https://github.com/bitcoin/bitcoin/pull/7910 +https://github.com/bitcoin/bitcoin/pull/8149 == References == From f388fef2f621c648f0e06aa5bdf06db3efd27b04 Mon Sep 17 00:00:00 2001 From: Christopher Jeffrey Date: Tue, 26 Jul 2016 23:26:46 -0700 Subject: [PATCH 26/27] BIP151: Clarifications on AAD and sequence numbers. --- bip-0151.mediawiki | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index cc797121..f565a4e2 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -123,12 +123,14 @@ After a successful encinit/encack interaction from bot Encrypted messages do not have the 4byte network magic. +The ciphertext payload length must be included in the AEAD MAC as AAD. + The maximum message length needs to be chosen carefully. The 4 byte length field can lead to a required message buffer of 4 GiB. Processing the message before the authentication succeeds must not be done. The 4byte sha256 checksum is no longer required because the AEAD. -Both peers need to track the message number (int64) of sent messages to the remote peer for building a symmetric cipher IV. Padding might be required (96bit IVs). +Both peers need to track the message sequence number (uint32) of sent messages to the remote peer for building a 64 bit symmetric cipher IV. Sequence numbers are allowed to overflow to zero after 4294967295 (2^32-1). The encrypted payload will result decrypted in one or many unencrypted messages: @@ -156,7 +158,7 @@ The Re-Keying must be done after every 1GB of data sent or received (recommended === Risks === -The encryption does not include an identity authentication scheme. This BIP does not cover a proposal to avoid MITM attacks during the encryption initialization. +The encryption does not include an identity authentication scheme. This BIP does not cover a proposal to avoid MITM attacks during the encryption initialization. Identity authentication will be covered in another BIP and will presume communication encryption after this BIP. From 0607a34fcfd139f02a9232449f88cdd3501d9a18 Mon Sep 17 00:00:00 2001 From: Christopher Jeffrey Date: Wed, 27 Jul 2016 00:26:34 -0700 Subject: [PATCH 27/27] bip151: remove aad change. --- bip-0151.mediawiki | 2 -- 1 file changed, 2 deletions(-) diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index f565a4e2..a4c8b8ec 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -123,8 +123,6 @@ After a successful encinit/encack interaction from bot Encrypted messages do not have the 4byte network magic. -The ciphertext payload length must be included in the AEAD MAC as AAD. - The maximum message length needs to be chosen carefully. The 4 byte length field can lead to a required message buffer of 4 GiB. Processing the message before the authentication succeeds must not be done.