summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--README.mediawiki4
-rw-r--r--bip-0002.mediawiki8
-rw-r--r--bip-0017.mediawiki4
-rw-r--r--bip-0018.mediawiki4
-rw-r--r--bip-0019.mediawiki4
-rw-r--r--bip-0020.mediawiki3
-rw-r--r--bip-0022.mediawiki4
-rw-r--r--bip-0023.mediawiki4
-rw-r--r--bip-0067.mediawiki5
-rw-r--r--bip-0075.mediawiki19
-rw-r--r--bip-0075/paymentrequest.proto4
-rw-r--r--bip-0109.mediawiki2
-rw-r--r--bip-0123.mediawiki332
-rw-r--r--bip-0134.mediawiki184
-rw-r--r--bip-0152.mediawiki2
-rwxr-xr-xscripts/buildtable.pl5
16 files changed, 368 insertions, 220 deletions
diff --git a/README.mediawiki b/README.mediawiki
index 3ac1078..ed46917 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -391,12 +391,12 @@ Those proposing changes should consider that ultimately consent may rest with th
| Washington Y. Sanchez
| Standard
| Draft
-|-
+|- style="background-color: #ffcfcf"
| [[bip-0109.mediawiki|109]]
| Two million byte size limit with sigop and sighash limits
| Gavin Andresen
| Standard
-| Draft
+| Rejected
|- style="background-color: #ffffcf"
| [[bip-0111.mediawiki|111]]
| NODE_BLOOM service bit
diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 43a5ce6..4796771 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -74,6 +74,7 @@ For each new BIP that comes in an editor does the following:
* The title should accurately describe the content.
* The BIP draft must have been sent to the Bitcoin development mailing list for discussion.
* Motivation and backward compatibility (when applicable) must be addressed.
+* The defined Layer header must be correctly assigned for the given specification.
* Licensing terms must be acceptable for BIPs.
If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
@@ -120,6 +121,7 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
<pre>
BIP: <BIP number, or "?" before being assigned>
+* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>
Title: <BIP title; maximum 44 characters>
Author: <list of authors' real names and email addrs>
* Discussions-To: <email address>
@@ -137,6 +139,9 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
* Superseded-By: <BIP number>
</pre>
+The Layer header (only for Standards Track BIPs) documents which layer of Bitcoin the BIP applies to.
+See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
+
The Author header lists the names and email addresses of all the authors/owners of the BIP.
The format of the Author header value must be
@@ -191,8 +196,6 @@ A process BIP may change status from Draft to Active when it achieves rough cons
====Progression to Final status====
-See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
-
A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork might have majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption. Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
@@ -395,6 +398,7 @@ Why is Public Domain no longer acceptable for new BIPs?
* An implementation is now required (when applicable) before BIPs can proceed to Proposed Status.
* BIP Comments are newly introduced.
* The License preamble headers have been added.
+* The Layer header is included from BIP 123.
* Non-image auxiliary files are permitted in the bip-XXXX subdirectory.
* Email addresses are now required for authors.
* The Post-History header may be provided as a link instead of a simple date.
diff --git a/bip-0017.mediawiki b/bip-0017.mediawiki
index 44011d5..3863487 100644
--- a/bip-0017.mediawiki
+++ b/bip-0017.mediawiki
@@ -11,6 +11,10 @@
This BIP describes a new opcode (OP_CHECKHASHVERIFY) for the Bitcoin scripting system, and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them.
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
==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.
diff --git a/bip-0018.mediawiki b/bip-0018.mediawiki
index fce4200..15e4418 100644
--- a/bip-0018.mediawiki
+++ b/bip-0018.mediawiki
@@ -11,6 +11,10 @@
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.
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
==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.
diff --git a/bip-0019.mediawiki b/bip-0019.mediawiki
index 7784e08..228fdc8 100644
--- a/bip-0019.mediawiki
+++ b/bip-0019.mediawiki
@@ -11,6 +11,10 @@
This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type using the existing scripting system without significant modifications.
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
==Motivation==
Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature.
diff --git a/bip-0020.mediawiki b/bip-0020.mediawiki
index fad634b..ff7fded 100644
--- a/bip-0020.mediawiki
+++ b/bip-0020.mediawiki
@@ -12,6 +12,9 @@ BIP 0020 is based off an earlier document by Nils Schneider. '''And has been rep
==Abstract==
This BIP proposes a URI scheme for making Bitcoin payments.
+==Copyright==
+This BIP is licensed under the BSD 2-clause license.
+
==Motivation==
The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.
diff --git a/bip-0022.mediawiki b/bip-0022.mediawiki
index 4b33e59..82a13bf 100644
--- a/bip-0022.mediawiki
+++ b/bip-0022.mediawiki
@@ -12,6 +12,10 @@
This BIP describes a new JSON-RPC method for "smart" Bitcoin miners and proxies.
Instead of sending a simple block header for hashing, the entire block structure is sent, and left to the miner to (optionally) customize and assemble.
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
==Specification==
===Block Template Request===
diff --git a/bip-0023.mediawiki b/bip-0023.mediawiki
index 0390958..1c7e721 100644
--- a/bip-0023.mediawiki
+++ b/bip-0023.mediawiki
@@ -11,6 +11,10 @@
This BIP describes extensions to the getblocktemplate JSON-RPC call to enhance pooled mining.
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
==Specification==
Note that all sections of this specification are optional extensions on top of [[bip-0022.mediawiki|BIP 22]].
diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki
index 13e2ed9..e266ab8 100644
--- a/bip-0067.mediawiki
+++ b/bip-0067.mediawiki
@@ -126,3 +126,8 @@ The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributi
== References ==
<references>
+
+
+== Copyright ==
+This document is placed in the public domain.
+
diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki
index 11fa43b..878d708 100644
--- a/bip-0075.mediawiki
+++ b/bip-0075.mediawiki
@@ -105,7 +105,7 @@ message InvoiceRequest {
{| class="wikitable"
! Field Name !! Description
|-
-| sender_public_key || Sender's EC public key
+| sender_public_key || Sender's SEC-encoded EC public key
|-
| amount || amount is integer-number-of-satoshis (default: 0)
|-
@@ -141,7 +141,7 @@ message ProtocolMessage {
required ProtocolMessageType message_type = 3;
required bytes serialized_message = 4;
optional string status_message = 5;
- optional bytes identifier = 6;
+ required bytes identifier = 6;
}
</pre>
@@ -158,7 +158,7 @@ message ProtocolMessage {
|-
|status_message || Human-readable Payment Protocol status message
|-
-|identifier || Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default
+|identifier || Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String)
|}
===Versioning===
@@ -177,7 +177,7 @@ message EncryptedProtocolMessage {
required bytes receiver_public_key = 5;
required bytes sender_public_key = 6;
required uint64 nonce = 7;
- optional bytes identifier = 8;
+ required bytes identifier = 8;
optional string status_message = 9;
optional bytes signature = 10;
}
@@ -193,13 +193,13 @@ message EncryptedProtocolMessage {
|-
| encrypted_message || AES-256-GCM Encrypted (as defined in BIP75) Payment Protocol Message
|-
-| receiver_public_key || Receiver's DER-encoded EC Public Key
+| receiver_public_key || Receiver's SEC-encoded EC Public Key
|-
-| sender_public_key || Sender's DER-encoded EC Public Key
+| sender_public_key || Sender's SEC-encoded EC Public Key
|-
| nonce || Microseconds since epoch
|-
-| identifier || Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default
+| identifier || Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String)
|-
| status_message || Human-readable Payment Protocol status message
|-
@@ -362,7 +362,7 @@ When either '''status_code''' OR '''status_message''' are present, the AES-256 G
Initial public key retrieval for [[#InvoiceRequest|InvoiceRequest]] encryption via [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulation can be done in a number of ways including, but not limited to, the following:
# Wallet Name public key asset type resolution - DNSSEC-validated name resolution returns Base64 encoded DER-formatted EC public key via TXT Record [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
# Key Server lookup - Key Server lookup (similar to PGP's pgp.mit.edu) based on key server identifier (i.e., e-mail address) returns Base64 encoded DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
-# QR Code - Use of QR-code to encode DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
+# QR Code - Use of QR-code to encode SEC-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
# Address Service Public Key Exposure
==Payment / PaymentACK Messages with a HTTP Store & Forward Server==
@@ -376,7 +376,8 @@ If a Store & Forward server wishes to protect themselves from spam or abuse, the
Clients SHOULD keep in mind Receivers can broadcast a transaction without returning an ACK. If a Payment message needs to be updated, it SHOULD include at least one input referenced in the original transaction to prevent the Receiver from broadcasting both transactions and getting paid twice.
==Public Key & Signature Encoding==
-* All EC public keys ('''sender_public_key''', '''receiver_public_key''') or x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded.
+* All x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded.
+* All EC public keys ('''sender_public_key''', '''receiver_public_key''') in any message defined in this BIP MUST be [[SECP256k1|http://www.secg.org/sec2-v2.pdf]] ECDSA Public Key ECPoints encoded using [[SEC 2.3.3 Encoding|http://www.secg.org/sec1-v2.pdf]]. Encoding MAY be compressed.
* All ECC signatures included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded.
* All OpenPGP certificates must follow [[https://tools.ietf.org/html/rfc4880|RFC4880]], sections 5.5 and 12.1.
diff --git a/bip-0075/paymentrequest.proto b/bip-0075/paymentrequest.proto
index 5a08192..5097abb 100644
--- a/bip-0075/paymentrequest.proto
+++ b/bip-0075/paymentrequest.proto
@@ -70,7 +70,7 @@ message ProtocolMessage {
required ProtocolMessageType message_type = 3; // Message Type of serialized_message
required bytes serialized_message = 4; // Serialized Payment Protocol Message
optional string status_message = 5; // Human-readable Payment Protocol status message
- optional bytes identifier = 6; // Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default
+ required bytes identifier = 6; // Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String)
}
message EncryptedProtocolMessage {
@@ -81,7 +81,7 @@ message EncryptedProtocolMessage {
required bytes receiver_public_key = 5; // Receiver's DER-encoded EC Public Key
required bytes sender_public_key = 6; // Sender's DER-encoded EC Public Key
required uint64 nonce = 7; // Microseconds since epoch
- optional bytes identifier = 8; // Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default
+ required bytes identifier = 8; // Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String)
optional string status_message = 9; // Human-readable Payment Protocol status message
optional bytes signature = 10; // Signature over the full EncryptedProtocolMessage with EC Key Belonging to Sender / Receiver, respectively
} \ No newline at end of file
diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki
index 667ef5f..bd37489 100644
--- a/bip-0109.mediawiki
+++ b/bip-0109.mediawiki
@@ -2,7 +2,7 @@
BIP: 109
Title: Two million byte size limit with sigop and sighash limits
Author: Gavin Andresen <gavinandresen@gmail.com>
- Status: Draft
+ Status: Rejected
Type: Standards Track
Created: 2016-01-28
</pre>
diff --git a/bip-0123.mediawiki b/bip-0123.mediawiki
index 3d40326..3005f01 100644
--- a/bip-0123.mediawiki
+++ b/bip-0123.mediawiki
@@ -1,6 +1,5 @@
<pre>
BIP: 123
- Layer: Process
Title: BIP Classification
Author: Eric Lombrozo <elombrozo@gmail.com>
Status: Draft
@@ -31,6 +30,8 @@ Standards BIPs are placed in one of four layers:
# API/RPC
# Applications
+Non-standards BIPs may be placed in these layers, or none at all.
+
===1. Consensus Layer===
The consensus layer defines cryptographic commitment structures. Its purpose is ensuring that anyone can locally evaluate whether a particular state and history is valid, providing settlement guarantees, and assuring eventual convergence.
@@ -76,19 +77,26 @@ The applications layer specifies high level structures, abstractions, and conven
!Status
|- style="background-color: #cfffcf"
| [[bip-0001.mediawiki|1]]
-| Process
+|
| BIP Purpose and Guidelines
| Amir Taaki
-| Standard
+| Process
| Active
|-
+| [[bip-0002.mediawiki|2]]
+|
+| BIP process, revised
+| Luke Dashjr
+| Process
+| Draft
+|- style="background-color: #cfffcf"
| [[bip-0009.mediawiki|9]]
-| Consensus (soft fork)
+|
| Version bits with timeout and delay
| Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
| Informational
-| Draft
-|-
+| Final
+|- style="background-color: #ffcfcf"
| [[bip-0010.mediawiki|10]]
| Applications
| Multi-Sig Transaction Distribution
@@ -97,11 +105,11 @@ The applications layer specifies high level structures, abstractions, and conven
| Withdrawn
|- style="background-color: #cfffcf"
| [[bip-0011.mediawiki|11]]
-| Peer Services
+| Applications
| M-of-N Standard Transactions
| Gavin Andresen
| Standard
-| Accepted
+| Final
|- style="background-color: #ffcfcf"
| [[bip-0012.mediawiki|12]]
| Consensus (soft fork)
@@ -122,8 +130,8 @@ The applications layer specifies high level structures, abstractions, and conven
| Protocol Version and User Agent
| Amir Taaki, Patrick Strateman
| Standard
-| Accepted
-|- style="background-color: #ffcfcf"
+| Final
+|-
| [[bip-0015.mediawiki|15]]
| Applications
| Aliases
@@ -133,7 +141,7 @@ The applications layer specifies high level structures, abstractions, and conven
|- style="background-color: #cfffcf"
| [[bip-0016.mediawiki|16]]
| Consensus (soft fork)
-| Pay To Script Hash
+| Pay to Script Hash
| Gavin Andresen
| Standard
| Final
@@ -142,18 +150,18 @@ The applications layer specifies high level structures, abstractions, and conven
| Consensus (soft fork)
| OP_CHECKHASHVERIFY (CHV)
| Luke Dashjr
+| Standard
| Withdrawn
-| Draft
-|-
+|- style="background-color: #ffffcf"
| [[bip-0018.mediawiki|18]]
| Consensus (soft fork)
| hashScriptCheck
| Luke Dashjr
| Standard
-| Draft
+| Accepted
|-
| [[bip-0019.mediawiki|19]]
-| Peer Services
+| Applications
| M-of-N Standard Transactions (Low SigOp)
| Luke Dashjr
| Standard
@@ -171,21 +179,21 @@ The applications layer specifies high level structures, abstractions, and conven
| URI Scheme
| Nils Schneider, Matt Corallo
| Standard
-| Accepted
+| Final
|- style="background-color: #cfffcf"
| [[bip-0022.mediawiki|22]]
| API/RPC
| getblocktemplate - Fundamentals
| Luke Dashjr
| Standard
-| Accepted
+| Final
|- style="background-color: #cfffcf"
| [[bip-0023.mediawiki|23]]
| API/RPC
| getblocktemplate - Pooled Mining
| Luke Dashjr
| Standard
-| Accepted
+| Final
|- style="background-color: #cfffcf"
| [[bip-0030.mediawiki|30]]
| Consensus (soft fork)
@@ -199,17 +207,17 @@ The applications layer specifies high level structures, abstractions, and conven
| Pong message
| Mike Hearn
| Standard
-| Accepted
+| Final
|- style="background-color: #cfffcf"
| [[bip-0032.mediawiki|32]]
| Applications
| Hierarchical Deterministic Wallets
| Pieter Wuille
| Informational
-| Accepted
+| Final
|-
| [[bip-0033.mediawiki|33]]
-| API/RPC
+| Peer Services
| Stratized Nodes
| Amir Taaki
| Standard
@@ -217,17 +225,17 @@ The applications layer specifies high level structures, abstractions, and conven
|- style="background-color: #cfffcf"
| [[bip-0034.mediawiki|34]]
| Consensus (soft fork)
-| Block v2, Height in coinbase
+| Block v2, Height in Coinbase
| Gavin Andresen
| Standard
-| Accepted
+| Final
|- style="background-color: #cfffcf"
| [[bip-0035.mediawiki|35]]
| Peer Services
| mempool message
| Jeff Garzik
| Standard
-| Accepted
+| Final
|-
| [[bip-0036.mediawiki|36]]
| Peer Services
@@ -238,38 +246,24 @@ The applications layer specifies high level structures, abstractions, and conven
|- style="background-color: #cfffcf"
| [[bip-0037.mediawiki|37]]
| Peer Services
-| Bloom filtering
-| Mike Hearn and Matt Corallo
+| Connection Bloom filtering
+| Mike Hearn, Matt Corallo
| Standard
-| Accepted
+| Final
|-
| [[bip-0038.mediawiki|38]]
| Applications
| Passphrase-protected private key
-| Mike Caldwell
+| Mike Caldwell, Aaron Voisine
| Standard
| Draft
-|-
+|- style="background-color: #ffffcf"
| [[bip-0039.mediawiki|39]]
| Applications
| Mnemonic code for generating deterministic keys
-| Slush
-| Standard
-| Draft
-|-
-| 40
-| Applications
-| Stratum wire protocol
-| Slush
+| Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe
| Standard
-| BIP number allocated
-|-
-| 41
-| Applications
-| Stratum mining protocol
-| Slush
-| Standard
-| BIP number allocated
+| Accepted
|-
| [[bip-0042.mediawiki|42]]
| Consensus (soft fork)
@@ -281,31 +275,44 @@ The applications layer specifies high level structures, abstractions, and conven
| [[bip-0043.mediawiki|43]]
| Applications
| Purpose Field for Deterministic Wallets
-| Slush
-| Standard
+| Marek Palatinus, Pavol Rusnak
+| Informational
| Draft
-|-
+|- style="background-color: #ffffcf"
| [[bip-0044.mediawiki|44]]
| Applications
| Multi-Account Hierarchy for Deterministic Wallets
-| Slush
+| Marek Palatinus, Pavol Rusnak
| Standard
-| Draft
-|-
+| Accepted
+|- style="background-color: #ffffcf"
| [[bip-0045.mediawiki|45]]
| Applications
| Structure for Deterministic P2SH Multisignature Wallets
-| Manuel Araoz
+| Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia
| Standard
+| Accepted
+|-
+| [[bip-0047.mediawiki|47]]
+| Applications
+| Reusable Payment Codes for Hierarchical Deterministic Wallets
+| Justus Ranvier
+| Informational
| Draft
|-
-| [[bip-0050.mediawiki|50]]
+| [[bip-0049.mediawiki|49]]
+| Applications
+| Derivation scheme for P2WPKH-nested-in-P2SH based accounts
+| Daniel Weigl
| Informational
+| Draft
+|- style="background-color: #cfffcf"
+| [[bip-0050.mediawiki|50]]
+|
| March 2013 Chain Fork Post-Mortem
| Gavin Andresen
| Informational
-| Draft
-<!-- 50 series reserved for a group of post-mortems -->
+| Final
|-
| [[bip-0060.mediawiki|60]]
| Peer Services
@@ -313,97 +320,118 @@ The applications layer specifies high level structures, abstractions, and conven
| Amir Taaki
| Standard
| Draft
-|-
+|- style="background-color: #cfffcf"
| [[bip-0061.mediawiki|61]]
| Peer Services
-| "reject" P2P message
+| Reject P2P message
| Gavin Andresen
| Standard
| Final
-|-
+|- style="background-color: #ffcfcf"
| [[bip-0062.mediawiki|62]]
| Consensus (soft fork)
| Dealing with malleability
| Pieter Wuille
| Standard
-| Draft
-|-
-| 63
-| Applications
-| Stealth Addresses
-| Peter Todd
-| Standard
-| BIP number allocated
+| Withdrawn
|-
| [[bip-0064.mediawiki|64]]
| Peer Services
-| getutxos message
+| getutxo message
| Mike Hearn
| Standard
| Draft
-|-
+|- style="background-color: #cfffcf"
| [[bip-0065.mediawiki|65]]
| Consensus (soft fork)
| OP_CHECKLOCKTIMEVERIFY
| Peter Todd
| Standard
-| Draft
-|-
+| Final
+|- style="background-color: #cfffcf"
| [[bip-0066.mediawiki|66]]
| Consensus (soft fork)
| Strict DER signatures
| Pieter Wuille
| Standard
-| Draft
-|-
+| Final
+|- style="background-color: #ffffcf"
| [[bip-0067.mediawiki|67]]
| Applications
-| Deterministic P2SH multi-signature addresses
-| Thomas Kerin
+| Deterministic Pay-to-script-hash multi-signature addresses through public key sorting
+| Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
| Standard
-| Draft
-|-
+| Accepted
+|- style="background-color: #cfffcf"
| [[bip-0068.mediawiki|68]]
| Consensus (soft fork)
-| Consensus-enforced transaction replacement signalled via sequence numbers
-| Mark Friedenbach
+| Relative lock-time using consensus-enforced sequence numbers
+| Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona
| Standard
-| Draft
-|-
+| Final
+|- style="background-color: #ffffcf"
+| [[bip-0069.mediawiki|69]]
+| Applications
+| Lexicographical Indexing of Transaction Inputs and Outputs
+| Kristov Atlas
+| Informational
+| Accepted
+|- style="background-color: #cfffcf"
| [[bip-0070.mediawiki|70]]
| Applications
-| Payment protocol
-| Gavin Andresen
+| Payment Protocol
+| Gavin Andresen, Mike Hearn
| Standard
| Final
-|-
+|- style="background-color: #cfffcf"
| [[bip-0071.mediawiki|71]]
| Applications
-| Payment protocol MIME types
+| Payment Protocol MIME types
| Gavin Andresen
| Standard
| Final
-|-
+|- style="background-color: #cfffcf"
| [[bip-0072.mediawiki|72]]
| Applications
-| Payment protocol URIs
+| bitcoin: uri extensions for Payment Protocol
| Gavin Andresen
| Standard
| Final
-|-
+|- style="background-color: #cfffcf"
| [[bip-0073.mediawiki|73]]
| Applications
-| Use "Accept" header with Payment Request URLs
+| Use "Accept" header for response type negotiation with Payment Request URLs
| Stephen Pair
| Standard
+| Final
+|-
+| [[bip-0074.mediawiki|74]]
+| Applications
+| Allow zero value OP_RETURN in Payment Protocol
+| Toby Padilla
+| Standard
| Draft
|-
-| [[bip-0080.mediawiki|80]]
+| [[bip-0075.mediawiki|75]]
| Applications
+| Out of Band Address Exchange using Payment Protocol Encryption
+| Justin Newton, Matt David, Aaron Voisine, James MacWhyte
+| Standard
+| Draft
+|-
+| [[bip-0080.mediawiki|80]]
+|
| Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
-| Monetas
+| Justus Ranvier, Jimmy Song
| Informational
-| Draft
+| Deferred
+|-
+| [[bip-0081.mediawiki|81]]
+|
+| Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
+| Justus Ranvier, Jimmy Song
+| Informational
+| Deferred
|-
| [[bip-0083.mediawiki|83]]
| Applications
@@ -413,18 +441,18 @@ The applications layer specifies high level structures, abstractions, and conven
| Draft
|-
| [[bip-0099.mediawiki|99]]
-| Informational
+|
| Motivation and deployment of consensus rule changes ([soft/hard]forks)
| Jorge Timón
-| Informational / Process
+| Informational
| Draft
-|-
+|- style="background-color: #ffcfcf"
| [[bip-0101.mediawiki|101]]
| Consensus (hard fork)
| Increase maximum block size
| Gavin Andresen
| Standard
-| Draft
+| Withdrawn
|-
| [[bip-0102.mediawiki|102]]
| Consensus (hard fork)
@@ -442,7 +470,7 @@ The applications layer specifies high level structures, abstractions, and conven
|-
| [[bip-0105.mediawiki|105]]
| Consensus (hard fork)
-| Consensus based block size retargetting algorithm
+| Consensus based block size retargeting algorithm
| BtcDrak
| Standard
| Draft
@@ -461,25 +489,39 @@ The applications layer specifies high level structures, abstractions, and conven
| Standard
| Draft
|-
+| [[bip-0109.mediawiki|109]]
+| Consensus (hard fork)
+| Two million byte size limit with sigop and sighash limits
+| Gavin Andresen
+| Standard
+| Draft
+|- style="background-color: #ffffcf"
| [[bip-0111.mediawiki|111]]
| Peer Services
| NODE_BLOOM service bit
| Matt Corallo, Peter Todd
| Standard
-| Draft
-|-
+| Accepted
+|- style="background-color: #cfffcf"
| [[bip-0112.mediawiki|112]]
| Consensus (soft fork)
| CHECKSEQUENCEVERIFY
| BtcDrak, Mark Friedenbach, Eric Lombrozo
| Standard
-| Draft
-|-
+| Final
+|- style="background-color: #cfffcf"
| [[bip-0113.mediawiki|113]]
| Consensus (soft fork)
-| Median time-past as endpoint for locktime calculations
+| Median time-past as endpoint for lock-time calculations
| Thomas Kerin, Mark Friedenbach
| Standard
+| Final
+|-
+| [[bip-0114.mediawiki|114]]
+| Consensus (soft fork)
+| Merkelized Abstract Syntax Tree
+| Johnson Lau
+| Standard
| Draft
|-
| [[bip-0120.mediawiki|120]]
@@ -504,32 +546,39 @@ The applications layer specifies high level structures, abstractions, and conven
| Draft
|-
| [[bip-0123.mediawiki|123]]
-| Process
+|
| BIP Classification
| Eric Lombrozo
-| Standard
+| Process
| Draft
|-
| [[bip-0124.mediawiki|124]]
| Applications
| Hierarchical Deterministic Script Templates
| Eric Lombrozo, William Swanson
-| Standard
+| Informational
| Draft
-|-
+|- style="background-color: #ffffcf"
| [[bip-0125.mediawiki|125]]
-| Peer Services
+| Applications
| Opt-in Full Replace-by-Fee Signaling
-| David Harding, Peter Todd
+| David A. Harding, Peter Todd
| Standard
-| Draft
+| Accepted
|-
+| [[bip-0126.mediawiki|126]]
+|
+| Best Practices for Heterogeneous Input Script Transactions
+| Kristov Atlas
+| Informational
+| Draft
+|- style="background-color: #ffffcf"
| [[bip-0130.mediawiki|130]]
| Peer Services
| sendheaders message
| Suhas Daftuar
| Standard
-| Draft
+| Accepted
|-
| [[bip-0131.mediawiki|131]]
| Consensus (hard fork)
@@ -537,12 +586,26 @@ The applications layer specifies high level structures, abstractions, and conven
| Chris Priest
| Standard
| Draft
-|-
+|- style="background-color: #ffcfcf"
| [[bip-0132.mediawiki|132]]
-| Process
+|
| Committee-based BIP Acceptance Process
| Andy Chase
| Process
+| Withdrawn
+|-
+| [[bip-0133.mediawiki|133]]
+| Peer Services
+| feefilter message
+| Alex Morcos
+| Standard
+| Draft
+|-
+| [[bip-0134.mediawiki|134]]
+| Consensus (hard fork)
+| Flexible Transactions
+| Tom Zander
+| Standard
| Draft
|-
| [[bip-0140.mediawiki|140]]
@@ -564,7 +627,7 @@ The applications layer specifies high level structures, abstractions, and conven
| Address Format for Segregated Witness
| Johnson Lau
| Standard
-| Draft
+| Deferred
|-
| [[bip-0143.mediawiki|143]]
| Consensus (soft fork)
@@ -578,6 +641,47 @@ The applications layer specifies high level structures, abstractions, and conven
| Segregated Witness (Peer Services)
| Eric Lombrozo, Pieter Wuille
| Standard
-| Draft
+| Draft
+|-
+| [[bip-0145.mediawiki|145]]
+| API/RPC
+| getblocktemplate Updates for Segregated Witness
+| Luke Dashjr
+| Standard
+| Draft
+|-
+| [[bip-0146.mediawiki|146]]
+| Consensus (soft fork)
+| Dealing with signature encoding malleability
+| Johnson Lau, Pieter Wuille
+| Standard
+| Draft
+|-
+| [[bip-0147.mediawiki|147]]
+| Consensus (soft fork)
+| Dealing with dummy stack element malleability
+| Johnson Lau
+| Standard
+| Draft
+|-
+| [[bip-0150.mediawiki|150]]
+| Peer Services
+| Peer Authentication
+| Jonas Schnelli
+| Standard
+| Draft
+|-
+| [[bip-0151.mediawiki|151]]
+| Peer Services
+| Peer-to-Peer Communication Encryption
+| Jonas Schnelli
+| Standard
+| Draft
+|-
+| [[bip-0152.mediawiki|152]]
+| Peer Services
+| Compact Block Relay
+| Matt Corallo
+| Standard
+| Draft
|}
-
diff --git a/bip-0134.mediawiki b/bip-0134.mediawiki
index afb5143..fa2103b 100644
--- a/bip-0134.mediawiki
+++ b/bip-0134.mediawiki
@@ -29,7 +29,7 @@ in future. Soft fork upgrades will become much easier and cleaner this
way.
This protocol upgrade cleans up past soft fork changes like BIP68 which
-reuse existing fields and do them in a much better to maintain and easier
+reuse existing fields and do them in a better to maintain and easier
to parse system. It creates the building blocks to allow new features to be
added much cleaner in the future.
@@ -39,14 +39,29 @@ history. Tests show that this can reduce space usage to about 75%.
==Motivation==
+After 8 years of using essentially the same transaction version and layout
+Bitcoin is in need of an upgrade and lessons learned in that time are
+taking into account when designing it. The most important detail is that
+we have seen a need for more flexibility. For instance when the 'sequence'
+fields were introduced in the old transaction format, and later deprecated
+again, the end result was that all transactions still were forced to keep
+those fields and grow the blockchain while they all were set to the default
+value.
+
+The way towards that flexibility is to use a generic concept made popular
+various decades ago with the XML format. The idea is that we give each
+field a name and this means that new fields can be added or optional fields
+can be omitted from individual transactions. Some other ideas are the
+standardization of data-formats (like integer and string encoding) so
+we create a more consistent system.
+One thing we shall not inherit from XML is its text-based format. Instead
+we use the [https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md Compact Message Format]
+(CMF) which is optimized to keep the size small and fast to parse.
+
Token based file-formats are not new, systems like XML and HTMl use a
similar system to allow future growth and they have been quite successful
for decades in part because of this property.
-Bitcoin needs a similar way of making the transaction future-proof because
-re-purposing not used fields for new features is not good for creating
-maintainable code.
-
Next to that this protocol upgrade will re-order the data-fields which
allows us to cleanly fix the malleability issue which means that future
technologies like Lightning Network will depend on this BIP being deployed.
@@ -55,6 +70,19 @@ At the same time, due to this re-ordering of data fields, it becomes very
easy to remove signatures from a transaction without breaking its tx-id,
which is great for future pruning features.
+=== Features ===
+
+* Fixes malleability
+* Linear scaling of signature checking
+* Very flexible future extensibility
+* Makes transactions smaller
+* Supports the Lightning Network
+
+Additionally, in the v4 (flextrans) format we add the support for the
+following proofs;
+* input amount. Including the amount means we sign this transaction only if the amount we are spending is the one provided. Wallets that do not have the full UTXO DB can safely sign knowing that if they were lied to about the amount being spent, their signature is useless.
+* scriptBase is the combined script of input and output, without signatures naturally. Providing this to a hardware wallet means it knows what output it is spending and can respond properly. Including it in the hash means its signature would be broken if we lied..
+* Double spent-proof. Should a node detect a double spent he can notify his peers about this fact. Instead of sending the entire transactions, instead he sends only a proof. The node needs to send two pairs of info that proves that in both transactions the CTxIn are identical.
=== Tokens ===
@@ -63,7 +91,8 @@ define how these tokens are named, where they can be placed and which are
optional. To refer to XML, this specification would be the schema of
a transaction.
-CMF tokens are triplets of name, format (like PositiveInteger) and value.
+[https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md CMF]
+tokens are triplets of name, format (like PositiveInteger) and value.
Names in this scope are defined much like an enumeration where the actual
integer value (id, below) is equally important to the written name.
If any token found that is not covered in the next table it will make the
@@ -73,114 +102,92 @@ transaction that contains it invalid.
|-
! Name !! id !! Format !! Default Value !! Description
|-
-|TxEnd || 0 ||BoolTrue || Required ||A marker that is end of the transaction.
+|TxEnd || 0 ||BoolTrue || Required ||A marker that is the end of the transaction
|-
-|TxInPrevHash || 1 ||ByteArray|| Required ||TxId we are spending
+|TxInPrevHash || 1 ||ByteArray|| Required ||TxId we are spending
|-
-|TxPrevIndex || 2 ||Integer || 0 ||Index in prev tx we are spending (applied to previous TxInPrevHash)
+|TxPrevIndex || 2 ||Integer || 0 ||Index in prev tx we are spending (applied to previous TxInPrevHash)
|-
-|TxInScript || 3 ||ByteArray|| Required ||The 'input' part of the script
+|TxInputStackItem || 3 ||ByteArray|| &nbsp; ||A 'push' of the input script
|-
-|TxOutValue || 4 ||Integer || Required ||Amount of Satoshis to transfer
+|TxInputStackItemContinued||4||ByteArray|| &nsbp; ||Another section for the same input
|-
-|TxOutScript || 5 ||ByteArray|| Required ||The 'output' part of the script
+|TxOutValue || 5 ||Integer || Required ||Amount of Satoshis to transfer
|-
-|LockByBlock || 6 ||Integer || Optional ||BIP68 replacement
+|TxOutScript || 6 ||ByteArray|| Required ||The output script
|-
-|LockByTime || 7 ||Integer || Optional ||BIP68 replacement
+|TxRelativeBlockLock|| 7 ||Integer || Optional ||Part of the input stating the amount of blocks (max 0XFFFF) after that input was mined, it can be mined
|-
-|ScriptVersion || 8 ||Integer || 2 ||Defines script version for outputs following
+|TxRelativeTimeLock || 8 ||Integer || Optional ||Part of the input stating the amount of time (max 0XFFFF) after that input was mined, it can be mined. 1 Unit is 512 seconds
+|-
+|CoinbaseMessage || 9 ||ByteArray|| Optional ||A message and some data for a coinbase transaction. Can't be used in combination with any TxIn\* tags
+|-
+|NOP_1x || 1x || &nbsp;|| Optional ||Values that will be ignored by anyone parsing the transaction
|-
-|NOP_1x || 1x || . || Optional ||Values that will be ignored by anyone parsing the transaction
|}
=== Scripting changes ===
-In the current version of Bitcoin-script, version 1, there are various
-opcodes that are used to validate the cryptographic proofs that users have
-to provide in order to spend outputs.
+In Bitcoin transactions version 1, checking of signatures is performed by
+various opcodes. The OP_CHECKSIG, OP_CHECKMULTISIG and their equivalents
+that immediately VERIFY. These are used to validate the cryptographic
+proofs that users have to provide in order to spend outputs.
+
+We additionally have some hashing-types in like SIGHASH_SINGLE that all
+specify slightly different subsections of what part of a transaction will
+be hashed in order to be signed.
+
+For transactions with version 4 we calculate a sha256 hash for signing an
+individual input based on the following content;
+
+# If the hash-type is 0 or 1 we hash the tx-id of the transaction. For other hash types we selectively ignore parts of the transaction exactly like it has always worked. With the caveat that we never serialize any signatures.
+# the TxId of the transaction we are spending in this input.
+# the index of output of the transaction we are spending in this input.
+# the input script we are signing (without the signature, naturally).
+# the amount, as a var-int.
+# the hash-type as a var-int.
-The OP_CHECKSIG is the most well known and, as its name implies, it
-validates a signature.
-In the new version of 'script' (version 2) the data that is signed is
-changed to be equivalent to the transaction-id. This is a massive
-simplification and also the only change between version 1 and version 2 of
-script.
=== Serialization order===
-The tokens defined above shall be serialized in a certain order for the
-transaction to be valid. Not serializing transactions in the
-order specified would allow multiple interpretations of the data which
-can't be allowed.
-There is still some flexibility and for that reason it is important for
-implementors to remember that the actual serialized data is used for the
-calculation of the transaction-id. Reading and writing it may give you a
-different output and when the txid changes, the signatures will break.
-At a macro-level the transaction has these segments. The order of the
-segments can not be changed, but you can skip segments.
+To keep in line with the name Flexible Transactions, there is very little
+requirement to have a specific order. The only exception is cases where
+there are optional values and reordering would make unclear what is meant.
-{| class="wikitable"
-!Segment !! Description
-|-
-| Inputs || Details about inputs.
-|-
-| Outputs || Details and scripts for outputs
-|-
-| Additional || For future expansion
-|-
-| Signatures || The scripts for the inputs
-|-
-| TxEnd || End of the transaction
-|}
+For this reason the TxInPrevHash always has to be the first token to start
+a new input. This is because the TxPrevIndex is optional. The tokens
+TxRelativeTimeLock and TxRelativeBlockLock are part of the input and
+similarly have to be set after the TxInPrevHash they belong to.
-The TxId is calculated by taking the serialized transaction without the
-Signatures and the TxEnd and hashing that.
+Similarly, the TxInputStackItem always has to be the first and can be
+followed by a number of TxInputStackItemContinued items.
+At a larger scope we define 3 sections of a transaction.
{| class="wikitable"
!Segment !! Tags !! Description
|-
-|Inputs||TxInPrevHash and TxInPrevIndex||Index can be skipped, but in any input the PrevHash always has to come first
-|-
-|Outputs||TxOutScript, TxOutValue||Order is not relevant
-|-
-|Additional||LockByBlock LockByTime NOP_1x
+|Transaction||all not elsewhere used||This section is used to make the TxId
|-
-|Signatures||TxInScript||Exactly the same amount as there are inputs
+|Signatures||TxInputStackItem, TxInputStackItemContinued||The input-proofs
|-
-|TxEnd||TxEnd
+|TxEnd||TxEnd||&nbsp;
|}
+The TxId is calculated by taking the serialized transaction without the
+Signatures and the TxEnd and hashing that.
+
TxEnd is there to allow a parser to know when one transaction in a stream
has ended, allowing the next to be parsed.
-Notice that the token ScriptVersion is currently not allowed because we
-don't have any valid value to give it. But if we introduce a new script
-version it would be placed in the outputs segment.
-
-=== Script v2 ===
-
-The default value of ScriptVersion is number 2, as opposed to the version 1
-of script that is in use today. The version 2 is mostly identical
-to version one, including upgrades made to it over the years and in the
-future. The only exception is that the OP_CHECKSIG is made dramatically
-simpler. The input-type for OP_CHECKSIG is now no longer configurable, it is
-always '1' and the content that will be signed is the txid.
-
-TODO: does check-multisig need its own mention?
-
-
=== Block-malleability ===
The effect of leaving the signatures out of the calculation of the
transaction-id implies that the signatures are also not used for the
calculation of the merkle tree. This means that changes in signatures
-would not be detectable. Except naturally by the fact that missing or
-broken signatures breaks full validation. But it is important to detect
-modifications to such signatures outside of validating all transactions.
+would not be detectable and open an attack vector.
For this reason the merkle tree is extended to include (append) the hash of
the v4 transactions. The markle tree will continue to have all the
@@ -188,9 +195,8 @@ transactions' tx-ids but appended to that are the v4 hashes that include the
signatures as well. Specifically the hash is taken over a data-blob that
is built up from:
-1. the tx-id
-2. the CMF-tokens 'TxInScript'
-
+# the tx-id
+# The entire bytearray that makes up all of the transactions signatures. This is a serialization of all of the signature tokens, so the TxInputStackItem and TxInputStackItemContinued in the order based on the inputs they are associated with.
=== Future extensibility ===
@@ -207,9 +213,18 @@ trivially use these tokens for their own usage without cooperation and
communication with the rest of the Bitcoin ecosystem as miners certainly
have the option to reject transactions that use unknown-to-them tokens.
+The amount of tokens that can be added after number 19 is practically
+unlimited and they are currently specified to not be allowed in any
+transaction and the transaction will be rejected if they are present.
+In the future a protocol upgrade may chance that and specify meaning for
+any token not yet specified here. Future upgrades should thus be quite a
+lot smoother because there is no change in concepts or in format. Just new
+data.
+
==Backwards compatibility ==
-Fully validating older clients are not compatible with this change.
+Fully validating older clients will not be able to understand or validate
+version 4 transactions and will need to be updated to restore that ability.
SPV (simple payment validation) wallets need to be updated to receive or
create the new transaction type.
@@ -220,11 +235,12 @@ backwards compatible for any existing data or parsing-code.
==Reference Implementation==
-Bitcoin Classic includes this in its beta releases and a reference
-implementation can be found at;
-
-https://github.com/bitcoinclassic/bitcoinclassic/pull/186
+Bitcoin Classic includes an implementation that is following this spec.
+The spec-author rejects the notion of reference implementation. The
+specification is always authoritative, the implementation is not.
+The official spec can be found at;
+https://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.md
==Deployment==
diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
index b1cc468..e05cc2a 100644
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@@ -128,7 +128,7 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
====getblocktxn====
# The getblocktxn message is defined as as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn".
-# Upon receipt of a properly-formatted getblocktxnmessage, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with an appropriate blocktxn message. Such a blocktxn message MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested.
+# Upon receipt of a properly-formatted getblocktxn message, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with either an appropriate blocktxn message, or a full block message. A blocktxn response MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested.
====blocktxn====
# The blocktxn message is defined as as a message containing a serialized BlockTransactions message and pchCommand == "blocktxn".
diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl
index f0e43d2..d8f52f2 100755
--- a/scripts/buildtable.pl
+++ b/scripts/buildtable.pl
@@ -31,9 +31,6 @@ my %MiscField = (
'Resolution' => undef,
);
-my %ValidLayer = (
- Process => undef,
-);
my %ValidStatus = (
Draft => undef,
Deferred => undef,
@@ -106,8 +103,6 @@ while (++$bipnum <= $topbip) {
} else {
$type = $val;
}
- } elsif ($field eq 'Layer') { # BIP 123
- die "Invalid layer $val in $fn" unless exists $ValidLayer{$val};
} elsif (exists $DateField{$field}) {
die "Invalid date format in $fn" unless $val =~ /^20\d{2}\-(?:0\d|1[012])\-(?:[012]\d|30|31)$/;
} elsif (exists $EmailField{$field}) {
generated by cgit v1.2.3 (git 2.26.2) at 2024-08-30 22:23:22 +0000