Talk:BIP 0020

See Talk:Main_Page#Header_capitalisation before continuing ;) Genjix 08:02, 10 January 2011 (GMT)

Also, consider using SI prefixes. They are standard throughout the world (except America). Genjix 08:04, 10 January 2011 (GMT)

• SI/decimal is the inferior competition/enemy of the superior Tonal system. That is, to be avoided. (Chinese is a standard language throughout most of the world too! And whatever the currency of China is-- should we not use bitcoins??) Luke-jr 15:05, 10 January 2011 (GMT)

Has anybody thought about including network addresses (IPv4/IPv6) of the receiving client into the URL? This way, a payment transaction could be sent directly (in addition to sending P2P of course). --Goonie 11:21, 23 July 2011 (GMT)

Exponents

• Wouldn't it be better if we used the more standard "e" to represent the exponent? e.g. 5e8 = 500,000,000. Weavejester 11:18 PM, 18 April 2011 (GMT)

An older draft used this, but when implementing, it was quickly noted to conflict with the 'e' hexadecimal digit. --Luke-jr 16:04, 19 April 2011 (GMT)

Thanks for the response! I noticed that flaw shortly after I asked the question, but it looks like the wiki lost the update I posted. Out of interest, what's the benefit for allowing both decimal and hexidecimal notation? Weavejester 20:02 PM, 19 April 2011 (GMT)

So people can at least some some degree of readability for TBC amounts. --Luke-jr 20:33, 19 April 2011 (GMT)

• Why are exponents even used to begin with? It is far, far simpler to just use the decimal values and I would almost guarantee that most people will always write their URIs using decimal amounts as its far simpler to write and is still valid. BlueMatt 12:46, 20 April 2011 (GMT)

Fallback URI

On Android an app can register to open with a normal web URI. This has the advantage of acting as a fallback URI in case there is no app that supports bitcoin:. For example we could propose https://en.bitcoin.it/wiki/Send/<address>[?][amount=<size>][&][label=<label>][&][message=<message>]. If the user had a mobile app that supported bitcoin it would have registered https://en.bitcoin.it/wiki/Send/ and be launched. If the user did not have such an app their browser would launch and be directed to https://en.bitcoin.it/wiki/Send/. This page could then inform the user about various apps that support bitcoin transfers and possibly have a link to MyBitcoin as well. Maybe https://bitcoin.org/Send/ would be more appropriate, though that one might not be updated often enough.

• iPhone support

There is even a way to have this work on iOS devices. Have the web page redirect to the standard bitcoin: scheme. If an app is present to support this the app will launch, if not the browser the will stay open at the explanation page.

• Upshot

This fallback proposal will make bitcoin QR codes meaningful regardless of if the user has a bitcoin app installed.--BitMark 16:05, 2 April 2011 (GMT)

Use-cases - buy this link

On the buy-this link, perhaps we should also incorporate an optional transaction id or something which would be passed along to the bitcoin client. Not really transaction but some sort of arbitrary data, only meaningful to the merchant. Something an online merchant can use to verify which transaction it has received is relevant to a purchase. Dantman 20:45, 18 April 2011 (GMT)

Tonal/Hex support

Why is Tonal/Hex part of the spec? If a couple users want to use a different unit system that is fine, but that doesn't mean we need to complicate the protocol for them. Tonal already needs to be converted to normal BTC before transferring, why is that not part of this spec. Also, jgarzik/others showed no interest in implementing URI in the main bitcoin client as long as there is tonal/hex support in the spec. BlueMatt 12:51, 20 April 2011 (GMT)

Incorrect Syntax

The proposed syntax doesn't seem to capture the intent of the design. Here's how it reads on the wiki page:

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

The above syntax describes the question mark and ampersands as optional, but really they should be mandatory as a separator if multiple parameters are included. According to the proposed specification, above, the following would be an acceptable URI, which I don't believe is a good thing (note the absence of the optional question mark and ampersands):

bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9Lamount=50X8label=Luke-Jrmessage=Donation%20for%20project%20xyz

Perhaps a more exact/correct way to describe the proposed syntax would be:

bitcoin:<address>[?<parameters-list>]
  where <parameters-list> is one or more of the following, separated by ampersand
[amount=<size>]
[label=<label>]
[message=<message>]

The BNF gets close to describing this, but also has issues. The most glaring to me is this line:

messageparam    = "label=" *uchar

(Seems to me that messageparam should have the literal "message=", as opposed to "label=".)

In addition, the BNF includes a parameter named "version" (which is not in the earlier specification), and also doesn't state that parameters are separated by ampersands.

Jerfelix 04:09, 13 June 2011 (GMT)

URI End / Ignored part

Edit by OP (phelix): Not necessary - found out a way how to realize this in the QR-Code world.

For some QR applications it might come in handy to add some characters that are not part of the URI any more. Does a space end the URI? Can everything after a # be ignored?

• An "end-of-URI" delimiter would be a QR-Code issue. I'm not sure how the existing implementations would handle a # either, though that seems like it could be logical. Might also try adding &dummy=... --Luke-jr 13:25, 26 May 2011 (GMT)