mirror of
https://github.com/bitcoin/bips.git
synced 2024-11-19 01:40:05 +01:00
Fix formatting
This commit is contained in:
Peter Todd
parent
3b0e74507e
commit
d9e890a8f2
@ -1,10 +1,10 @@
|
||||
People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here.
|
||||
People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here.
|
||||
|
||||
We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.
|
||||
|
||||
Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.
|
||||
|
||||
Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: [[economic majority]]).
|
||||
Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority]).
|
||||
|
||||
{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
|
||||
!Number
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 1
|
||||
Title: BIP Purpose and Guidelines
|
||||
@ -26,7 +24,7 @@ There are three kinds of BIP:
|
||||
|
||||
==BIP Work Flow==
|
||||
|
||||
The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to <gmaxwell@gmail.com> (no cross-posting please). Also see BIP Editor Responsibilities & Workflow below.
|
||||
The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to gmaxwell@gmail.com (no cross-posting please). Also see BIP Editor Responsibilities & Workflow below.
|
||||
|
||||
The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones.
|
||||
|
||||
@ -36,7 +34,7 @@ Vetting an idea publicly before going as far as writing a BIP is meant to save t
|
||||
|
||||
Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal.
|
||||
|
||||
Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors <gmaxwell@gmail.com>. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
|
||||
Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors gmaxwell@gmail.com. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
|
||||
|
||||
If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and create and create a page for it on the [[Bitcoin_Improvement_Proposals|Bitcoin Wiki]]. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.
|
||||
|
||||
@ -58,7 +56,7 @@ BIPs can also be superseded by a different BIP, rendering the original obsolete.
|
||||
|
||||
The possible paths of the status of BIPs are as follows:
|
||||
|
||||
[[File:BIP-0001-Process.png]]
|
||||
<img src=bip-0001/process.png></img>
|
||||
|
||||
Some Informational and Process BIPs may also have a status of "Active" if they are never meant to be completed. E.g. BIP 1 (this BIP).
|
||||
|
||||
@ -140,10 +138,10 @@ BIPs may include auxiliary files such as diagrams. Such files must be named BIP-
|
||||
|
||||
It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.
|
||||
|
||||
If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor <gmaxwell@gmail.com>. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
|
||||
If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor gmaxwell@gmail.com. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
|
||||
BIP Editor Responsibilities & Workflow
|
||||
|
||||
A BIP editor must subscribe to the <gmaxwell@gmail.com> list. All BIP-related correspondence should be sent (or CC'd) to <gmaxwell@gmail.com> (but please do not cross-post!).
|
||||
A BIP editor must subscribe to the gmaxwell@gmail.com list. All BIP-related correspondence should be sent (or CC'd) to gmaxwell@gmail.com (but please do not cross-post!).
|
||||
|
||||
For each new BIP that comes in an editor does the following:
|
||||
|
||||
@ -170,5 +168,3 @@ The editors don't pass judgement on BIPs. We merely do the administrative & edit
|
||||
==History==
|
||||
|
||||
This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the Bitcoin editors or the forums at bitcointalk.org.
|
||||
|
||||
[[Category:BIP|A]]
|
||||
|
||||
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 10
|
||||
Title: Multi-Sig Transaction Distribution
|
||||
@ -34,6 +32,7 @@ This BIP proposes the following process, with terms in quotes referring to recom
|
||||
|
||||
Anyone adopting BIP 0010 for multi-sig transactions will use the following format (without indentation):
|
||||
|
||||
<pre>
|
||||
'-----BEGIN-TRANSACTION-TXDPID-------'
|
||||
("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
|
||||
(serializedTxListInHex_Line1)
|
||||
@ -50,10 +49,11 @@ Anyone adopting BIP 0010 for multi-sig transactions will use the following forma
|
||||
(SigHexRemainingLines)
|
||||
("_TXINPUT_") (02) (InputValue)
|
||||
'-------END-TRANSACTION-TXDPID-------'
|
||||
|
||||
</pre>
|
||||
|
||||
The following is an example TxDP from Armory, produced while running on the test network. Its DPID is 3fX59xPj:
|
||||
|
||||
</pre>
|
||||
-----BEGIN-TRANSACTION-3fX59xPj-------------------------------------------------
|
||||
_TXDIST_fabfb5da_3fX59xPj_00a0
|
||||
010000000292807c8e70a28c687daea2998d6273d074e56fa8a55a0b10556974cf2b526e61000000
|
||||
@ -86,8 +86,7 @@ The following is an example TxDP from Armory, produced while running on the test
|
||||
456298a566aa76fefeab8a7cb7a91e8a936a11757c911b4c669f0434d12ab0936fc13986b156156f
|
||||
9b389ed244bbb580112be07dbe23949a4764dffb
|
||||
-------END-TRANSACTION-3fX59xPj-------------------------------------------------
|
||||
|
||||
|
||||
</pre>
|
||||
|
||||
In this transaction, there are two inputs, one of 150 BTC and the other of 12 BTC. This transaction combines 162 BTC to create two outputs, one of 160 BTC, one 1.9995 BTC, and a tx fee of 0.0005. In this TxDP, both inputs have been signed, and thus could broadcast immediately.
|
||||
|
||||
@ -99,5 +98,3 @@ A party receiving this TxDP can simply add their signature to the appropriate _T
|
||||
|
||||
This proposal has been implemented and tested in the ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction), and will eventually use it for multi-signature transcations. The source code for this implementation be found in the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py Armory Github project]. Specifically, the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4704 PyTxDistProposal class] implements all features of BIP 0010. It contains reference code for both
|
||||
[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L5095 serializing a TxDP] and [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L5143 unserializing a TxDP].
|
||||
|
||||
[[Category:BIP|D]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 11
|
||||
Title: M-of-N Standard Transactions
|
||||
@ -58,5 +56,3 @@ https://github.com/gavinandresen/bitcoin-git/tree/op_eval
|
||||
== Post History ==
|
||||
|
||||
* [https://bitcointalk.org/index.php?topic=46538 OP_EVAL proposal]
|
||||
|
||||
[[Category:BIP|C]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 12
|
||||
Title: OP_EVAL
|
||||
@ -83,5 +81,3 @@ https://bitcointalk.org/index.php?topic=46538
|
||||
"Bitcoin Address 01" BIP
|
||||
|
||||
M-of-N Multisignature Transactions BIP 11
|
||||
|
||||
[[Category:BIP|W]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 13
|
||||
Title: Address Format for pay-to-script-hash
|
||||
@ -8,6 +6,7 @@
|
||||
Type: Standards Track
|
||||
Created: 18-10-2011
|
||||
</pre>
|
||||
|
||||
==Abstract==
|
||||
|
||||
This BIP describes a new type of Bitcoin address to support arbitrarily complex transactions. Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin.
|
||||
@ -52,9 +51,6 @@ See base58.cpp1/base58.h at https://github.com/bitcoin/bitcoin/src
|
||||
|
||||
==See Also==
|
||||
|
||||
* [[BIP 0012|BIP 12: OP_EVAL, the original P2SH design]]
|
||||
* [[BIP 0016|BIP 16: Pay to Script Hash (aka "/P2SH/")]]
|
||||
* [[BIP 0017|BIP 17: OP_CHECKHASHVERIFY, another P2SH design]]
|
||||
|
||||
[[Category:BIP|D]]
|
||||
[[Category:Security]]
|
||||
* [[bip-0012.mediawiki|BIP 12: OP_EVAL, the original P2SH design]]
|
||||
* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]]
|
||||
* [[bip-0017.mediawiki|BIP 17: OP_CHECKHASHVERIFY, another P2SH design]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 14
|
||||
Title: BIP Protocol Version and User Agent
|
||||
@ -89,5 +87,3 @@ They should not be misused beyond what is specified in this section.
|
||||
== Timeline ==
|
||||
|
||||
When this document was published, the bitcoin protocol and Satoshi client versions were currently at 0.5 and undergoing changes. In order to minimise disruption and allow the undergoing changes to be completed, the next protocol version at 0.6 became peeled from the client version (also at 0.6). As of that time (January 2012), protocol and implementation version numbers are distinct from each other.
|
||||
|
||||
[[Category:BIP|C]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 15
|
||||
Title: BIP Aliases
|
||||
@ -9,7 +7,7 @@
|
||||
Created: 10-12-2011
|
||||
</pre>
|
||||
|
||||
[[BIP 0070]] (payment protocol) may be seen as the alternative to Aliases.
|
||||
[[bip-0070.mediawiki|BIP 0070]] (payment protocol) may be seen as the alternative to Aliases.
|
||||
|
||||
Using vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist.
|
||||
|
||||
@ -97,7 +95,7 @@ It also scales reasonably- anybody wishing to run a naming service can attach a
|
||||
|
||||
A naive implementation is provided below as an example.
|
||||
|
||||
<source lang="cpp">
|
||||
<pre>
|
||||
// resolv.h
|
||||
#ifndef NOMRESOLV_H__
|
||||
#define NOMRESOLV_H__
|
||||
@ -159,9 +157,9 @@ private:
|
||||
};
|
||||
|
||||
#endif
|
||||
</source>
|
||||
</pre>
|
||||
|
||||
<source lang="cpp">
|
||||
<pre>
|
||||
// resolv.cpp
|
||||
#include "resolv.h"
|
||||
|
||||
@ -327,7 +325,7 @@ Value rpc_send(const Array& params, bool fHelp)
|
||||
}
|
||||
|
||||
...
|
||||
</source>
|
||||
</pre>
|
||||
|
||||
=== IP Transactions ===
|
||||
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 16
|
||||
Title: Pay to Script Hash
|
||||
@ -110,6 +108,4 @@ https://gist.github.com/gavinandresen/3966071
|
||||
* [[bip-0016/qa.mediawiki|Quality Assurance test checklist]]
|
||||
|
||||
== References ==
|
||||
<references/>
|
||||
|
||||
[[Category:BIP|D]]
|
||||
<references>
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 17
|
||||
Title: OP_CHECKHASHVERIFY (CHV)
|
||||
@ -98,8 +96,6 @@ OP_NOP2 is used, so existing OP_EVAL (BIP 12) transactions in the block chain ca
|
||||
|
||||
==See Also==
|
||||
|
||||
* The [[BIP 0013|Address format for Pay to Script Hash BIP]]
|
||||
* [[BIP 0011|M-of-N Multisignature Transactions (BIP 11)]]
|
||||
* The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]]
|
||||
* [[bip-0011.mediawiki|M-of-N Multisignature Transactions (BIP 11)]]
|
||||
* Example BIP 17 transaction chain: [http://blockexplorer.com/tx/b8fd633e7713a43d5ac87266adc78444669b987a56b3a65fb92d58c2c4b0e84d a] [http://blockexplorer.com/tx/eb3b82c0884e3efa6d8b0be55b4915eb20be124c9766245bcc7f34fdac32bccb b] [http://blockexplorer.com/tx/055707ce7fea7b9776fdc70413f65ceec413d46344424ab01acd5138767db137 c] [http://blockexplorer.com/tx/6d36bc17e947ce00bb6f12f8e7a56a1585c5a36188ffa2b05e10b4743273a74b d]
|
||||
|
||||
[[Category:BIP|D]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 18
|
||||
Title: hashScriptCheck
|
||||
@ -123,8 +121,6 @@ https://github.com/gavinandresen/bitcoin-git/tree/pay_to_script_hash
|
||||
|
||||
==See Also==
|
||||
|
||||
* The [[BIP 0013|Address format for Pay to Script Hash BIP]]
|
||||
* [[BIP 16|BIP 16 - Pay to Script Hash (aka "/P2SH/")]]
|
||||
* M-of-N Multisignature Transactions [[BIP 0011|BIP 11]]
|
||||
|
||||
[[Category:BIP]]
|
||||
* The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]]
|
||||
* [[bip-0016.mediawiki|BIP 16 - Pay to Script Hash (aka "/P2SH/")]]
|
||||
* M-of-N Multisignature Transactions [[bip-0011.mediawiki|BIP 11]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 19
|
||||
Title: M-of-N Standard Transactions (Low SigOp)
|
||||
@ -60,12 +58,10 @@ scriptSig:
|
||||
==Rationale==
|
||||
|
||||
OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases.
|
||||
This is already specified in [[BIP 0011]].
|
||||
This is already specified in [[bip-0011.mediawiki|BIP 0011]].
|
||||
However, each OP_CHECKMULTISIG counts toward the block limit as 20 sigops, which only allows 1000 total multisig transactions in a block.
|
||||
Using OP_CHECKSIG only counts as 1 per signature, so can scale better.
|
||||
|
||||
==Implementation==
|
||||
|
||||
All used operations are already supported by old clients and miners as a non-standard transaction type.
|
||||
|
||||
[[Category:BIP|C]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 20
|
||||
Title: URI Scheme
|
||||
@ -57,7 +55,7 @@ Graphical bitcoin clients SHOULD register themselves as the handler for the "bit
|
||||
==== Transfer amount/size ====
|
||||
|
||||
If an amount is provided, it may be specified either in decimal or, when prefixed with a single "x" character, hexadecimal.
|
||||
The number SHOULD be followed by "X" <digits> to signify an exponent to the base multiplier.
|
||||
The number SHOULD be followed by "X" <digits> to signify an exponent to the base multiplier.
|
||||
Thus, "X8" multiplies your number by 100,000,000.
|
||||
For decimal values, this means the standard BTC unit.
|
||||
For hexadecimal values, this means ᵇTBC units (which are equivalent to 42.94967296 BTC).
|
||||
@ -94,9 +92,11 @@ Make it possible for later generations to improve our work, to mend our errors,
|
||||
This section is non-normative and does not cover all possible syntax.
|
||||
Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax.
|
||||
|
||||
[foo] means optional, <bar> are placeholders
|
||||
[foo] means optional, <bar> are placeholders
|
||||
|
||||
<pre>
|
||||
bitcoin:<address>[;version=1.0][?amount=<amount>][?label=<label>][?message=<message>][?send=<private key>]
|
||||
</pre>
|
||||
|
||||
=== Examples ===
|
||||
|
||||
@ -129,15 +129,21 @@ Characters must be URI encoded properly.
|
||||
===Sending money via private key===
|
||||
To send a payment to someone else first construct a new keypair. You may want to use a [[mini private key format]], or you may also use a full private key for more security depending on the amount being sent and how long you expect to pass before a claim. Now create and publish a transaction with an output of the amount you wish to send. Use this script in that output:
|
||||
|
||||
<pre>
|
||||
<pubkey> OP_CHECKSIG
|
||||
</pre>
|
||||
|
||||
Construct an address from the public key. Encode the URI as below:
|
||||
|
||||
<pre>
|
||||
bitcoin:<address>?send=<base 58 encoded private key>
|
||||
</pre>
|
||||
|
||||
You may optionally include amount or message fields as well. In a wallet to claim money sent this way search for an incoming transaction with the output script form above, where <address> matches the public key in the script. When you find the transaction create a claim transaction with an input script of this form:
|
||||
You may optionally include amount or message fields as well. In a wallet to claim money sent this way search for an incoming transaction with the output script form above, where <address> matches the public key in the script. When you find the transaction create a claim transaction with an input script of this form:
|
||||
|
||||
<pre>
|
||||
<sig>
|
||||
</pre>
|
||||
|
||||
This claims the money you were sent. Until your claim transaction has confirmed the sender may take their money back.
|
||||
|
||||
@ -147,6 +153,7 @@ This claims the money you were sent. Until your claim transaction has confirmed
|
||||
|
||||
=== Parsing amount ===
|
||||
==== ECMAScript ====
|
||||
<pre>
|
||||
reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;
|
||||
function parseAmount(txt) {
|
||||
var m = txt.match(reAmount);
|
||||
@ -163,8 +170,10 @@ This claims the money you were sent. Until your claim transaction has confirmed
|
||||
(m[4] ? Math.pow(10, m[4]) : 1e8)
|
||||
);
|
||||
}
|
||||
</pre>
|
||||
|
||||
==== Python ====
|
||||
<pre>
|
||||
m = re.match(r'^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$', amount, re.IGNORECASE)
|
||||
if m.group(5):
|
||||
amount = float(int(m.group(5), 16))
|
||||
@ -180,8 +189,10 @@ This claims the money you were sent. Until your claim transaction has confirmed
|
||||
amount *= 10 ** int(m.group(4))
|
||||
else:
|
||||
amount *= 100000000
|
||||
</pre>
|
||||
|
||||
==== C# ====
|
||||
<pre>
|
||||
Regex amountExpression = new Regex(@"^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$", RegexOptions.IgnoreCase);
|
||||
Match match = amountExpression.Match(value);
|
||||
if (match.Success)
|
||||
@ -206,7 +217,4 @@ This claims the money you were sent. Until your claim transaction has confirmed
|
||||
Amount = (long)(decimal.Parse(match.Groups[2].Value) * decimalExponent);
|
||||
}
|
||||
}
|
||||
|
||||
[[Category:Developer]]
|
||||
[[Category:Technical]]
|
||||
[[Category:BIP|D]]
|
||||
</pre>
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 21
|
||||
Title: URI Scheme
|
||||
@ -10,7 +8,7 @@
|
||||
Created: 29-01-2012
|
||||
</pre>
|
||||
|
||||
This BIP is a modification of an earlier [[BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed.
|
||||
This BIP is a modification of an earlier [[bip-0020.mediawiki|BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed.
|
||||
|
||||
==Abstract==
|
||||
This BIP proposes a URI scheme for making Bitcoin payments.
|
||||
@ -82,9 +80,9 @@ As this BIP is written, several clients already implement a bitcoin: URI scheme
|
||||
=== Simpler syntax ===
|
||||
|
||||
This section is non-normative and does not cover all possible syntax.
|
||||
Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax.
|
||||
Please see the BNF grammar above for the normative syntax.
|
||||
|
||||
[foo] means optional, <bar> are placeholders
|
||||
[foo] means optional, <bar> are placeholders
|
||||
|
||||
<nowiki>bitcoin:<address>[?amount=<amount>][?label=<label>][?message=<message>]</nowiki>
|
||||
|
||||
@ -112,8 +110,5 @@ Characters must be URI encoded properly.
|
||||
|
||||
== Reference Implementations ==
|
||||
=== 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-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858.
|
||||
|
||||
[[Category:Developer]]
|
||||
[[Category:Technical]]
|
||||
[[Category:BIP|D]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 22
|
||||
Title: getblocktemplate - Fundamentals
|
||||
@ -20,7 +18,7 @@ Instead of sending a simple block header for hashing, the entire block structure
|
||||
|
||||
A JSON-RPC method is defined, called "getblocktemplate".
|
||||
It accepts exactly one argument, which MUST be an Object of request parameters.
|
||||
If the request parameters include a "mode" key, that is used to explicitly select between the default "template" request or a [[BIP 0023#Block Proposal|"proposal"]].
|
||||
If the request parameters include a "mode" key, that is used to explicitly select between the default "template" request or a [[bip-0023.mediawiki#Block Proposal|"proposal"]].
|
||||
|
||||
Block template creation can be influenced by various parameters:
|
||||
{| class="wikitable"
|
||||
@ -28,7 +26,7 @@ Block template creation can be influenced by various parameters:
|
||||
|-
|
||||
! Key !! Required !! Type !! Description
|
||||
|-
|
||||
| capabilities || {{No}} || Array of Strings || SHOULD contain a list of the following, to indicate client-side support: [[#Optional: Long Polling|"longpoll"]], "coinbasetxn", "coinbasevalue", [[BIP 0023#Block Proposal|"proposal"]], [[BIP 0023#Logical Services|"serverlist"]], "workid", and any of the [[BIP 0023#Mutations|mutations]]
|
||||
| capabilities || {{No}} || Array of Strings || SHOULD contain a list of the following, to indicate client-side support: [[#Optional: Long Polling|"longpoll"]], "coinbasetxn", "coinbasevalue", [[bip-0023.mediawiki#Block Proposal|"proposal"]], [[bip-0023.mediawiki#Logical Services|"serverlist"]], "workid", and any of the [[bip-0023.mediawiki#Mutations|mutations]]
|
||||
|-
|
||||
| mode || {{No}} || String || MUST be "template" or omitted
|
||||
|}
|
||||
@ -53,9 +51,9 @@ getblocktemplate MUST return a JSON Object containing the following keys:
|
||||
|-
|
||||
| transactions || {{Yes|Should}} || Array of Objects || Objects containing [[#Transactions Object Format|information for Bitcoin transactions]] (excluding coinbase)
|
||||
|-
|
||||
| version || {{Yes}} || Number || always 1 or 2 (at least for bitcoin) - clients MUST understand the implications of the version they use (eg, comply with [[BIP 0034]] for version 2)
|
||||
| version || {{Yes}} || Number || always 1 or 2 (at least for bitcoin) - clients MUST understand the implications of the version they use (eg, comply with [[bip-0034.mediawiki|BIP 0034]] for version 2)
|
||||
|-
|
||||
| coinbaseaux || {{No}} || Object || data that SHOULD be included in the coinbase's scriptSig content. Only the values (hexadecimal byte-for-byte) in this Object should be included, not the keys. This does not include the block height, which is required to be included in the scriptSig by [[BIP 0034]]. It is advisable to encode values inside "PUSH" opcodes, so as to not inadvertantly expend SIGOPs (which are counted toward limits, despite not being executed).
|
||||
| coinbaseaux || {{No}} || Object || data that SHOULD be included in the coinbase's scriptSig content. Only the values (hexadecimal byte-for-byte) in this Object should be included, not the keys. This does not include the block height, which is required to be included in the scriptSig by [[bip-0034.mediawiki|BIP 0034]]. It is advisable to encode values inside "PUSH" opcodes, so as to not inadvertantly expend SIGOPs (which are counted toward limits, despite not being executed).
|
||||
|-
|
||||
| coinbasetxn || {{Patch|this or ↓}} || Object || [[#Transactions Object Format|information for coinbase transaction]]
|
||||
|-
|
||||
@ -230,7 +228,7 @@ What is the purpose of "workid"?
|
||||
* If servers allow all mutations, it may be hard to identify which job it is based on. While it may be possible to verify the submission by its content, it is much easier to compare it to the job issued. It is very easy for the miner to keep track of this. Therefore, using a "workid" is a very cheap solution to enable more mutations.
|
||||
|
||||
Why should "sigops" be provided for transactions?
|
||||
* Due to the [[BIP 0016]] changes regarding rules on block sigops, it is impossible to count sigops from the transactions themselves (the sigops in the scriptCheck must also be included in the count).
|
||||
* Due to the [[bip-0016.mediawiki|BIP 0016]] changes regarding rules on block sigops, it is impossible to count sigops from the transactions themselves (the sigops in the scriptCheck must also be included in the count).
|
||||
|
||||
==Reference Implementation==
|
||||
|
||||
@ -239,6 +237,4 @@ Why should "sigops" be provided for transactions?
|
||||
* [https://github.com/bitcoin/bitcoin/pull/936/files bitcoind (minimal server)]
|
||||
|
||||
==See Also==
|
||||
* [[BIP 0023|BIP 23: getblocktemplate - Pooled Mining]]
|
||||
|
||||
[[Category:BIP|D]]
|
||||
* [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 23
|
||||
Title: getblocktemplate - Pooled Mining
|
||||
@ -22,8 +20,8 @@ Note that all sections of this specification are optional extensions on top of [
|
||||
Something can be said to have BIP 23 Level 1 support if it implements at least:
|
||||
* [http://www.ietf.org/rfc/rfc1945.txt RFC 1945]
|
||||
* [http://json-rpc.org/wiki/specification JSON-RPC 1.0]
|
||||
* [[BIP 0022|BIP 22 (non-optional sections)]]
|
||||
* [[BIP 0022#Optional: Long Polling|BIP 22 Long Polling]]
|
||||
* [[bip-0022.mediawiki|BIP 22 (non-optional sections)]]
|
||||
* [[bip-0022.mediawiki#Optional: Long Polling|BIP 22 Long Polling]]
|
||||
* [[#Basic Pool Extensions|BIP 23 Basic Pool Extensions]]
|
||||
* [[#Mutations|BIP 23 Mutation "coinbase/append"]]
|
||||
* [[#Submission Abbreviation|BIP 23 Submission Abbreviation "submit/coinbase"]]
|
||||
@ -83,7 +81,7 @@ This is accomplished by calling getblocktemplate with two keys:
|
||||
The block data MUST be validated and checked against the server's usual acceptance rules (excluding the check for a valid proof-of-work).
|
||||
If it is found to be in violation of any of these rules, the server MUST return one of the following:
|
||||
* Null if it is acceptable as-is, with the same workid (if any) as provided. Note that this SHOULD NOT invalidate the old template's claim to the same workid.
|
||||
* A String giving the reason for the rejection (see [[BIP 0022#Appendix: Example Rejection Reasons|example rejection reasons]]).
|
||||
* A String giving the reason for the rejection (see [[bip-0022.mediawiki#appendix-example-rejection-reasons|example rejection reasons]]).
|
||||
* A "delta" block template (with changes needed); in this case, any missing keys are assumed to default to those in the proposed block or, if not applicable, the original block template it was based on. This template MAY also include a "reject-reason" key with a String of the reason for rejection.
|
||||
|
||||
It is RECOMMENDED that servers which merely need to track the proposed block for later share/* submissions, return a simple Object of the form:
|
||||
@ -295,6 +293,4 @@ What is the purpose of the "hash" transaction list format?
|
||||
* [https://github.com/bitcoin/bitcoin/pull/936/files bitcoind]
|
||||
|
||||
==See Also==
|
||||
* [[BIP 0022|BIP 22: getblocktemplate - Fundamentals]]
|
||||
|
||||
[[Category:BIP|D]]
|
||||
* [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 30
|
||||
Title: Duplicate transactions
|
||||
@ -47,7 +45,3 @@ There have been additional commits to refine the implementation of this BIP.
|
||||
|
||||
==Acknowledgements==
|
||||
Thanks to Russell O'Connor for finding and demonstrating this problem, and helping test the patch.
|
||||
|
||||
[[Category:Developer]]
|
||||
[[Category:Technical]]
|
||||
[[Category:BIP|D]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 31
|
||||
Title: Pong message
|
||||
@ -38,7 +36,3 @@ Clients must opt-in to the new feature by advertising a protocol version > 60000
|
||||
==Implementation==
|
||||
|
||||
https://github.com/bitcoin/bitcoin/pull/932/files
|
||||
|
||||
[[Category:Developer]]
|
||||
[[Category:Technical]]
|
||||
[[Category:BIP|D]]
|
||||
|
||||
@ -1,10 +1,7 @@
|
||||
{{bip}}
|
||||
|
||||
|
||||
RECENT CHANGES:
|
||||
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)
|
||||
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)
|
||||
* [25 May 2013] Added test vectors
|
||||
* (16 Apr 2013) Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)
|
||||
* (30 Apr 2013) Switched from multiplication by I_L to addition of I_L (faster, easier implementation)
|
||||
* (25 May 2013) Added test vectors
|
||||
|
||||
<pre>
|
||||
BIP: 32
|
||||
@ -17,7 +14,7 @@ RECENT CHANGES:
|
||||
|
||||
==Abstract==
|
||||
|
||||
This document describes [[Deterministic Wallet|hierarchical determinstic wallets]] (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.
|
||||
This document describes hierarchical determinstic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.
|
||||
|
||||
The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients. Although the wallets described here have many features, not all are required by supporting clients.
|
||||
|
||||
@ -127,7 +124,7 @@ The total number of possible extended keypairs is almost 2^512, but the produced
|
||||
* Use I<sub>L</sub> as master secret key, and I<sub>R</sub> as master chain code.
|
||||
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.
|
||||
|
||||
[[File:BIP32-derivation.png]]
|
||||
<img src=bip-0032/derivation.png></img>
|
||||
|
||||
==Specification: Wallet structure==
|
||||
|
||||
|
||||
BIN
bip-0032/derivation.png
Normal file
BIN
bip-0032/derivation.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 162 KiB |
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 33
|
||||
Title: Stratized Nodes
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 34
|
||||
Title: Block v2, Height in Coinbase
|
||||
@ -32,7 +30,3 @@ All older clients are compatible with this change. Users and merchants should no
|
||||
==Implementation==
|
||||
|
||||
https://github.com/bitcoin/bitcoin/pull/1526
|
||||
|
||||
[[Category:Developer]]
|
||||
[[Category:Technical]]
|
||||
[[Category:BIP|D]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 35
|
||||
Title: mempool message
|
||||
@ -38,7 +36,3 @@ Older clients remain 100% compatible and interoperable after this change.
|
||||
==Implementation==
|
||||
|
||||
https://github.com/bitcoin/bitcoin/pull/1641
|
||||
|
||||
[[Category:Developer]]
|
||||
[[Category:Technical]]
|
||||
[[Category:BIP|D]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 36
|
||||
Title: Custom Services
|
||||
@ -153,7 +151,3 @@ Finally, this BIP defines both explicitly and implicitly some useful common nome
|
||||
==Copyright==
|
||||
|
||||
This document is placed in the public domain.
|
||||
|
||||
[[Category:Developer]]
|
||||
[[Category:Technical]]
|
||||
[[Category:BIP|D]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 37
|
||||
Title: Connection Bloom filtering
|
||||
@ -171,7 +169,3 @@ The number of hash functions required is given by <code>S * 8 / N * log(2)</code
|
||||
==Copyright==
|
||||
|
||||
This document is placed in the public domain.
|
||||
|
||||
[[Category:Developer]]
|
||||
[[Category:Technical]]
|
||||
[[Category:BIP|D]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: BIP-0039
|
||||
Title: Mnemonic code for generating deterministic keys
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 50
|
||||
Title: March 2013 Chain Fork Post-Mortem
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 60
|
||||
Title: Fixed Length "version" Message (Relay-Transactions Field)
|
||||
@ -28,7 +26,7 @@ Another property of fixed-length field messages is the ability to pass stream op
|
||||
==Specification==
|
||||
=== version ===
|
||||
|
||||
When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.
|
||||
When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.
|
||||
|
||||
Payload:
|
||||
|
||||
@ -49,11 +47,11 @@ Payload:
|
||||
|-
|
||||
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
|
||||
|-
|
||||
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)
|
||||
| ? || user_agent || var_str || [[bip-0014.mediawiki|User Agent]] (0x00 if string is 0 bytes long)
|
||||
|-
|
||||
| 4 || start_height || int32_t || The last block received by the emitting node
|
||||
|-
|
||||
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001
|
||||
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[bip-0037.mediawiki|BIP 0037]], since version >= 70001
|
||||
|}
|
||||
|
||||
A "verack" packet shall be sent if the version packet was accepted.
|
||||
@ -90,7 +88,3 @@ Additionally the protocol version is increased from 70001 to 70002.
|
||||
==Copyright==
|
||||
|
||||
This document is placed in the public domain.
|
||||
|
||||
[[Category:Developer]]
|
||||
[[Category:Technical]]
|
||||
[[Category:BIP|D]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 70
|
||||
Title: Payment Protocol
|
||||
@ -45,7 +43,7 @@ and PaymentACK, and begins with the customer somehow indicating that
|
||||
they are ready to pay and the merchant's server responding with a
|
||||
PaymentRequest message:
|
||||
|
||||
[[Image:Protocol_Sequence.png]]
|
||||
<img src=bip-0070/Protocol_Sequence.png></img>
|
||||
|
||||
==Messages==
|
||||
|
||||
@ -259,9 +257,9 @@ other extensions.
|
||||
|
||||
==References==
|
||||
|
||||
[[BIP 0071]] : Payment Protocol mime types
|
||||
[[bip-0071.mediawiki|BIP 0071]] : Payment Protocol mime types
|
||||
|
||||
[[BIP 0072]] : Payment Protocol bitcoin: URI extensions
|
||||
[[bip-0072.mediawiki|BIP 0072]] : Payment Protocol bitcoin: URI extensions
|
||||
|
||||
Public-Key Infrastructure (X.509) working group :
|
||||
http://datatracker.ietf.org/wg/pkix/charter/
|
||||
@ -282,5 +280,3 @@ ThomasV's "Signed Aliases" proposal : http://ecdsa.org/bitcoin_URIs.html
|
||||
|
||||
Homomorphic Payment Addresses and the Pay-to-Contract Protocol :
|
||||
http://arxiv.org/abs/1212.3257
|
||||
|
||||
[[Category:BIP]]
|
||||
|
||||
BIN
bip-0070/Protocol_Sequence.png
Normal file
BIN
bip-0070/Protocol_Sequence.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 71
|
||||
Title: Payment Protocol MIME types
|
||||
@ -46,5 +44,3 @@ following headers:
|
||||
Content-Type: application/bitcoin-paymentrequest
|
||||
Content-Transfer-Encoding: binary
|
||||
</pre>
|
||||
|
||||
[[Category:BIP]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 72
|
||||
Title: bitcoin: uri extensions for Payment Protocol
|
||||
@ -60,4 +58,3 @@ Non-backwards-compatible equivalent:
|
||||
<pre>
|
||||
bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe
|
||||
</pre>
|
||||
[[Category:BIP]]
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{{bip}}
|
||||
|
||||
<pre>
|
||||
BIP: 73
|
||||
Title: Use "Accept" header for response type negotiation with Payment Request URLs
|
||||
@ -11,7 +9,7 @@
|
||||
|
||||
==Abstract==
|
||||
|
||||
This BIP describes an enhancement to the payment protocol ([[BIP 0070|BIP 70]])
|
||||
This BIP describes an enhancement to the payment protocol ([[bip-0070.mediawiki|BIP 70]])
|
||||
that addresses the need for short URLs when scanning from QR codes. It
|
||||
generalizes the specification for the behavior of a payment request URL in a
|
||||
way that allows the client and server to negotiate the content of the
|
||||
@ -19,7 +17,7 @@ response using the HTTP Accept: header field. Specifically, the client
|
||||
can indicate to the server whether it prefers to receive a bitcoin URI or
|
||||
a payment request.
|
||||
|
||||
Implementation of this BIP does not require full payment request ([[BIP 0070|BIP 70]]) support.
|
||||
Implementation of this BIP does not require full payment request ([[bip-0070.mediawiki|BIP 70]]) support.
|
||||
|
||||
==Motivation==
|
||||
|
||||
@ -79,5 +77,4 @@ specified (note, this is a fairly minimal URI as it does not contain a
|
||||
label and the request URL is of moderate size). The second image is a QR
|
||||
code with only the payment request url specified.
|
||||
|
||||
[[File:BIP_0073a.png]] [[File:BIP_0073b.png]]
|
||||
[[Category:BIP]]
|
||||
<img src=bip-0073/a.png></img><img src=bip-0073/b.png></img>
|
||||
|
||||
BIN
bip-0073/a.png
Normal file
BIN
bip-0073/a.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 674 B |
BIN
bip-0073/b.png
Normal file
BIN
bip-0073/b.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 514 B |
Loading…
Reference in New Issue
Block a user