Bitcoin Forum

One of the tough things we need to improve for everyday use of bitcoin is how to remember, share and input bitcoin addresses. You can't give your bitcoin address as easily as you give your email address.

To address this issue, a couple of wonderful bitcoin address shortening services, such as FirstBits (http://firstbits.com) and payb.tc (http://payb.tc), started to appear. They're actually so useful that bitcoin handling tools (e.g. the original client, a mobile phone app, etc.) would highly benefit from integrating them wherever a bitcoin address is expected. 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. Where interactive use is possible, such programs would optionally handle the case where there are several addresses, and let the user choose one from a list.

I long ago suggested (http://forum.bitcoin.org/index.php?topic=2396.msg32455#msg32455) a <link />-based way to do it, and I still think it would work well, as well as be easy to implement:

(Well, PIF isn't there anymore, but I just copied and paste my former example.)

As someone said later in the same thread, it's very similar to how OpenID does it.

It would be great if address-shortening services, and generally other services that return bitcoin addresses would use this approach (or a similar one). What do you think?

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.

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

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. ;)

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 <link /> elements over anchors (<a>...</a> 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 (http://gitorious.org/bitcoim/pages/Requesting_someones_bitcoin_address_via_XMPP) to address that.

Both links and achors are described in Section 12 of the HTML 4.01 specification (http://www.w3.org/TR/1999/REC-html401-19991224/struct/links.html). 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 (http://gopher://gopher.floodgap.com/).
edit: Forum software assumed I forgot to include "HTTP". The Http gateway is here (http://gopher.floodgap.com/gopher/).

Yes ;)

bitcoin://3.55@address

would be a nice way to handle this.

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

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.

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.

There's already a URI scheme (http://en.bitcoin.it/wiki/URI_Scheme).

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.

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.

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 <address>" just to avoid the link saying one thing but sending another to the client.

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)

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 :D

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'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 <link rel="bitcoin.address" href="xxxxxxxxxx" title="whatever"/> 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 <link /> 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.

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.

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.

Sounds great, indeed!