Can someone explain why BIP 21 is better than BIP 20?

[dree12]

After careful review I'm beginning to think that BIP 20, is, in fact better. Firstly, a review of BIP 21 shows how it does not accept the X or exponent parameter, nor the hexadecimal bitcoin system. Although I could care less about the hexadecimal system, the X parameter seems like an excellent idea to more consisely represent units of the user's preference.

My opinion on this is that a hybrid system may be optimal here. To avoid decimal bias, a base parameter may be employed to increase flexibility. For the size parameter, why not a system like this:

Code:

([0-9A-F]+)([.,|'": ]+)?([0-9A-F]*)(X[0-9A-F]+)?(Y[0-9]+)?

And the computation is psuedocode:

Code:

If not Group 5:
    Set Group 5 to 10
If not Group 4:
    Set Group 4 to 8
Set significant as to_decimal(Group 1 from base Group 5) *Group 5^Group 4
If Group 2:
    Set insignificant as to_decimal((concatenate "0." and Group 3) from base Group 5) *Group 5^Group 4
    Set total as significant + insignificant
Else:
    Set total as significant

This allows constructs like

Code:

50,00 => 5000000000
50 50 => 5050000000
600X0 => 600
500X0Y6 => 180
1Y16 => 4294967296
30 => 3000000000
40:50 => 4050000000

[1713519360]

1713519360

[1713519360]

1713519360

[1713519360]

1713519360

[Killdozer]

<the issue was resolved  >

[dree12]

<issue resolved>

<issue resolved>

[dree12]

After reading the BIP in question again, I noticed this text:

The alternative payment amounts in BIP 0020 have been removed.

This confirms that the removal of alternative payout amounts was intentional. How is this an improvement at all? A little bit more complexity isn't going to hurt here. If this is because of a security concern, just convert the value and ask the user to deal with it.

If it is because the bitcoin developers want the URI to be unique, consider:

Code:

50

Code:

50.0

Code:

50.00

Code:

50;.00

Code:

fifty(50).zero(0)

which all compute to 5000000000 units. I understand that it is possible to use a req:flexiblesize parameter or something, but why not allow the more flexible representation to be used by all clients?

(edit): I'm assuming, although unwritten, that a req:size and size can not co-exist. Also, although not explicitly stated, amount and size are also equivalent. If there is something I misread (e.g., amount still allows BIP20 description), please do inform me.

[garyrowe]

My understanding is that BIP 21 reduces the level of processing of the Bitcoin URI by both humans and machines and makes the overall URI scheme simpler.

To have single representation of an amount fixed as decimal BTCs (decimal biased) means that people can easily read the value as presented in their client in a raw state (e.g. a browser) without having to do any specialised thinking. For example, a member of the general public attempting to decode "amount=500X0Y6" would fail utterly. Equally, machine processing is made simple because there will nearly always be a decimal in place, and further decimal positions (e.g. a move from 8dp to 10dp or whatever) won't invalidate earlier URIs.

The purpose of a URI is to provide a unique resource identifier, and good design typically means that one URI binds to one resource (although others can temporarily point to the same one). In this case the resource is interpreted as a payment request.

The notation for the "required parameter" was going to change from "req:" to "req-" in line with RFC 3986 Section 2.2 "Reserved Characters" but the edits may not have made it to the wiki yet.

[dree12]

My understanding is that BIP 21 reduces the level of processing of the Bitcoin URI by both humans and machines and makes the overall URI scheme simpler.

To have single representation of an amount fixed as decimal BTCs (decimal biased) means that people can easily read the value as presented in their client in a raw state (e.g. a browser) without having to do any specialised thinking. For example, a member of the general public attempting to decode "amount=500X0Y6" would fail utterly. Equally, machine processing is made simple because there will nearly always be a decimal in place, and further decimal positions (e.g. a move from 8dp to 10dp or whatever) won't invalidate earlier URIs.

The purpose of a URI is to provide a unique resource identifier, and good design typically means that one URI binds to one resource (although others can temporarily point to the same one). In this case the resource is interpreted as a payment request.

The notation for the "required parameter" was going to change from "req:" to "req-" in line with RFC 3986 Section 2.2 "Reserved Characters" but the edits may not have made it to the wiki yet.

Hmm, thanks for this informative post. I still don't understand why this would make decimal shifts easier, however, as the X parameter can easily be expanded to include a negative exponent (e.g., Z instead of X). According to the wiki, however, decimal points are not needed in BIP 21, which gives rise to the multiple-URI one semantic I outlined in my previous post.

I guess the design of BIP 21 focused on decoding the URI, while my proposal and understanding only considered making creating the URI more efficient and easier. To resolve this issue, I wrote a simple python script which would take a 500X0Y6 like parameter and convert it into a BIP 21 protocol string. Thanks again for clearing it up for me.

Is it possible to offer third-party extensions in BIP21? For example, having a bitcoin client support a field like "req-satoshi-detailedamount" or "armory-lowfee", without coordination between the client developers?

[garyrowe]

Is it possible to offer third-party extensions in BIP21? For example, having a bitcoin client support a field like "req-satoshi-detailedamount" or "armory-lowfee", without coordination between the client developers?

I can't speak for the whole developer community, but if an arbitrary set of fields was included into the URI with a "req-" prefix and my client didn't understand them it would, correctly, reject the URI. Over use, or un-coordinated use, of this approach would give rise to a lot of broken URIs among clients and an inconsistent user experience.

Overall, if you have a field that you think is important enough to have on your URI, submit it to the developer community for widespread acceptance (and review). That's what the BIP is for.