Bitcoin Forum
December 03, 2016, 01:54:02 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: .  (Read 7269 times)
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
April 20, 2011, 07:26:27 PM
 #21

Final and MIT licensed version:
http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/commitdiff/d32bebafd41fac885055274ebf6142b960d1345e

I put a lot of work into doing this perfectly, at way below cost from what I would usually charge for programming, so I would like to request it only be merged as-is, with any pre-merge changes made by me. Specifically, I have concerns about jgarzik and tcatm trying to break the entire URI specification 3 months after it's been implemented in every* client except their own. Obviously, my request still leaves them room to do so post-merge, but at least this way people who have problems can be pointed to a specific breaking revision to revert to fix it.

And to clear up any FUD in advance: the URI spec and implementation herein do not in any way constitute "Tonal support". The changes to the spec irrationally demanded by the trolls involves making it absurdly more difficult for Tonal users (at no gain to Decimal users), and also makes it more difficult/annoying for Decimal users in the future when everyone is using milli- or micro-bitcoins. At the same time, their change is effectively attempting to repeat one of the known (and agreed by a general consensus, in numerous other forum threads) design flaws in the JSON-RPC protocol.

1480773242
Hero Member
*
Offline Offline

Posts: 1480773242

View Profile Personal Message (Offline)

Ignore
1480773242
Reply with quote  #2

1480773242
Report to moderator
1480773242
Hero Member
*
Offline Offline

Posts: 1480773242

View Profile Personal Message (Offline)

Ignore
1480773242
Reply with quote  #2

1480773242
Report to moderator
1480773242
Hero Member
*
Offline Offline

Posts: 1480773242

View Profile Personal Message (Offline)

Ignore
1480773242
Reply with quote  #2

1480773242
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480773242
Hero Member
*
Offline Offline

Posts: 1480773242

View Profile Personal Message (Offline)

Ignore
1480773242
Reply with quote  #2

1480773242
Report to moderator
1480773242
Hero Member
*
Offline Offline

Posts: 1480773242

View Profile Personal Message (Offline)

Ignore
1480773242
Reply with quote  #2

1480773242
Report to moderator
1480773242
Hero Member
*
Offline Offline

Posts: 1480773242

View Profile Personal Message (Offline)

Ignore
1480773242
Reply with quote  #2

1480773242
Report to moderator
sirius
Bitcoiner
Staff
Sr. Member
****
Offline Offline

Activity: 429



View Profile
April 20, 2011, 07:51:46 PM
 #22

Thanks for quick completion, Luke!

You can test the URIs on Firefox (3.5 and above):

  • Type about:config into the Location Bar (address bar) and press Enter.
  • Right-click -> New -> Boolean -> Name: network.protocol-handler.expose.bitcoin -> Value -> false
  • Create an html page with a bitcoin-link: <a href="bitcoin:bitcoinaddress">payment link</a>
  • Click the link and you will be asked which application to open it with. Open with the bitcoinuri binary.

Identifi - Decentralized address book with trust ratings
I'm not a forum admin - please contact theymos instead.
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
April 20, 2011, 08:00:19 PM
 #23

Working on some slight modifications to make it pull-able and will send in a pull request when I'm done.  (mostly removing tonal/hex stuff which jgarzik specifically objected to and adding support for Windows and OSX)

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
April 20, 2011, 08:01:14 PM
 #24

We've already got ParseMoney in util.cpp, this patch adds parseNumber/uriParseAmount.  Having more than one way to convert strings into bitcoin amounts is not a good idea, in my humble opinion.

Also, instead of having a separate executable it would be more 'wxbitcoin-like' to have one executable that acts as either client or server depending on what command-line arguments are given.  The problem with two executables is you'll have clueless users double-clicking on bitcoinuri.exe and then wondering why it doesn't do anything.

I do like the use of boost message queues to communicate.

How often do you get the chance to work on a potentially world-changing project?
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
April 20, 2011, 08:13:21 PM
 #25

We've already got ParseMoney in util.cpp, this patch adds parseNumber/uriParseAmount.  Having more than one way to convert strings into bitcoin amounts is not a good idea, in my humble opinion.
Problem is that the URI Spec uses a different method for encoding values (for future compatibility) specifically using exponents to allow uBTC to be specified as 1X2 or other similar situations.  IMHO this is needless and is overcomplicated for no reason, but it is already the way it is done and I don't see anyone complaining too much here so unless you highly disagree, I don't see anything wrong with it.

Also, instead of having a separate executable it would be more 'wxbitcoin-like' to have one executable that acts as either client or server depending on what command-line arguments are given.  The problem with two executables is you'll have clueless users double-clicking on bitcoinuri.exe and then wondering why it doesn't do anything.
Working on changing that Smiley

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
April 20, 2011, 08:50:17 PM
 #26

Working on some slight modifications to make it pull-able and will send in a pull request when I'm done.  (mostly removing tonal/hex stuff which jgarzik specifically objected to and adding support for Windows and OSX)
This is exactly what I object to.
We've already got ParseMoney in util.cpp, this patch adds parseNumber/uriParseAmount.  Having more than one way to convert strings into bitcoin amounts is not a good idea, in my humble opinion.
I agree, except that ParseMoney does not comply with the spec, and is not suitable to URIs.
Also, instead of having a separate executable it would be more 'wxbitcoin-like' to have one executable that acts as either client or server depending on what command-line arguments are given.  The problem with two executables is you'll have clueless users double-clicking on bitcoinuri.exe and then wondering why it doesn't do anything.
The problem with a single executable, is that the OS will load and link everything for every URI click.

xf2_org
Member
**
Offline Offline

Activity: 70


View Profile
April 20, 2011, 09:08:11 PM
 #27


Oh, there are complaints aplenty about the URI spec.

Google for #bitcoin-dev IRC logs...

BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
April 20, 2011, 09:16:16 PM
 #28

I don't see the problem of allowing the URI to support multiple amount formats. You are free to only use decimal if you like.

Oh, there are complaints aplenty about the URI spec.

Google for #bitcoin-dev IRC logs...

What are the specific complaints? Spending a few minutes Googling yielded chat logs, but nothing that I can connect to this discussion.
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
April 20, 2011, 09:23:01 PM
 #29

I don't see the problem of allowing the URI to support multiple amount formats. You are free to only use decimal if you like.

Oh, there are complaints aplenty about the URI spec.

Google for #bitcoin-dev IRC logs...

What are the specific complaints? Spending a few minutes Googling yielded chat logs, but nothing that I can connect to this discussion.
Please read the ones from tonight.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
April 20, 2011, 10:21:37 PM
 #30

Please read the ones from tonight.

http://veritas.maximilianeum.ch/bitcoin/irc/logs/2011/04/20

Here's how it appears to me...

Jgarzik doesn't realize that the "tonal support" in this patch is merely allowing conversion of tonal specified units in the URI to Satoshis for internal use. It's not adding anything to do with displaying or computing tonal numbers into the actual client. I think having flexibility in the URI is a great thing. Why not allow people who use the URI on their sites to specify the amount in whatever format they choose? It will still display a decimal amount in the client.

5.0 == 5X8 == 500000000X0 == x1DCD6500X0 == x1DCBX4 == x1DCB

I normally dislike Luke's evangelising of tonal, but in this case I don't see any ulterior motive on his part.
weavejester
Newbie
*
Offline Offline

Activity: 23


View Profile
April 20, 2011, 10:51:03 PM
 #31

The changes to the spec irrationally demanded by the trolls involves making it absurdly more difficult for Tonal users (at no gain to Decimal users)

Maybe it's just me, but I didn't understand that 5X8 meant 500,000,000 until I read the specification in more detail. On the other hand, I would have instantly understood 5e8, because it's a standard convention. So at least in my case, there is a disadvantage to using this syntax, as it's less discoverable. I'd also point out that the difference in character height makes it easier to distinguish the exponent and multiplier in 5e8, whereas 5X8 is a little harder to read.

Perhaps I'm incorrect, but my guess is that the number of people who are familiar with the 5e8 convention is considerably greater than the amount of people who prefer using hexadecimal notation for monetary values. It's my opinion that using a syntax that disadvantages the majority, even if only slightly, is not worth the cost if only a very few people benefit.

If we really must have hexadecimal notation, can't we use a different exponent marker for hexadecimal values? e.g. 500e8 for decimals, and 0xf00x8 for hexadecimal.
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
April 20, 2011, 10:53:34 PM
 #32

Maybe it's just me, but I didn't understand that 5X8 meant 500,000,000 until I read the specification in more detail. On the other hand, I would have instantly understood 5e8, because it's a standard convention. So at least in my case, there is a disadvantage to using this syntax, as it's less discoverable. I'd also point out that the difference in character height makes it easier to distinguish the exponent and multiplier in 5e8, whereas 5X8 is a little harder to read.

Perhaps I'm incorrect, but my guess is that the number of people who are familiar with the 5e8 convention is considerably greater than the amount of people who prefer using hexadecimal notation for monetary values. It's my opinion that using a syntax that disadvantages the majority, even if only slightly, is not worth the cost if only a very few people benefit.

If we really must have hexadecimal notation, can't we use a different exponent marker for hexadecimal values? e.g. 500e8 for decimals, and 0xf00x8 for hexadecimal.

Actually, I agree with this. Perhaps "e" or "X" could be used to denote the exponential unit.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
April 20, 2011, 10:55:44 PM
 #33

If we really must have hexadecimal notation, can't we use a different exponent marker for hexadecimal values? e.g. 500e8 for decimals, and 0xf00x8 for hexadecimal.
Treating 'e' like this only for decimal values would not break backward compatibility. No objection from me.

Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
April 20, 2011, 11:28:23 PM
 #34

If we really must have hexadecimal notation, can't we use a different exponent marker for hexadecimal values? e.g. 500e8 for decimals, and 0xf00x8 for hexadecimal.
Treating 'e' like this only for decimal values would not break backward compatibility. No objection from me.
Quote from the wiki talk page:
Quote
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)

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
April 20, 2011, 11:31:43 PM
 #35

Which is why 'e' would work for decimal, as Luke said.

But now that I think about it, 'e' isn't in the tonal alphabet, right?
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
April 20, 2011, 11:52:56 PM
 #36

Which is why 'e' would work for decimal, as Luke said.

But now that I think about it, 'e' isn't in the tonal alphabet, right?
Correct, but the URI scheme doesn't support tonal.

rand0mmm
Newbie
*
Offline Offline

Activity: 6


View Profile
April 21, 2011, 10:24:55 PM
 #37

Vladimirs scheme looks straightforwards and useful to me. Though I would add an action param to make this clear it was a "Send". (SEND/RECV)
The scheme needs actions, a way to do more than just send. I don't worry too much about the human readable part, but it is nice when all human legible parts are clustered together. Also, To you guys, the bitcoin address probably jumps out as such, but to most, it looks like scrambled eggs. So I would probably put the amount after the address. It does seem good to have some sort of version number in there, essentially making clear what url format is in use.  Easy to move forwards by revving the version, easy to handle old requests as they come in tagged.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
April 22, 2011, 02:50:18 AM
 #38

The scheme needs actions, a way to do more than just send. I don't worry too much about the human readable part, but it is nice when all human legible parts are clustered together. Also, To you guys, the bitcoin address probably jumps out as such, but to most, it looks like scrambled eggs. So I would probably put the amount after the address. It does seem good to have some sort of version number in there, essentially making clear what url format is in use.  Easy to move forwards by revving the version, easy to handle old requests as they come in tagged.

See x-btc, which has actions and other useful features:
https://en.bitcoin.it/wiki/X-btc

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ISA
Jr. Member
*
Offline Offline

Activity: 48


View Profile
June 10, 2011, 02:50:15 AM
 #39

I find Valdimirs URI scheme RFC very straight-forward and easy to understand,
thus very powerful.

I strongly recommend to implement this RFC asap in the client, since
this makes web payments / donations really easy and bitcoin very interesting
to merchants.

HanSolo
Jr. Member
*
Offline Offline

Activity: 59


Don't everyone thank me at once.


View Profile
June 10, 2011, 09:42:35 AM
 #40

URI spec is rfc3986 from 2005, supersedes rfc2396 from 1998.

Double-slashes aren't right. By convention they mean 'next part describes a hierarchical-authority-root affecting the rest of the interpretation'. In 'http', a host is the 'authority'. For a suggested bitcoin transaction, neither the amount nor destination address is really the 'authority'. For a completed transaction, maybe the originator is the 'authority'.. but people seem to want these URIs as triggers for next-actions not back-references to past-actions, though a back-reference format to point to blocks, transactions, keys maybe useful too.

Slashes to separate fields by hard ordering are fragile and contrary to other URI precedents.

Better to avoid slashes unless there's a real nested hierarchy. The proposal on the wiki has the right idea.


Never tell me the odds. ⓑ 1J5wQvCz2mn3f4TxPFtExKs253GyeKKkBb
Pages: « 1 [2] 3 »  All
  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!