summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--README.mediawiki34
-rw-r--r--bip-0010.mediawiki2
-rw-r--r--bip-0013.mediawiki2
-rw-r--r--bip-0032.mediawiki4
-rw-r--r--bip-0070.mediawiki10
5 files changed, 45 insertions, 7 deletions
diff --git a/README.mediawiki b/README.mediawiki
index 4f1431d..26b8d5d 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -10,173 +10,207 @@ Those proposing changes should consider that ultimately consent may rest with th
!Number
!Title
!Owner
+!Type
!Status
|- style="background-color: #cfffcf"
| [[bip-0001.mediawiki|1]]
| BIP Purpose and Guidelines
| Amir Taaki
+| Standard
| Active
|-
| [[bip-0010.mediawiki|10]]
| Multi-Sig Transaction Distribution
| Alan Reiner
+| Informational
| Draft
|- style="background-color: #cfffcf"
| [[bip-0011.mediawiki|11]]
| M-of-N Standard Transactions
| Gavin Andresen
+| Standard
| Accepted
|- style="background-color: #ffcfcf"
| [[bip-0012.mediawiki|12]]
| OP_EVAL
| Gavin Andresen
+| Standard
| Withdrawn
|- style="background-color: #cfffcf"
| [[bip-0013.mediawiki|13]]
| Address Format for pay-to-script-hash
| Gavin Andresen
+| Standard
| Final
|- style="background-color: #cfffcf"
| [[bip-0014.mediawiki|14]]
| Protocol Version and User Agent
| Amir Taaki, Patrick Strateman
+| Standard
| Accepted
|- style="background-color: #ffcfcf"
| [[bip-0015.mediawiki|15]]
| Aliases
| Amir Taaki
+| Standard
| Withdrawn
|- style="background-color: #cfffcf"
| [[bip-0016.mediawiki|16]]
| Pay To Script Hash
| Gavin Andresen
+| Standard
| Accepted
|- style="background-color: #ffcfcf"
| [[bip-0017.mediawiki|17]]
| OP_CHECKHASHVERIFY (CHV)
| Luke Dashjr
| Withdrawn
+| Draft
|-
| [[bip-0018.mediawiki|18]]
| hashScriptCheck
| Luke Dashjr
+| Standard
| Draft
|-
| [[bip-0019.mediawiki|19]]
| M-of-N Standard Transactions (Low SigOp)
| Luke Dashjr
+| Standard
| Draft
|- style="background-color: #ffcfcf"
| [[bip-0020.mediawiki|20]]
| URI Scheme
| Luke Dashjr
+| Standard
| Replaced
|- style="background-color: #cfffcf"
| [[bip-0021.mediawiki|21]]
| URI Scheme
| Nils Schneider, Matt Corallo
+| Standard
| Accepted
|- style="background-color: #cfffcf"
| [[bip-0022.mediawiki|22]]
| getblocktemplate - Fundamentals
| Luke Dashjr
+| Standard
| Accepted
|- style="background-color: #cfffcf"
| [[bip-0023.mediawiki|23]]
| getblocktemplate - Pooled Mining
| Luke Dashjr
+| Standard
| Accepted
|- style="background-color: #cfffcf"
| [[bip-0030.mediawiki|30]]
| Duplicate transactions
| Pieter Wuille
+| Standard
| Accepted
|- style="background-color: #cfffcf"
| [[bip-0031.mediawiki|31]]
| Pong message
| Mike Hearn
+| Standard
| Accepted
|- style="background-color: #cfffcf"
| [[bip-0032.mediawiki|32]]
| Hierarchical Deterministic Wallets
| Pieter Wuille
+| Informational
| Accepted
|-
| [[bip-0033.mediawiki|33]]
| Stratized Nodes
| Amir Taaki
+| Standard
| Draft
|- style="background-color: #cfffcf"
| [[bip-0034.mediawiki|34]]
| Block v2, Height in coinbase
| Gavin Andresen
+| Standard
| Accepted
|- style="background-color: #cfffcf"
| [[bip-0035.mediawiki|35]]
| mempool message
| Jeff Garzik
+| Standard
| Accepted
|-
| [[bip-0036.mediawiki|36]]
| Custom Services
| Stefan Thomas
+| Standard
| Draft
|- style="background-color: #cfffcf"
| [[bip-0037.mediawiki|37]]
| Bloom filtering
| Mike Hearn and Matt Corallo
+| Standard
| Accepted
|-
| [[bip-0038.mediawiki|38]]
| Passphrase-protected private key
| Mike Caldwell
+| Standard
| Draft
|-
| [[bip-0039.mediawiki|39]]
| Mnemonic code for generating deterministic keys
| Slush
+| Standard
| Draft
|-
| 40
| Stratum wire protocol
| Slush
+| Standard
| BIP number allocated
|-
| 41
| Stratum mining protocol
| Slush
+| Standard
| BIP number allocated
<!-- 42-49 reserved for stratum extensions -->
|-
| [[bip-0050.mediawiki|50]]
| March 2013 Chain Fork Post-Mortem
| Gavin Andresen
+| Informational
| Draft
<!-- 50 series reserved for a group of post-mortems -->
|-
| [[bip-0060.mediawiki|60]]
| Fixed Length "version" Message (Relay-Transactions Field)
| Amir Taaki
+| Standard
| Draft
|-
| [[bip-0070.mediawiki|70]]
| Payment protocol
| Gavin Andresen
+| Standard
| Draft
|-
| [[bip-0071.mediawiki|71]]
| Payment protocol MIME types
| Gavin Andresen
+| Standard
| Draft
|-
| [[bip-0072.mediawiki|72]]
| Payment protocol URIs
| Gavin Andresen
+| Standard
| Draft
|-
| [[bip-0073.mediawiki|73]]
| Use "Accept" header with Payment Request URLs
| Stephen Pair
+| Standard
| Draft
|}
diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki
index ac4f4a4..76712f5 100644
--- a/bip-0010.mediawiki
+++ b/bip-0010.mediawiki
@@ -26,7 +26,7 @@ This BIP proposes the following process, with terms in quotes referring to recom
# The user creating the TxDP (the preparer) will create the transaction as they would like to see it spent, but with blank TxIn scripts (where the signatures scripts will eventually go).
# The proposed transaction will be spending a set of unspent TxOuts available in the blockchain. The full transactions containing these TxOuts will be serialized and included, as well. This so that the values of the TxIns can be verified before signing (the prev-tx-hash is part of the data being signed, but the value is not). By including the full tx, the signing party can verify that the tx matches the OutPoint hash, and then verify input values, all without any access to the blockchain.
# The TxDP will have an "DP ID" or "Unsigned ID" which is the hash of the proposed transaction with blanked scripts, in Base58. This is a specific naming convention to make sure it is not confused with the actual the transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected). The final Tx ID can be referred to as its "Broadcast ID", in order to distinguish it from the pre-signed ID.
-# The TxDP will have an potentially-unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it.
+# The TxDP will have a potentially-unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it.
# Identical TxDP objects with different signatures can be easily combined. This allows one party to send out all the requests for signatures at once, and combine them all when they are received (instead of having to "pass it around".
# For cases where the TxDP might be put into a file or sent via email, it should use .txdp or .btcdp suffix
diff --git a/bip-0013.mediawiki b/bip-0013.mediawiki
index ce71a6a..367862b 100644
--- a/bip-0013.mediawiki
+++ b/bip-0013.mediawiki
@@ -25,7 +25,7 @@ The new bitcoin address type is constructed in the same manner as existing bitco
Version byte is 5 for a main-network address, 196 for a testnet address.
The 20-byte hash is the hash of the script that will be used to redeem the coins.
-And the 4-byte checksum is the first four bytes of the SHA256 hash of the version and hash.
+And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and hash.
==Rationale==
diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index 10dbf9f..a835d26 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -238,6 +238,10 @@ A C++ implementation is available at https://github.com/CodeShark/CoinClasses/tr
A Ruby implementation is available at https://github.com/wink/money-tree
+A Go implementation is available at https://github.com/WeMeetAgain/go-hdwallet
+
+A JavaScript implementation is available at https://github.com/sarchar/brainwallet.github.com/tree/bip32
+
==Acknowledgements==
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.
diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 7e434f9..699ff32 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -84,15 +84,15 @@ about the merchant and a digital signature.
{|
| network || either "main" for payments on the production Bitcoin network, or "test" for payments on test network. If a client receives a PaymentRequest for a network it does not support it must reject the request.
|-
-| outputs|| one or more outputs where Bitcoins are to be sent. If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored).
+| outputs || one or more outputs where Bitcoins are to be sent. If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored).
|-
-| time|| Unix timestamp (seconds since 1-Jan-1970) when the PaymentRequest was created.
+| time || Unix timestamp (seconds since 1-Jan-1970) when the PaymentRequest was created.
|-
-| expires|| Unix timestamp after which the PaymentRequest should be considered invalid.
+| expires || Unix timestamp after which the PaymentRequest should be considered invalid.
|-
-| memo|| UTF-8 encoded, plain-text (no formatting) note that should be displayed to the customer, explaining what this PaymentRequest is for.
+| memo || UTF-8 encoded, plain-text (no formatting) note that should be displayed to the customer, explaining what this PaymentRequest is for.
|-
-| payment_url|| Secure (usually https) location where a Payment message (see below) may be sent to obtain a PaymentACK.
+| payment_url || Secure (usually https) location where a Payment message (see below) may be sent to obtain a PaymentACK.
|-
| merchant_data || Arbitrary data that may be used by the merchant to identify the PaymentRequest. May be omitted if the merchant does not need to associate Payments with PaymentRequest or if they associate each PaymentRequest with a separate payment address.
|}
generated by cgit v1.2.3 (git 2.26.2) at 2024-08-28 09:41:22 +0000