Bitcoin Wiki - User contributions [en]

User:Marcusaurelius

2011-01-15T12:57:17Z

Marcusaurelius:

Hi, i am '''marcusaurelius'''.

Calculated SHA-256 Hash:
7469e12af4003493ed5adf14c224a38194ab6a519cd18592
7e181103235f79c7

User:Marcusaurelius

2011-01-15T12:48:13Z

Marcusaurelius: Created page with "Hi, i am '''marcusaurelius'''."

Hi, i am '''marcusaurelius'''.

BIP 0020

2011-01-13T10:38:25Z

Marcusaurelius: /* Proposed specification */ the question mark and ampersands are not optional in the way the others are.

This is about creating a URI scheme for bitcoin.
Previous discussion in the forum http://www.bitcoin.org/smf/index.php?topic=55.0
x-btc specification at [[x-btc]]

==RFC 3986==
'''the following is taken from wikipedia'''

Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:

<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code>

The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").

The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''.

* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".

* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.

The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref>
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.
</ref><ref>
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
</ref><ref>
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]
"CGI implementors are encouraged to support the use of ';' in place of '&' "
</ref> or separated by an ampersand, for example:
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code>
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code>

The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.

==Proposed specification==

[] means optional, <> are placeholders

bitcoin:<address>[?][amount=<size>][&][label=<label>][&][message=<message>]

=== Query Keys ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: optional message that is shown to the user after scanning the QR code
*size: amount of base bitcoin units (uBTCents/TBCᵇ-- NOT full DecimalBitCoins/BTC nor TonalBitCoins/TBC; see below)

==== 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.
That is, "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).
If exponent is omitted, implementations SHOULD assume X8 for decimal numbers, and X4 for hexadecimal numbers.
I.e. amount=50.00 is treated as 50 BTC, and amount=x40 is treated as 40 TBC.
When specifying bitcoin base units, "X0" SHOULD be used.

=== Examples ===

Just the address:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo

Address with name:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?label=Luke-Jr

Request to send 20.30 BTC to Luke-Jr:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=20.3&label=Luke-Jr

Request to send 400 TBC to Luke:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=x400

Request to send 4000 TBC to Luke:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=x4X7

Request to send 5 uBTC:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=500X0

Request to send 50 BTC with message:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=5X9&label=Luke-Jr&message=Donation%20for%20project%20xyz

Characters must be URI encoded properly.

=== BNF syntax ===

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = FIXME :)
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam
amountparam = "amount=" amount
amount = amountdecimal | amounthex
amountdecimal = digits [ "X" digits ]
amounthex = "x" hexdigits [ "X" hexdigits ]
labelparam = "label=" *uchar
messageparam = "label=" *uchar

=== Parsing amount ===
==== ECMAScript ====
reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;
function parseAmount(txt) {
var m = txt.match(reAmount);
return m[5] ? (
(
parseInt(m[5], 16) +
(m[7] ? (parseInt(m[7], 16) * Math.pow(16, -(m[7].length))) : 0)
) * (
m[9] ? Math.pow(16, parseInt(m[9], 16)) : 0x10000
)
) : (
m[2]
*
(m[4] ? Math.pow(10, m[4]) : 1e8)
);
}

==Requirements==

===Payment identifiers, not person identifiers===
in my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. so the URIs should represent first and foremost payments. if it represents something else, this needs to be specified. Thus
<code>
bitcoin:13guMzcGPvdD3qjQvCoNc1w5XAgJ638KaQ
</code>
represent a '''payment''' to me using my bitcoin adress, not my bitcoin adress itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the adress filled in. you then need to add an amount and confirm the payment.
If your application is smart, it will also have a button "just store the adress". But the point i am trying to make, is that the default use of the URI should be for payment, nor for exchanging adresses.

===Accessibility===
'''imported from the forum:''' I like the simplicity of bitcoin:xxxxxxxxxxxxx plus very much approve of its accessibility. Should someone from the outside happen to see such a uri, the protocol name already gives a description. A quick google search should then do the rest. x-btc sounds much more cryptic, the chance that s/1 gooogles that out of curiosity are much slimmer. Also, very likely, what s/he will find are mostly technical specifications. Not a good introduction to bitcoin.

for the same reason i am for using '&' as a delimiter for key-value-pairs. people know it from urls. make it easy for people to understand what is going on.

===Keep it simple===
don't explicitly write down information that can be inferred. don't mark the address as an address. if there is no address, this does lose much of its utility. we could, however, specify 'address' as a reserved word, so that <code>
bitcoin:address?amount=50
</code>
would initiate a transaction with the amount filled in, but with a blank address. I am not convinced that there is a use case, though.

===Use-cases===
before the URI scheme is finalised one should think long and hard about use-cases. in what circumstances will who use this for what?
* an online shop has a 'buy this'-link, which uses the URI scheme.
**PROBLEM: click on the link opens the application. how does the merchant notice this.
***POSSIBLE SOLUTION: javascript can detect the click.
***POSSIBLE SOLUTION: the checkout site checks its bitcoin account for payment via httprequest
**PROBLEM: the time problem (~10minutes) is very apparent here. nobody wants to wait 10minutes for the transaction to be confirmed.
* a person only has an online client, no actual application
**PROBLEM: how to redirect the URI, so that the online client gets a notice?

===Backwards compatibility===
we want URIs generated in 2011 to still work in 2036. think about extensibility. of course we can make only educated guesses (and nothing more!) about the future, but don't act as if there is none. this should be the best we can do, but it should not be seen as forever set in stone. make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now. Version incompatibility is the easiest thing to drive users crazy: "i now upgraded to this shiny new version. what? it doesn't support the old format? AAAAAAARRRGH!"

==References==
<references/>

BIP 0020

2011-01-10T19:24:31Z

Marcusaurelius: /* use-cases */ there was half a sentence missing. weird.

This is about creating a URI scheme for bitcoin.
Previous discussion in the forum http://www.bitcoin.org/smf/index.php?topic=55.0
x-btc specification at [[x-btc]]

==RFC 3986==
'''the following is taken from wikipedia'''

Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:

<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code>

The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").

The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''.

* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".

* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.

The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref>
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.
</ref><ref>
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
</ref><ref>
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]
"CGI implementors are encouraged to support the use of ';' in place of '&' "
</ref> or separated by an ampersand, for example:
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code>
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code>

The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.

==tcatm==

I propose a scheme like this:

() means optional, $* are placeholders

<pre>
bitcoin:($label@)$address(?$query)(#$message)
</pre>

=== Variables ===

<pre>
label: Label for that address (e.g. name of receiver)
address: bitcoin address
query: pairs of key=value seperated by &
message: optional message that is shown to the user after scanning the QR code
</pre>

=== Query keys ===
<pre>
amount: amount of BTC

</pre>
=== Examples ===

Just the address:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Address with name:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Request to send 20.30 BTC to me:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30
</pre>

Request to send 50 BTC with message:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=50#Payment%20for%20product%20xyz
</pre>

Characters must be URI encoded.

=== Criticism ===
* Not compliant with URI specification.
* Biased toward '''only''' decimal BitCoins
** Not future-proof, since the DecimalBitCoin unit (BTC) will be too large for regular trading should bitcoin ever gain large-scale adoption.

==tcatm, modified by LukeJr==

I propose a scheme like this:

[] means optional, <> are placeholders

bitcoin:<address>?amount=<size>[&label=<label>][&message=<message>]

=== Variables ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: optional message that is shown to the user after scanning the QR code
*size: amount of base bitcoin units (uBTCents/TBCᵇ-- NOT full DecimalBitCoins/BTC); this number can be prefixed with the letter "x" to signify a hexadecimal number; it can be appended with "X" <digits> to signify an exponent to the base multiplier (that is, 'X8' moves your number 8 positional places to the left-- if specifying decimal units (without an "x" prefix), this means the standard BTC unit; if specifying hexadecimal units (with an "x" prefix), this means ᵇTBC units)

=== Examples ===

Just the address:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo

Address with name:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?label=Luke-Jr

Request to send 20.30 BTC to Luke-Jr:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=20.3X8&label=Luke-Jr

Request to send 400 TBC to Luke:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=x400X4

Request to send 5 uBTC:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=500

Request to send 50 BTC with message:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=5X9&label=Luke-Jr&message=Donation%20for%20project%20xyz

Characters must be URI encoded properly.

=== BNF syntax ===

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = FIXME :)
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam
amountparam = "amount=" amount
amount = amountdecimal | amounthex
amountdecimal = digits [ "X" digits ]
amounthex = "x" hexdigits [ "X" hexdigits ]
labelparam = "label=" *uchar
messageparam = "label=" *uchar

=== Parsing Amount ===
==== ECMAScript ====
reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;
function parseAmount(txt) {
var m = txt.match(reAmount);
return m[5] ? (
(
parseInt(m[5], 16) +
(m[7] ? (parseInt(m[7], 16) * Math.pow(16, -(m[7].length))) : 0)
) * (
m[9] ? Math.pow(16, parseInt(m[9], 16)) : 1
)
) : (
m[2]
*
(m[4] ? Math.pow(10, m[4]) : 1)
);
}

=== Criticism ===

==marcusaurelius==

===payment identifiers, not person identifiers===
in my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. so the URIs should represent first and foremost payments. if it represents something else, this needs to be specified. Thus
<code>
bitcoin:13guMzcGPvdD3qjQvCoNc1w5XAgJ638KaQ
</code>
represent a '''payment''' to me using my bitcoin adress, not my bitcoin adress itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the adress filled in. you then need to add an amount and confirm the payment.
If your application is smart, it will also have a button "just store the adress". But the point i am trying to make, is that the default use of the URI should be for payment, nor for exchanging adresses.

===accessibility===
'''imported from the forum:''' I like the simplicity of bitcoin:xxxxxxxxxxxxx plus very much approve of its accessibility. Should someone from the outside happen to see such a uri, the protocol name already gives a description. A quick google search should then do the rest. x-btc sounds much more cryptic, the chance that s/1 gooogles that out of curiosity are much slimmer. Also, very likely, what s/he will find are mostly technical specifications. Not a good introduction to bitcoin.

for the same reason i am for using '&' as a delimiter for key-value-pairs. people know it from urls. make it easy for people to understand what is going on.

===keep it simple===
don't explicitly write down information that can be inferred. don't mark the address as an address. if there is no address, this does lose much of its utility. we could, however, specify 'address' as a reserved word, so that <code>
bitcoin:address?amount=50
</code>
would initiate a transaction with the amount filled in, but with a blank address. I am not convinced that there is a use case, though.

===use-cases===
before the URI scheme is finalised one should think long and hard about use-cases. in what circumstances will who use this for what?
* an online shop has a 'buy this'-link, which uses the URI scheme.
**PROBLEM: click on the link opens the application. how does the merchant notice this.
***POSSIBLE SOLUTION: javascript can detect the click.
***POSSIBLE SOLUTION: the checkout site checks its bitcoin account for payment via httprequest
**PROBLEM: the time problem (~10minutes) is very apparent here. nobody wants to wait 10minutes for the transaction to be confirmed.
* a person only has an online client, no actual application
**PROBLEM: how to redirect the URI, so that the online client gets a notice?

===backwards-compatibility===
we want URIs generated in 2011 to still work in 2036. think about extensibility. of course we can make only educated guesses (and nothing more!) about the future, but don't act as if there is none. this should be the best we can do, but it should not be seen as forever set in stone. make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now. Version incompatibility is the easiest thing to drive users crazy: "i now upgraded to this shiny new version. what? it doesn't support the old format? AAAAAAARRRGH!"

==References==
<references/>

BIP 0020

2011-01-10T12:44:22Z

Marcusaurelius: /* use-cases */

This is about creating a URI scheme for bitcoin.
Previous discussion in the forum http://www.bitcoin.org/smf/index.php?topic=55.0
x-btc specification at http://pastebin.com/VsBbmXQx

==RFC 3986==
'''the following is taken from wikipedia'''

Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:

<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code>

The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").

The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''.

* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".

* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.

The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref>
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.
</ref><ref>
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
</ref><ref>
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]
"CGI implementors are encouraged to support the use of ';' in place of '&' "
</ref> or separated by an ampersand, for example:
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code>
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code>

The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.

==tcatm==

I propose a scheme like this:

() means optional, $* are placeholders

<pre>
bitcoin:($label@)$address(?$query)(#$message)
</pre>

=== Variables ===

<pre>
label: Label for that address (e.g. name of receiver)
address: bitcoin address
query: pairs of key=value seperated by &
message: optional message that is shown to the user after scanning the QR code
</pre>

=== Query keys ===
<pre>
amount: amount of BTC

</pre>
=== Examples ===

Just the address:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Address with name:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Request to send 20.30 BTC to me:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30
</pre>

Request to send 50 BTC with message:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=50#Payment%20for%20product%20xyz
</pre>

Characters must be URI encoded.

==tcatm, modified by LukeJr==

I propose a scheme like this:

[] means optional, <> are placeholders

bitcoin:<address>?amount=<size><unit>[&label=<label>][&message=<message>]

=== Variables ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: optional message that is shown to the user after scanning the QR code
*size: amount of $unit
*unit: BTC, [ᵗˢᵐᵇ]TBC[ᵗˢᵐᵇ], or null/omitted (which refers to the base unit)

=== Examples ===

Just the address:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt

Address with name:BTC
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?label=tcatm

Request to send 20.30 BTC to tcatm:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30BTC&label=tcatm

Request to send 400 TBC to Luke:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=400TBC

Request to send 5 uBTC:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=500

Request to send 50 BTC with message:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8qztaWWXt?amount=50BTC&label=tcatm&message=Payment%20for%20product%20xyz

Characters must be URI encoded properly.

=== BNF syntax ===

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = FIXME :)
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam
amountparam = "amount=" amount
amount = amountdecimal | amounthex | amounttonal
amountdecimal = digits btcunits
amounthex = "x" hexdigits bitcoinunit
amounttonal = tonaldigits tbcunits
bitcoinunit = btcunits | tbcunits
btcunits = "BTC" | "BTCents" | "uBTC" | "uBTCents"
tbcunits = tbcunitsunicode | tbcunitsascii | tbcunitsfull
tbcunitsunicode = "ᵇTBC" | "ᵐTBC" | "ˢTBC" | "ᵗTBC" | "TBC" | "TBCᵗ" | "TBCˢ" | "TBCᵐ" | "TBCᵇ"
tbcunitsascii = "bTBC" | "mTBC" | "sTBC" | "tTBC" | "TBC" | "TBCt" | "TBCs" | "TBCm" | "TBCb"
tbcunitsfull = "tran-TBC" | "song-TBC" | "tam-TBC" | "bong-TBC" | "mill-TBC" | "san-TBC" | "ton-TBC" | "TBC" | "TBC-ton" | "TBC-san" | "TBC-mill" | "TBC-bong"
labelparam = "label=" *uchar
messageparam = "label=" *uchar

==marcusaurelius==

===payment identifiers, not person identifiers===
in my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. so the URIs should represent first and foremost payments. if it represents something else, this needs to be specified. Thus
<code>
bitcoin:13guMzcGPvdD3qjQvCoNc1w5XAgJ638KaQ
</code>
represent a '''payment''' to me using my bitcoin adress, not my bitcoin adress itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the adress filled in. you then need to add an amount and confirm the payment.
If your application is smart, it will also have a button "just store the adress". But the point i am trying to make, is that the default use of the URI should be for payment, nor for exchanging adresses.

===accessibility===
'''imported from the forum:''' I like the simplicity of bitcoin:xxxxxxxxxxxxx plus very much approve of its accessibility. Should someone from the outside happen to see such a uri, the protocol name already gives a description. A quick google search should then do the rest. x-btc sounds much more cryptic, the chance that s/1 gooogles that out of curiosity are much slimmer. Also, very likely, what s/he will find are mostly technical specifications. Not a good introduction to bitcoin.

for the same reason i am for using '&' as a delimiter for key-value-pairs. people know it from urls. make it easy for people to understand what is going on.

===keep it simple===
don't explicitly write down information that can be inferred. don't mark the address as an address. if there is no address, this does lose much of its utility. we could, however, specify 'address' as a reserved word, so that <code>
bitcoin:address?amount=50
</code>
would initiate a transaction with the amount filled in, but with a blank address. I am not convinced that there is a use case, though.

===use-cases===
before the URI scheme is finalised one should think long and hard about use-cases. in what circumstances will who use this for what?
* an online shop has a 'buy this'-link, which uses the URI scheme.
**PROBLEM: click on the link opens the application. how does the merchant notice this.
***POSSIBLE SOLUTION: javascript can detect the click.
***POSSIBLE SOLUTION: the checkout site checks the httprequest
**PROBLEM: the time problem (~10minutes) is very apparent here. nobody wants to wait 10minutes for the transaction to be confirmed.
* a person only has an online client, no actual application
**PROBLEM: how to redirect the URI, so that the online client gets a notice?

===backwards-compatibility===
we want URIs generated in 2011 to still work in 2036. think about extensibility. of course we can make only educated guesses (and nothing more!) about the future, but don't act as if there is none. this should be the best we can do, but it should not be seen as forever set in stone. make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now. Version incompatibility is the easiest thing to drive users crazy: "i now upgraded to this shiny new version. what? it doesn't support the old format? AAAAAAARRRGH!"

==References==
<references/>

BIP 0020

2011-01-10T12:32:27Z

Marcusaurelius: /* marcusaurelius */

This is about creating a URI scheme for bitcoin.
Previous discussion in the forum http://www.bitcoin.org/smf/index.php?topic=55.0
x-btc specification at http://pastebin.com/VsBbmXQx

==RFC 3986==
'''the following is taken from wikipedia'''

Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:

<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code>

The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").

The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''.

* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".

* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.

The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref>
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.
</ref><ref>
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
</ref><ref>
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]
"CGI implementors are encouraged to support the use of ';' in place of '&' "
</ref> or separated by an ampersand, for example:
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code>
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code>

The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.

==tcatm==

I propose a scheme like this:

() means optional, $* are placeholders

<pre>
bitcoin:($label@)$address(?$query)(#$message)
</pre>

=== Variables ===

<pre>
label: Label for that address (e.g. name of receiver)
address: bitcoin address
query: pairs of key=value seperated by &
message: optional message that is shown to the user after scanning the QR code
</pre>

=== Query keys ===
<pre>
amount: amount of BTC

</pre>
=== Examples ===

Just the address:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Address with name:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Request to send 20.30 BTC to me:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30
</pre>

Request to send 50 BTC with message:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=50#Payment%20for%20product%20xyz
</pre>

Characters must be URI encoded.

==tcatm, modified by LukeJr==

I propose a scheme like this:

[] means optional, <> are placeholders

bitcoin:<address>?amount=<size><unit>[&label=<label>][&message=<message>]

=== Variables ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: optional message that is shown to the user after scanning the QR code
*size: amount of $unit
*unit: BTC, [ᵗˢᵐᵇ]TBC[ᵗˢᵐᵇ], or null/omitted (which refers to the base unit)

=== Examples ===

Just the address:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt

Address with name:BTC
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?label=tcatm

Request to send 20.30 BTC to tcatm:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30BTC&label=tcatm

Request to send 400 TBC to Luke:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=400TBC

Request to send 5 uBTC:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=500

Request to send 50 BTC with message:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8qztaWWXt?amount=50BTC&label=tcatm&message=Payment%20for%20product%20xyz

Characters must be URI encoded properly.

=== BNF syntax ===

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = FIXME :)
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam
amountparam = "amount=" amount
amount = amountdecimal | amounthex | amounttonal
amountdecimal = digits btcunits
amounthex = "x" hexdigits bitcoinunit
amounttonal = tonaldigits tbcunits
bitcoinunit = btcunits | tbcunits
btcunits = "BTC" | "BTCents" | "uBTC" | "uBTCents"
tbcunits = tbcunitsunicode | tbcunitsascii | tbcunitsfull
tbcunitsunicode = "ᵇTBC" | "ᵐTBC" | "ˢTBC" | "ᵗTBC" | "TBC" | "TBCᵗ" | "TBCˢ" | "TBCᵐ" | "TBCᵇ"
tbcunitsascii = "bTBC" | "mTBC" | "sTBC" | "tTBC" | "TBC" | "TBCt" | "TBCs" | "TBCm" | "TBCb"
tbcunitsfull = "tran-TBC" | "song-TBC" | "tam-TBC" | "bong-TBC" | "mill-TBC" | "san-TBC" | "ton-TBC" | "TBC" | "TBC-ton" | "TBC-san" | "TBC-mill" | "TBC-bong"
labelparam = "label=" *uchar
messageparam = "label=" *uchar

==marcusaurelius==

===payment identifiers, not person identifiers===
in my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. so the URIs should represent first and foremost payments. if it represents something else, this needs to be specified. Thus
<code>
bitcoin:13guMzcGPvdD3qjQvCoNc1w5XAgJ638KaQ
</code>
represent a '''payment''' to me using my bitcoin adress, not my bitcoin adress itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the adress filled in. you then need to add an amount and confirm the payment.
If your application is smart, it will also have a button "just store the adress". But the point i am trying to make, is that the default use of the URI should be for payment, nor for exchanging adresses.

===accessibility===
'''imported from the forum:''' I like the simplicity of bitcoin:xxxxxxxxxxxxx plus very much approve of its accessibility. Should someone from the outside happen to see such a uri, the protocol name already gives a description. A quick google search should then do the rest. x-btc sounds much more cryptic, the chance that s/1 gooogles that out of curiosity are much slimmer. Also, very likely, what s/he will find are mostly technical specifications. Not a good introduction to bitcoin.

for the same reason i am for using '&' as a delimiter for key-value-pairs. people know it from urls. make it easy for people to understand what is going on.

===keep it simple===
don't explicitly write down information that can be inferred. don't mark the address as an address. if there is no address, this does lose much of its utility. we could, however, specify 'address' as a reserved word, so that <code>
bitcoin:address?amount=50
</code>
would initiate a transaction with the amount filled in, but with a blank address. I am not convinced that there is a use case, though.

===use-cases===
before the URI scheme is finalised one should think long and hard about use-cases. in what circumstances will who use this for what?

===backwards-compatibility===
we want URIs generated in 2011 to still work in 2036. think about extensibility. of course we can make only educated guesses (and nothing more!) about the future, but don't act as if there is none. this should be the best we can do, but it should not be seen as forever set in stone. make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now. Version incompatibility is the easiest thing to drive users crazy: "i now upgraded to this shiny new version. what? it doesn't support the old format? AAAAAAARRRGH!"

==References==
<references/>

BIP 0020

2011-01-10T12:27:51Z

Marcusaurelius: /* marcusaurelius */

BIP 0020

2011-01-10T12:17:57Z

Marcusaurelius:

This is about creating a URI scheme for bitcoin.
Previous discussion in the forum http://www.bitcoin.org/smf/index.php?topic=55.0
x-btc specification at http://pastebin.com/VsBbmXQx

==RFC 3986==
'''the following is taken from wikipedia'''

Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:

<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code>

The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").

The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''.

* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".

* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.

The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref>
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.
</ref><ref>
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
</ref><ref>
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]
"CGI implementors are encouraged to support the use of ';' in place of '&' "
</ref> or separated by an ampersand, for example:
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code>
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code>

The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.

==tcatm==

I propose a scheme like this:

() means optional, $* are placeholders

<pre>
bitcoin:($label@)$address(?$query)(#$message)
</pre>

=== Variables ===

<pre>
label: Label for that address (e.g. name of receiver)
address: bitcoin address
query: pairs of key=value seperated by &
message: optional message that is shown to the user after scanning the QR code
</pre>

=== Query keys ===
<pre>
amount: amount of BTC

</pre>
=== Examples ===

Just the address:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Address with name:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Request to send 20.30 BTC to me:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30
</pre>

Request to send 50 BTC with message:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=50#Payment%20for%20product%20xyz
</pre>

Characters must be URI encoded.

==tcatm, modified by LukeJr==

I propose a scheme like this:

[] means optional, <> are placeholders

bitcoin:<address>?amount=<size><unit>[&label=<label>][&message=<message>]

=== Variables ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: optional message that is shown to the user after scanning the QR code
*size: amount of $unit
*unit: BTC, [ᵗˢᵐᵇ]TBC[ᵗˢᵐᵇ], or null/omitted (which refers to the base unit)

=== Examples ===

Just the address:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt

Address with name:BTC
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?label=tcatm

Request to send 20.30 BTC to tcatm:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30BTC&label=tcatm

Request to send 400 TBC to Luke:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=400TBC

Request to send 5 uBTC:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=500

Request to send 50 BTC with message:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8qztaWWXt?amount=50BTC&label=tcatm&message=Payment%20for%20product%20xyz

Characters must be URI encoded properly.

=== BNF syntax ===

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = FIXME :)
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam
amountparam = "amount=" amount
amount = amountdecimal | amounthex | amounttonal
amountdecimal = digits btcunits
amounthex = "x" hexdigits bitcoinunit
amounttonal = tonaldigits tbcunits
bitcoinunit = btcunits | tbcunits
btcunits = "BTC" | "BTCents" | "uBTC" | "uBTCents"
tbcunits = tbcunitsunicode | tbcunitsascii | tbcunitsfull
tbcunitsunicode = "ᵇTBC" | "ᵐTBC" | "ˢTBC" | "ᵗTBC" | "TBC" | "TBCᵗ" | "TBCˢ" | "TBCᵐ" | "TBCᵇ"
tbcunitsascii = "bTBC" | "mTBC" | "sTBC" | "tTBC" | "TBC" | "TBCt" | "TBCs" | "TBCm" | "TBCb"
tbcunitsfull = "tran-TBC" | "song-TBC" | "tam-TBC" | "bong-TBC" | "mill-TBC" | "san-TBC" | "ton-TBC" | "TBC" | "TBC-ton" | "TBC-san" | "TBC-mill" | "TBC-bong"
labelparam = "label=" *uchar
messageparam = "label=" *uchar

==marcusaurelius==

in my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. so the URIs should represent first and foremost payments. if it represents something else, this needs to be specified. Thus
<code>
bitcoin:13guMzcGPvdD3qjQvCoNc1w5XAgJ638KaQ
</code>
represent a '''payment''' to me using my bitcoin adress, not my bitcoin adress itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the adress filled in. you then need to add an amount and confirm the payment.
If your application is smart, it will also have a button "just store the adress". But the point i am trying to make, is that the default use of the URI should be for payment, nor for exchanging adresses.

==References==
<references/>

BIP 0020

2011-01-10T12:14:44Z

Marcusaurelius: /* marcusaurelius */

==RFC 3986==
'''the following is taken from wikipedia'''

Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:

<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code>

The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").

The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''.

* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".

* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.

The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref>
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.
</ref><ref>
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
</ref><ref>
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]
"CGI implementors are encouraged to support the use of ';' in place of '&' "
</ref> or separated by an ampersand, for example:
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code>
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code>

The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.

==tcatm==

I propose a scheme like this:

() means optional, $* are placeholders

<pre>
bitcoin:($label@)$address(?$query)(#$message)
</pre>

=== Variables ===

<pre>
label: Label for that address (e.g. name of receiver)
address: bitcoin address
query: pairs of key=value seperated by &
message: optional message that is shown to the user after scanning the QR code
</pre>

=== Query keys ===
<pre>
amount: amount of BTC

</pre>
=== Examples ===

Just the address:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Address with name:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Request to send 20.30 BTC to me:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30
</pre>

Request to send 50 BTC with message:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=50#Payment%20for%20product%20xyz
</pre>

Characters must be URI encoded.

==tcatm, modified by LukeJr==

I propose a scheme like this:

[] means optional, <> are placeholders

bitcoin:<address>?amount=<size><unit>[&label=<label>][&message=<message>]

=== Variables ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: optional message that is shown to the user after scanning the QR code
*size: amount of $unit
*unit: BTC, [ᵗˢᵐᵇ]TBC[ᵗˢᵐᵇ], or null/omitted (which refers to the base unit)

=== Examples ===

Just the address:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt

Address with name:BTC
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?label=tcatm

Request to send 20.30 BTC to tcatm:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30BTC&label=tcatm

Request to send 400 TBC to Luke:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=400TBC

Request to send 5 uBTC:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=500

Request to send 50 BTC with message:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8qztaWWXt?amount=50BTC&label=tcatm&message=Payment%20for%20product%20xyz

Characters must be URI encoded properly.

=== BNF syntax ===

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = FIXME :)
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam
amountparam = "amount=" amount
amount = amountdecimal | amounthex | amounttonal
amountdecimal = digits btcunits
amounthex = "x" hexdigits bitcoinunit
amounttonal = tonaldigits tbcunits
bitcoinunit = btcunits | tbcunits
btcunits = "BTC" | "BTCents" | "uBTC" | "uBTCents"
tbcunits = tbcunitsunicode | tbcunitsascii | tbcunitsfull
tbcunitsunicode = "ᵇTBC" | "ᵐTBC" | "ˢTBC" | "ᵗTBC" | "TBC" | "TBCᵗ" | "TBCˢ" | "TBCᵐ" | "TBCᵇ"
tbcunitsascii = "bTBC" | "mTBC" | "sTBC" | "tTBC" | "TBC" | "TBCt" | "TBCs" | "TBCm" | "TBCb"
tbcunitsfull = "tran-TBC" | "song-TBC" | "tam-TBC" | "bong-TBC" | "mill-TBC" | "san-TBC" | "ton-TBC" | "TBC" | "TBC-ton" | "TBC-san" | "TBC-mill" | "TBC-bong"
labelparam = "label=" *uchar
messageparam = "label=" *uchar

==marcusaurelius==

in my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. so the URIs should represent first and foremost payments. if it represents something else, this needs to be specified. Thus
<code>
bitcoin:13guMzcGPvdD3qjQvCoNc1w5XAgJ638KaQ
</code>
represent a '''payment''' to me using my bitcoin adress, not my bitcoin adress itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the adress filled in. you then need to add an amount and confirm the payment.
If your application is smart, it will also have a button "just store the adress". But the point i am trying to make, is that the default use of the URI should be for payment, nor for exchanging adresses.

==References==
<references/>

BIP 0020

2011-01-10T12:05:54Z

Marcusaurelius: /* marcusaurelius */

BIP 0020

2011-01-10T12:05:39Z

Marcusaurelius: /* marcusaurelius */

BIP 0020

2011-01-10T12:05:13Z

Marcusaurelius: /* RFC 3986 */

BIP 0020

2011-01-10T12:02:31Z

Marcusaurelius: rfc 3986

==RFC 3986==

[[Internet standard]] [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:

<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code>

The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").

The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''.

* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. [[domain name]] or [[IP address]]), and an optional [[TCP and UDP port|port number]] preceded by a colon ":".

* The '''path''' part is a sequence of segments (conceptually similar to [[Directory (file systems)|directories]], though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.

The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The [[query string]] syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref>
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.
</ref><ref>
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
</ref><ref>
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]
"CGI implementors are encouraged to support the use of ';' in place of '&' "
</ref> or separated by an ampersand, for example:
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code>
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code>

The '''[[Fragment identifier|fragment]]''' is an optional part separated from the front parts by a [[Number sign|hash]] ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an [[HTML]] document, the '''fragment''' is often an [[HTML#Attributes|<code>id</code> attribute]] of a specific element and [[web browser]]s will make sure this element is visible.

==tcatm==

I propose a scheme like this:

() means optional, $* are placeholders

<pre>
bitcoin:($label@)$address(?$query)(#$message)
</pre>

=== Variables ===

<pre>
label: Label for that address (e.g. name of receiver)
address: bitcoin address
query: pairs of key=value seperated by &
message: optional message that is shown to the user after scanning the QR code
</pre>

=== Query keys ===
<pre>
amount: amount of BTC

</pre>
=== Examples ===

Just the address:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Address with name:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Request to send 20.30 BTC to me:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30
</pre>

Request to send 50 BTC with message:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=50#Payment%20for%20product%20xyz
</pre>

Characters must be URI encoded.

==tcatm, modified by LukeJr==

I propose a scheme like this:

[] means optional, <> are placeholders

bitcoin:<address>?amount=<size><unit>[&label=<label>][&message=<message>]

=== Variables ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: optional message that is shown to the user after scanning the QR code
*size: amount of $unit
*unit: BTC, [ᵗˢᵐᵇ]TBC[ᵗˢᵐᵇ], or null/omitted (which refers to the base unit)

=== Examples ===

Just the address:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt

Address with name:BTC
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?label=tcatm

Request to send 20.30 BTC to tcatm:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30BTC&label=tcatm

Request to send 400 TBC to Luke:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=400TBC

Request to send 5 uBTC:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=500

Request to send 50 BTC with message:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8qztaWWXt?amount=50BTC&label=tcatm&message=Payment%20for%20product%20xyz

Characters must be URI encoded properly.

=== BNF syntax ===

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = FIXME :)
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam
amountparam = "amount=" amount
amount = amountdecimal | amounthex | amounttonal
amountdecimal = digits btcunits
amounthex = "x" hexdigits bitcoinunit
amounttonal = tonaldigits tbcunits
bitcoinunit = btcunits | tbcunits
btcunits = "BTC" | "BTCents" | "uBTC" | "uBTCents"
tbcunits = tbcunitsunicode | tbcunitsascii | tbcunitsfull
tbcunitsunicode = "ᵇTBC" | "ᵐTBC" | "ˢTBC" | "ᵗTBC" | "TBC" | "TBCᵗ" | "TBCˢ" | "TBCᵐ" | "TBCᵇ"
tbcunitsascii = "bTBC" | "mTBC" | "sTBC" | "tTBC" | "TBC" | "TBCt" | "TBCs" | "TBCm" | "TBCb"
tbcunitsfull = "tran-TBC" | "song-TBC" | "tam-TBC" | "bong-TBC" | "mill-TBC" | "san-TBC" | "ton-TBC" | "TBC" | "TBC-ton" | "TBC-san" | "TBC-mill" | "TBC-bong"
labelparam = "label=" *uchar
messageparam = "label=" *uchar

==marcusaurelius==

BIP 0020

2011-01-10T11:58:25Z

Marcusaurelius: distinguished between tcatm's proposal and LukeJr's changes

==tcatm==

I propose a scheme like this:

() means optional, $* are placeholders

<pre>
bitcoin:($label@)$address(?$query)(#$message)
</pre>

=== Variables ===

<pre>
label: Label for that address (e.g. name of receiver)
address: bitcoin address
query: pairs of key=value seperated by &
message: optional message that is shown to the user after scanning the QR code
</pre>

=== Query keys ===
<pre>
amount: amount of BTC

</pre>
=== Examples ===

Just the address:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Address with name:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt
</pre>

Request to send 20.30 BTC to me:
<pre>
bitcoin:tcatm@18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30
</pre>

Request to send 50 BTC with message:
<pre>
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=50#Payment%20for%20product%20xyz
</pre>

Characters must be URI encoded.

==tcatm, modified by LukeJr==

I propose a scheme like this:

[] means optional, <> are placeholders

bitcoin:<address>?amount=<size><unit>[&label=<label>][&message=<message>]

=== Variables ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: optional message that is shown to the user after scanning the QR code
*size: amount of $unit
*unit: BTC, [ᵗˢᵐᵇ]TBC[ᵗˢᵐᵇ], or null/omitted (which refers to the base unit)

=== Examples ===

Just the address:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt

Address with name:BTC
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?label=tcatm

Request to send 20.30 BTC to tcatm:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=20.30BTC&label=tcatm

Request to send 400 TBC to Luke:
bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=400TBC

Request to send 5 uBTC:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8q9ztaWWXt?amount=500

Request to send 50 BTC with message:
bitcoin:18pnDgDYFMAKsHTA3ZqyAi6t8qztaWWXt?amount=50BTC&label=tcatm&message=Payment%20for%20product%20xyz

Characters must be URI encoded properly.

=== BNF syntax ===

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = FIXME :)
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam
amountparam = "amount=" amount
amount = amountdecimal | amounthex | amounttonal
amountdecimal = digits btcunits
amounthex = "x" hexdigits bitcoinunit
amounttonal = tonaldigits tbcunits
bitcoinunit = btcunits | tbcunits
btcunits = "BTC" | "BTCents" | "uBTC" | "uBTCents"
tbcunits = tbcunitsunicode | tbcunitsascii | tbcunitsfull
tbcunitsunicode = "ᵇTBC" | "ᵐTBC" | "ˢTBC" | "ᵗTBC" | "TBC" | "TBCᵗ" | "TBCˢ" | "TBCᵐ" | "TBCᵇ"
tbcunitsascii = "bTBC" | "mTBC" | "sTBC" | "tTBC" | "TBC" | "TBCt" | "TBCs" | "TBCm" | "TBCb"
tbcunitsfull = "tran-TBC" | "song-TBC" | "tam-TBC" | "bong-TBC" | "mill-TBC" | "san-TBC" | "ton-TBC" | "TBC" | "TBC-ton" | "TBC-san" | "TBC-mill" | "TBC-bong"
labelparam = "label=" *uchar
messageparam = "label=" *uchar