. | Bitcointalksearch.org

BitterTea

sr. member

Activity: 294

Merit: 252

Quote from: HanSolo on June 12, 2011, 07:05:04 PM

To trigger a full transaction, we could also think bigger. Why not a 'payto:' URI that works first and best for bitcoin transactions because they're so easy to represent online but could also subsume other currencies and destinations? For example..

payto:0.02btc|bitcoin:19bF4Xq2bJwVKzGmbq5pxmkgYkE1KnXngp#bitcoin+RFC+donation+to+vladimir
payto:24.99usd|https://paypal.com/user/exampleman#payment+for+1btc

This seems to be inferior to the already specified bitcoin: URI.

bitcoin:19bF4Xq2bJwVKzGmbq5pxmkgYkE1KnXngp?amount=0.02&message=bitcoin+RFC+donation+to+vladimir

How is it any more readable to have fields separated by random symbols as opposed to specified in name/value pairs?

Not to mention that links aren't/don't have to be readable by a human, just a computer. Most of the time links would be done like this anyway:

Click to Donate!

HanSolo

newbie

Activity: 59

Merit: 0

Quote from: ?? on ??

I am quite sure that my proposal complies with rfc3986 just fine.

Moreover, I do not really care if / or : or | or some other separator is used in URI. My proposal is all about simplicity and placing important things where human can easily see and comprehend it. It is also about getting rid of named & variables nonsense.

Though, apparently this stuff is up to software developer to chose and implement. Pray that Luke-jr does not get to implementing URI hooks or you will all be converting to tonal before long. Grin

Sections 3 and 3.2 of rfc3986 strongly suggest '//' be reserved for introducing an Authority "so that governance of the name space defined by the remainder of the URI is delegated to that authority" and even says "When authority is not present, the path cannot begin with two slash characters ("//")." Applied to your proposal, that makes the amount or the receiver the Authority.

Putting the important things first is good, it just needs different separators. Also, maybe 'bitcoin:' should just be an address indicator.

To trigger a full transaction, we could also think bigger. Why not a 'payto:' URI that works first and best for bitcoin transactions because they're so easy to represent online but could also subsume other currencies and destinations? For example..

payto:0.02btc|bitcoin:19bF4Xq2bJwVKzGmbq5pxmkgYkE1KnXngp#bitcoin+RFC+donation+to+vladimir
payto:24.99usd|https://paypal.com/user/exampleman#payment+for+1btc

ISA

newbie

Activity: 52

Merit: 0

great!

ISA

newbie

Activity: 52

Merit: 0

However the solution will look like. Either with ? or / or : or @.

It's a critical feature request for the whole bitcoin economy, especially for merchants.

So please implement it ASAP

HanSolo

newbie

Activity: 59

Merit: 0

People adopt simple things, period.

And that's why we all reached this site via the AOL keyword 'bitcoin'.

HanSolo

newbie

Activity: 59

Merit: 0

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.

ISA

newbie

Activity: 52

Merit: 0

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.

theymos

administrator

Activity: 5222

Merit: 13032

Quote from: rand0mmm on April 21, 2011, 05:24:55 PM

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

rand0mmm

newbie

Activity: 6

Merit: 0

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: BitterTea on April 20, 2011, 06:31:43 PM

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.

BitterTea

sr. member

Activity: 294

Merit: 252

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?

Matt Corallo

hero member

Activity: 755

Merit: 515

Quote from: Luke-Jr on April 20, 2011, 05:55:44 PM

Quote from: weavejester on April 20, 2011, 05:51:03 PM

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)

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: weavejester on April 20, 2011, 05:51:03 PM

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.

BitterTea

sr. member

Activity: 294

Merit: 252

Quote from: weavejester on April 20, 2011, 05:51:03 PM

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.

weavejester

newbie

Activity: 22

Merit: 0

Quote from: Luke-Jr on April 20, 2011, 02:26:27 PM

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

Activity: 294

Merit: 252

Quote from: Matt Corallo on April 20, 2011, 04:23:01 PM

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.

Matt Corallo

hero member

Activity: 755

Merit: 515

Quote from: BitterTea on April 20, 2011, 04:16:16 PM

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.

Quote from: xf2_org on April 20, 2011, 04:08:11 PM

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.

BitterTea

sr. member

Activity: 294

Merit: 252

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.

Quote from: xf2_org on April 20, 2011, 04:08:11 PM

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.

xf2_org

member

Activity: 98

Merit: 13

Oh, there are complaints aplenty about the URI spec.

Google for #bitcoin-dev IRC logs...

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Matt Corallo on April 20, 2011, 03:00:19 PM

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.

Quote from: Gavin Andresen on April 20, 2011, 03:01:14 PM

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.

Quote from: Gavin Andresen on April 20, 2011, 03:01:14 PM

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.

Topic: . (Read 8012 times)