Bitcoin Forum
December 03, 2016, 12:29:15 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Can someone explain why BIP 21 is better than BIP 20?  (Read 1393 times)
dree12
Legendary
*
Offline Offline

Activity: 1232



View Profile
February 01, 2012, 12:41:03 AM
 #1

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
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480724955
Hero Member
*
Offline Offline

Posts: 1480724955

View Profile Personal Message (Offline)

Ignore
1480724955
Reply with quote  #2

1480724955
Report to moderator
Killdozer
Full Member
***
Offline Offline

Activity: 204



View Profile
February 01, 2012, 12:49:19 AM
 #2

<the issue was resolved  Smiley >

dree12
Legendary
*
Offline Offline

Activity: 1232



View Profile
February 01, 2012, 12:50:50 AM
 #3

<issue resolved>
<issue resolved>
dree12
Legendary
*
Offline Offline

Activity: 1232



View Profile
February 02, 2012, 04:05:10 PM
 #4

After reading the BIP in question again, I noticed this text:
Quote
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
Full Member
***
Offline Offline

Activity: 124



View Profile WWW
February 02, 2012, 05:13:26 PM
 #5

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.

Bitcoin enthusiast and Java programmer contributing to https://multibit.org and http://bitcoin.stackexchange.com
dree12
Legendary
*
Offline Offline

Activity: 1232



View Profile
February 02, 2012, 06:17:48 PM
 #6

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
Full Member
***
Offline Offline

Activity: 124



View Profile WWW
February 02, 2012, 06:25:56 PM
 #7

Quote
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.

Bitcoin enthusiast and Java programmer contributing to https://multibit.org and http://bitcoin.stackexchange.com
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!