Topic: Machine-detectable way to give a bitcoin address in an HTML page (Read 2378 times)
Sounds great, indeed!
October 17, 2012, 08:31:07 PM
Just a follow-up for anyone developing this further. What do you think about using an existing link relation type for bitcoin? "payment" seems to be about right...
So a link might look like:
See: https://tools.ietf.org/html/draft-nottingham-http-link-header-10
Relation Name: payment
o Description: indicates a resource where payment is accepted.
o Reference: [this document]
o Notes: this relation type registration did not indicate a
reference. Requested by Joshua Kinberg and Robert Sayre. It is
meant as a general way to facilitate acts of payment, and thus
this specification makes no assumptions on the type of payment or
transaction protocol. Examples may include a web page where
donations are accepted or where goods and services are available
for purchase. rel="payment" is not intended to initiate an
automated transaction. In Atom documents, a link element with a
rel="payment" attribute may exist at the feed/channel level and/or
the entry/item level. For example, a rel="payment" link at the
feed/channel level may point to a "tip jar" URI, whereas an entry/
item containing a book review may include a rel="payment" link
that points to the location where the book may be purchased
through an online retailer.
So a link might look like:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L" />
See: https://tools.ietf.org/html/draft-nottingham-http-link-header-10
Relation Name: payment
o Description: indicates a resource where payment is accepted.
o Reference: [this document]
o Notes: this relation type registration did not indicate a
reference. Requested by Joshua Kinberg and Robert Sayre. It is
meant as a general way to facilitate acts of payment, and thus
this specification makes no assumptions on the type of payment or
transaction protocol. Examples may include a web page where
donations are accepted or where goods and services are available
for purchase. rel="payment" is not intended to initiate an
automated transaction. In Atom documents, a link element with a
rel="payment" attribute may exist at the feed/channel level and/or
the entry/item level. For example, a rel="payment" link at the
feed/channel level may point to a "tip jar" URI, whereas an entry/
item containing a book review may include a rel="payment" link
that points to the location where the book may be purchased
through an online retailer.
Why not use the hCard microformat in the HTML to publish receiving addresses?
http://microformats.org/wiki/hcard
Or RDFa?
http://en.wikipedia.org/wiki/RDFa
How about in addition to URLs, we use email addresses to lookup Bitcoin addresses stored in XRD documents via WebFinger?
http://webfinger.org/
http://code.google.com/p/webfinger/wiki/WebFingerProtocol
Seems like this wheel has already been invented.
http://microformats.org/wiki/hcard
Or RDFa?
http://en.wikipedia.org/wiki/RDFa
How about in addition to URLs, we use email addresses to lookup Bitcoin addresses stored in XRD documents via WebFinger?
http://webfinger.org/
http://code.google.com/p/webfinger/wiki/WebFingerProtocol
Seems like this wheel has already been invented.
No browser involved. You don't need a browser to do an HTTP request and parse the response.
In order to avoid confusion on my proposal, here's a step-by-step example:
I do agree that there's a security risk if the HTTP communication is not trusted (no SSL, or SSL with invalid/untrusted certificate), but only in that case.
In order to avoid confusion on my proposal, here's a step-by-step example:
- I'm prompted for a bitcoin address (for example by my desktop bitcoin client, or by mtgox for a withdrawal, etc.)
- Where the address is expected, I enter http://payb.tc/foo
- The client (or MtGox, etc.) fetches the URL. If the Content-Type is text/html, it reads the element(s) that's contained in the header, prompting me to choose if there are several ones, or selecting the first one if we're in a non-interactive context. One improvement can be, if the Content-Type is text/plain instead, to assume the response contains the address as is. This would allow me to give, in payb.tc's case, http://payb.tc/foo/text and make the parsing job easier. People would surely appreciate to be able to give their own homepage URL though (like OpenID), hence the idea.
- It sends the payment to address xxxxxxxxxx.
I do agree that there's a security risk if the HTTP communication is not trusted (no SSL, or SSL with invalid/untrusted certificate), but only in that case.
I think that it's almost a given that any client accepting external automated inputs should require a manual confirmation while providing full details available. e.g. "Received request from site http://blahblahblah.com/somepage to send X bitcoins to " just to avoid the link saying one thing but sending another to the client.
It's better than that - unless the devs completely fuck up the wallet encryption implementation, you're going to have to enter your wallet password each time you want to send money if you have wallet encryption enabled.
If you enable the URL handler, and you don't have an encrypted wallet, you kind of deserve everything you get.
You need both kind of confirmation. The first is to prevent phishing and fraud, the second to ensure a rogue/buggy client cannot simply access your wallet after bypassing the confirmation prompt.
Definitely somebody who enables external access and doesn't encrypt the wallet deserves getting it stolen
I think that it's almost a given that any client accepting external automated inputs should require a manual confirmation while providing full details available. e.g. "Received request from site http://blahblahblah.com/somepage to send X bitcoins to " just to avoid the link saying one thing but sending another to the client.
It's better than that - unless the devs completely fuck up the wallet encryption implementation, you're going to have to enter your wallet password each time you want to send money if you have wallet encryption enabled.
If you enable the URL handler, and you don't have an encrypted wallet, you kind of deserve everything you get.
The goal is to give an URL when/where a bitcoin address is needed, because URLs are generally shorter and easier to memorize than bitcoin addresses.
It's also ridiculous insecure as long as the resolving response is not cryptographically signed. Valid certificate/key management on the other hand is hard to do right and average joe fails at this on a daily basis. (just look at browsers for proof)
Yes, but what if someone hacks the browser and sends a send to order to the client? Browsers are very hackable, they are very expose and do a lot of stuff.
A solution might be to have a mode in the client where all the RPC transactions have to be confirmed manually. Im still fearful of connecting the client to the browser but that might work.
A solution might be to have a mode in the client where all the RPC transactions have to be confirmed manually. Im still fearful of connecting the client to the browser but that might work.
I think that it's almost a given that any client accepting external automated inputs should require a manual confirmation while providing full details available. e.g. "Received request from site http://blahblahblah.com/somepage to send X bitcoins to " just to avoid the link saying one thing but sending another to the client.
Are you guys sure you want to connect your browser to the bitcoin client and allow it to send it orders? That would be a hackers paradise.
I don't think anyone's suggesting auto-send are they? I think the browser would just open up the client but have the user click SEND to actually confirm it.
There's already a URI scheme.
Yes, but what if someone hacks the browser and sends a send to order to the client? Browsers are very hackable, they are very expose and do a lot of stuff.
A solution might be to have a mode in the client where all the RPC transactions have to be confirmed manually. Im still fearful of connecting the client to the browser but that might work.
Are you guys sure you want to connect your browser to the bitcoin client and allow it to send it orders? That would be a hackers paradise.
I don't think anyone's suggesting auto-send are they? I think the browser would just open up the client but have the user click SEND to actually confirm it.
There's already a URI scheme.
There's already a URI scheme.
Are you guys sure you want to connect your browser to the bitcoin client and allow it to send it orders? That would be a hackers paradise.
The interface would go, e.g.: "Pay to: payb.tc/da".
Obviously, it wouldn't be safe to be hard-bound to one specific shortening service, so we need to be able to parse any random HTML page and extract the bitcoin address it contains.
Obviously, it wouldn't be safe to be hard-bound to one specific shortening service, so we need to be able to parse any random HTML page and extract the bitcoin address it contains.
Any shortening service worth it's salt would also output plain text and other useful formats anyway... payb.tc does if you do http://payb.tc/da/text
But I agree it would be great if the various 'withdrawal' and other bitcoin forms around the web would accept a short link, in addition to accepting an address directly.
it would be better and easier to do this instead
bitcoin://public key
bitcoin://send/amount/public key
bitcoin://about
then the browser would pass that off to the default program. then you only need to mess with bitcoin instead of html.
bitcoin://public key
bitcoin://send/amount/public key
bitcoin://about
then the browser would pass that off to the default program. then you only need to mess with bitcoin instead of html.
The URI should follow a standard addressing pattern to avoid issues parsing it. I'd suggest something like
bitcoin://[amount]@address/[command][?parameters]
so those become
bitcoin://1.75@address/send
bitcoin://address/about?details=This is my bitcoin address
Yes 
bitcoin://3.55@address
would be a nice way to handle this.
bitcoin://3.55@address
would be a nice way to handle this.
Both links and achors are described in Section 12 of the HTML 4.01 specification. Essentially, instead of using an 'HTTP' url, you use a 'bitcoin' url. Some browsers/Forum software get confused when you present it with a url type is does not recognize. For example: Floodgap Systems' official gopher server.
edit:
edit:
Code:
Forum software assumed I forgot to include "HTTP". The Http gateway is here. What does putting it in a element do that putting it in an anchor won't?
The goal is to give an URL when/where a bitcoin address is needed, because URLs are generally shorter and easier to memorize than bitcoin addresses. I don't have any particular preference for elements over anchors (... elements) – do you have an example of how to transform an URL into a bitcoin address using anchors? Maybe the vCard format could be extended to announce someone's bitcoin address.
I would also like to clarify that although I'm using bitcoin:xxx URI format in my example, this isn't the point. Use bitcoin://xxx?label=foo if you prefer, or whatever, it doesn't matter here. The choice of a particular URI format is off-topic here – this question is debated in length in other threads.
A similar goal would be to discover bitcoin addresses from a JID (XMPP identifier). I've started to work on something to address that.
mine or his?
I don't know who is right and who is wrong - Everyone who's implementing a URL handler needs to use the format that's on the Wiki, so there's no confusion.
Don't fuck with the URL format - there's one already established, it should be used (but moreso, it should be damn-well implemented in the client so people stop getting the idea to fuck with it).
What does putting it in a element do that putting it in an anchor won't? Is it for a browser plugin's benefit or what?
What does putting it in a element do that putting it in an anchor won't? Is it for a browser plugin's benefit or what?
mine or his?
steam does what i said, thats were i got the idea from, also magnet links work the same way.
Don't fuck with the URL format - there's one already established, it should be used (but moreso, it should be damn-well implemented in the client so people stop getting the idea to fuck with it).
What does putting it in a element do that putting it in an anchor won't? Is it for a browser plugin's benefit or what?
What does putting it in a element do that putting it in an anchor won't? Is it for a browser plugin's benefit or what?
Jump to: