Bitcoin URL scheme: have any proposals been adapted?

aq

full member

Activity: 238

Merit: 100

Quote from: bitplane on August 13, 2011, 08:28:28 PM

If you have a confirmation box then a simple VBScript which launches an URL and calls sendkeys to confirm the transaction could potentially drain your account. I suggest putting the confirmation box on a secure desktop to prevent this possibility.

Sure, instead of just enabling server mode by changing a single line in the config file and using the rpc api (doable right now, and it seems that everyone is ok with this - even no GUI involved, so undetectable by the average user), a hacker would choose the more difficult way of using some link and sendkeys. I mean why even use the link at all, your VBScript can start the bitcoin exe and use sendkeys to open the send dialog to do the same. IMHO that would be an extreme lame excuse for not implementing clickable links. I am sure I could probably write both versions within an hour. And BTW, a VBScript can as easily simulate the link drag-dropping...
So to cut a long story short, either put all those send bitcoin dialogs on a secure desktop, or stop using this as an argument against clickable links.

bitplane

sr. member

Activity: 321

Merit: 250

Firstbits: 1gyzhw

If you have a confirmation box then a simple VBScript which launches an URL and calls sendkeys to confirm the transaction could potentially drain your account. I suggest putting the confirmation box on a secure desktop to prevent this possibility.

aq

full member

Activity: 238

Merit: 100

Quote from: D.H. on August 10, 2011, 11:04:56 AM

Quote from: wumpus on August 07, 2011, 08:06:52 PM

Quote from: bitplane on August 07, 2011, 08:01:42 PM

It should be desktop environment specific, nothing to do with the browser:

Thanks. But I think I'll keep it at explicit drag&drop. Having the browser being able to send commands to the bitcoin client without user intervention is just a too big a potential security hole.

I suggest that you use a confirmation box in the client before executing whatever the link is trying to do. After all it's much more intuitive to click links than to drag them.

+1
Modern browsers already support dragable text, so if a "link" is only dragable, one can just put a plain text address there.
The whole point of a link is that it is clickable. IMHO, thinks like this prevent bitcoin from being mass adoped Sad

error

hero member

Activity: 588

Merit: 500

Quote from: wumpus on August 07, 2011, 08:06:52 PM

Quote from: bitplane on August 07, 2011, 08:01:42 PM

It should be desktop environment specific, nothing to do with the browser:

Thanks. But I think I'll keep it at explicit drag&drop. Having the browser being able to send commands to the bitcoin client without user intervention is just a too big a potential security hole.

I'm not sure if you understand how browsers pass such URLs to external URL handlers. Your program gets called with the URL as an argument. That's all. It's up to your program to actually do something with the URL.

D.H.

sr. member

Activity: 311

Merit: 251

Bitcoin.se site owner

Quote from: wumpus on August 07, 2011, 08:06:52 PM

Quote from: bitplane on August 07, 2011, 08:01:42 PM

It should be desktop environment specific, nothing to do with the browser:

Thanks. But I think I'll keep it at explicit drag&drop. Having the browser being able to send commands to the bitcoin client without user intervention is just a too big a potential security hole.

I suggest that you use a confirmation box in the client before executing whatever the link is trying to do. After all it's much more intuitive to click links than to drag them.

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: bitplane on August 07, 2011, 08:01:42 PM

It should be desktop environment specific, nothing to do with the browser:

Thanks. But I think I'll keep it at explicit drag&drop. Having the browser being able to send commands to the bitcoin client without user intervention is just a too big a potential security hole.

bitplane

sr. member

Activity: 321

Merit: 250

Firstbits: 1gyzhw

Quote from: wumpus on August 07, 2011, 09:49:43 AM

Alas, dispatching based on clicking the URL would need to be implemented on a per-browser basis Sad

So don't expect this any soon.

It should be desktop environment specific, nothing to do with the browser:
Here's how to do it for Windows, Linux (Gnome/KDE), OSX, Android and iOS

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: Gavin Andresen on August 07, 2011, 10:16:08 AM

Suggestions for a better "RFC process" are welcome; which open source project should we emulate? (e.g. bittorrent has BEPs, python has PEPs, are there other models to follow?)

It seems that the PEP process that Python uses works pretty well. I don't know anything about BEP, or how it compares.

But this is a great idea... I also think the URI would be a good initial "Bitcoin PEP" as it is fairly trivial and a good way to get people used to it.

Much better than keeping the spec on a wiki page where people can add all kind of wacky stuff for their own agenda.

drawoc

full member

Activity: 168

Merit: 100

Firstbits: 175wn

Quote from: wumpus on August 07, 2011, 02:26:30 PM

Are '-' even allowed in URI schemes?

Apparently, yes.

From RFC 3986:

Quote

Scheme names consist of a sequence of characters beginning with a
letter and followed by any combination of letters, digits, plus
("+"), period ("."), or hyphen ("-").

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: drawoc on August 07, 2011, 12:23:31 PM

Is x-btc widely used yet? If not, maybe we could modify that to everyone's liking, and make that the standard, so we don't need to worry about backward compatibility.

I don't think any bitcoin URI scheme is widely used yet

But indeed, x-btc: is even more rare than bitcoin: . Are '-' even allowed in URI schemes?

drawoc

full member

Activity: 168

Merit: 100

Firstbits: 175wn

Is x-btc widely used yet? If not, maybe we could modify that to everyone's liking, and make that the standard, so we don't need to worry about backward compatibility.

Gavin Andresen

legendary

Activity: 1652

Merit: 2301

Chief Scientist

The wiki page is luke-jr's baby. Several of us are tired of having wiki-editing wars so we just ignore it.

Suggestions for a better "RFC process" are welcome; which open source project should we emulate? (e.g. bittorrent has BEPs, python has PEPs, are there other models to follow?)

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

I implemented drag&drop support for the simple Bitcoin URLs in my UI.

Simply make a link on the webpage Drag this to the Bitcoin client to pay, and you can drag it to the client to switch to payment mode and add it to the recipients list.

Alas, dispatching based on clicking the URL would need to be implemented on a per-browser basis Sad

So don't expect this any soon.

bitplane

sr. member

Activity: 321

Merit: 250

Firstbits: 1gyzhw

Yeah, you make good points. I guess what's needed is for the devs of the different apps to get together and simplify the standard. Since I'm not actually doing any hacking on these projects I guess my opinion holds no weight, but it's nice to rant about them anyway

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: bitplane on August 04, 2011, 08:34:46 PM

I agree that it seems sensible apart from the hex digits and non-standard exponent, the only virtue of the exponent is that it would discourage people from storing the values in IEEE floats, which are susceptible to rounding error. The hex thing is just plain unforgivable and should rightly be as ignored as hex floats are.

edit: the semicolon thing should also be ignored IMO. Everyone is used to ampersands whether Tim Berners-Lee likes it or not, we're used to parsing them by now.

I can see two ways around the incompatibilities, either label this as version 1.0 of the standard and rename the amount parameter to something else (send?), or have someone rewrite the entire thing, debate it, then actually submit it as an RFC to be forever set in stone.

There are also other things aside from the URI scheme that are worth defining if they haven't been already, for example an XHTML microformat for sharing addresses inline in HTML, plus a way to embed addresses in a vCard or address book.

RFCs are written (or at least should be written) after a sizable body of working code exists.

I would feel free to ignore a spec on a wiki page, but try to avoid gratuitous incompatibilities. In this case, adding E notation in addition to the existing X notation won't be ambiguous for many years, hopefully plenty of time for the X notation to vanish. And as much as I hate to admit it, accepting hex values for compatibility is pretty easy, however silly it is to generate them.

bitplane

sr. member

Activity: 321

Merit: 250

Firstbits: 1gyzhw

I agree that it seems sensible apart from the hex digits and non-standard exponent, the only virtue of the exponent is that it would discourage people from storing the values in IEEE floats, which are susceptible to rounding error. The hex thing is just plain unforgivable and should rightly be as ignored as hex floats are.

edit: the semicolon thing should also be ignored IMO. Everyone is used to ampersands whether Tim Berners-Lee likes it or not, we're used to parsing them by now.

I can see two ways around the incompatibilities, either label this as version 1.0 of the standard and rename the amount parameter to something else (send?), or have someone rewrite the entire thing, debate it, then actually submit it as an RFC to be forever set in stone.

There are also other things aside from the URI scheme that are worth defining if they haven't been already, for example an XHTML microformat for sharing addresses inline in HTML, plus a way to embed addresses in a vCard or address book.

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: kjj on August 04, 2011, 10:03:54 AM

And second the base unit, 1E-8 BTC is an accident of history.

Yep... we're always stuck with an offset of 8 now. So 1e-10 bitcoin would be 1X-2 :p It's all possible, but it's a pity that the "standard" was not designed with simplicity in mind.

So we have different interpretations now;
jav's client interprets amount=1.23 as 1.23 BTC
Bit-Pay would interpret that as 1.23e-8 BTC as there is no exponent

great Tongue

kjj

legendary

Activity: 1302

Merit: 1026

Good to know that there are at least two other projects actually using the thing.

That said, I'm going to just say this publicly. The X notation is stupid. First, there was already a widely known and used notation for powers of 10. And second the base unit, 1E-8 BTC is an accident of history. The foolishness of basing the notation on this value will become obvious just as soon as the first 128 bit client extensions show up.

The only good thing about it is that it lets people use E notation, and do it in a way that makes sense. So, I propose the following:

Amounts that match this regex:

Code:

([0-9]|[0-9]+\.?[0-9]*|[0-9]?\.[0-9]+)E-?[0-9]+

should be interpreted using standard E notation, based around 1 BTC. In E notation, xEy is shorthand for x * (10 ^ y).

Andreas Schildbach

hero member

Activity: 483

Merit: 551

Quote from: jav on August 04, 2011, 02:56:44 AM

I would have been in favor of specifying the amount in Satoshis, but it is my impression that things start to move to interpret the amount as BTC directly. For example the Android Bitcoin client does that.

Yes, and I implemented it this way because of the sentence "If exponent is omitted, implementations SHOULD assume X8 for decimal numbers, ..." on https://en.bitcoin.it/wiki/URI_Scheme

I planned to skip implementing the exponent extension (X), but I got various error reports from users that they could not use generated QR codes (Bit-Pay uses this syntax).

I will try to avoid implementing the hex extension (x). Hex fractional numbers just feel completely awkward, I've never used them anywhere in my computing life.

IMHO: Keep the URI format as human readable as possible. If we want to invent a compressed syntax that squeezes every bit, I'd tackle this more fundamentally by skipping the parameter based syntax completely and compressing amounts by base64-encoding their binary representation.

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: wumpus on August 04, 2011, 06:28:39 AM

Quote from: kjj on August 04, 2011, 06:18:27 AM

There is one argument in favor of using E notation for the amounts. People embed (or want to be able to embed) these URIs into QR code labels, and then scan them with cheap readers, meaning cell phones with cheap cameras. More bits means higher resolution, which makes them less suitable for one popular intended use.

Do those few bytes (up to 7) really matter? If you'd really want to squish out every last byte, you'd also want to give the parameters shorter names.

I don't know if they matter or not. Like most things they are probably unimportant most of the time, but absolutely critical in a few cases. Stripping the field names down to a for amount and l for label is probably a good idea in the same way.

Since you are working on the receiving end, you could always rig your client to accept short versions and long versions, plus absolute values and E notation.

By making a working implementation, and getting it out there in the wild, you are essentially defining the standard in a way that carries a lot more weight than just tossing some ideas on the wiki.

Topic: Bitcoin URL scheme: have any proposals been adapted? (Read 2918 times)