bitcoin://

[Bruce Wagner]

Today over lunch, I was telling Ed about the idea of a bitcoin widget for donations and/or payments.   This idea came to me:

What we need is a new standard type of URL or link...  like:

bitcoin://15kDhRAcpgsugmh6mQsTcCHdvbsuYncEEV

Whenever anyone clicks that link (or an image or button with that as the underlying link), the computer's default Bitcoin app would launch, with that address already in the Send TO field.  Even the web-based MyBitcoin could be set as the default bitcoin app for that device.

This way using bitcoin could become a one click thing.  As easy as clicking on someone's email address to compose a new email to him.

[FreeMoney]

There has been discussion about exactly that. I don't quite get it in light of this:

http://bitcointalk.org/index.php?topic=1411.0

a chrome extension, it turns bitcoin addresses on the page into clickable links. The implementation isn't perfect yet, but it works.

[BitLex]

and more discussion here
http://bitcointalk.org/index.php?topic=1877.0
and here
http://bitcointalk.org/index.php?topic=55.0

[genjix]

How about using mimetypes and setting bitcoin as that default mimetype.

i.e

download and open address.bitcoin which contains the string 15kDhRAcpgsugmh6mQsTcCHdvbsuYncEEV

Would be a hell of a lot easier and very simple to implement.

[MagicalTux]

the .bitcoin file could just contain the address in binary format, or could be formatted to also include informations about, for example, a transaction to be made

[Gavin Andresen]

I've been lobbying for the mimetype solution.

I did a little mockup a while ago of what happens if you click on a link and do NOT have bitcoin installed (which, in my opinion, is the most important case):
http://skypaint.com/btcpay/mimepay.html

[Bruce Wagner]

As I said on that other thread...

Questions.

1.  Why not have both?   The market will decide which one people choose to use most.  One might be used more at first, then later as browsers are updated, site owners might later switch to the other.   But....  Are they mutually exclusive??

2.  What's stopping us?   Let's just implement them BOTH immediately.   We obviously have the knowledge and expertise to get the job done.   Let's just get the job done already.

[jgarzik]

MIME type is clearly superior to "bitcoin://" type URL.  Because after all, you might use http:// to download a .bitcoin file.

[Gavin Andresen]

1.  Why not have both?   The market will decide which one people choose to use most.  One might be used more at first, then later as browsers are updated, site owners might later switch to the other.   But....  Are they mutually exclusive??

Nope, the hard parts aren't parsing the bitcoin: url string (or the file), and once parsed the same code could do the actual request.

2.  What's stopping us?   Let's just implement them BOTH immediately.   We obviously have the knowledge and expertise to get the job done.   Let's just get the job done already.

The hard part:  what happens if I click on a pay-using-bitcoin link and I don't happen to have bitcoin running right now?

The browser or OS runs bitcoin and hands it the payment request info.

The bitcoin process checks to see if there is already another bitcoin process running.

Nope.  Ok, load the wallet.  And then wait until we're caught up fetching the block chain that we missed while we weren't running.  Gotta do that because some of the transactions in my wallet might have been spent (if you copied your wallet somewhere), or you might have received payments while bitcoin wasn't running.

And so N minutes after clicking bitcoin is FINALLY ready to send payment.  If N is greater than 1, then that really sucks!

---------------

I like click-to-pay, and I want it to work; it would work well now for the "I'm running bitcoin and connected to the network 24/7" use case.  But I don't think that will be the common use case (most people probably won't bother generating).

So I think we've got to figure out some clever way of making click-to-pay quick-- maybe ask for payment permission and then have bitcoin chug away in the background, popup an alert if there's some problem paying, or just shut itself down after it's caught up with the block chain and has submitted the payment.  Or, assuming you have enough coins in your wallet, maybe just throw the transaction onto the network and let peers tell you if you're accidentally double-spending (that makes me very nervous, though).  Or...

[genjix]

bitcoind should ideally run listening. Then the bitcoin gui is simply a thin client communicating using json to the daemon.

This way people can easily make custom clients IMO

[MrFlibble]

I've been lobbying for the mimetype solution.

+1  ^{(populism != sanity)}

The bitcoin: URL scheme makes sense by analogy to mailto: but

• It leaves the transaction info visible.  Without a standard way to transport and encrypt it (re-invent https?!), you encourage data leaks which are likely to link people to transactions.
• Is >35 chr long.  bitcoin: (8 chr) + address (27 in base64, 35 in the standard form?) + amount etc.
• Compare something like ht tps://txn.bt/b64id which is 20 chr, of which some cavalier folk will omit 8.  Without a checksum, it's good for 1E9 transactions.
  "txn.bt has not been registered yet and so available. This domain could be purchased but with no guarantee. Availability of domain name doesn't necessarily mean this can be purchased." -- http://www.nic.bt/twhois/whoiss.php
  If it's available, that's a nice landgarb for some enterprising person to make another centralised service. 
• So you need a transport for the text containing/of the URL.  I think <a href> in HTML-over-HTTPS is intended, and could work fine.  Otherwise, you could offer a shortcut (.lnk) file for download but a) they are platform-dependent b) cautious people don't trust them c) do shortcut files have a mimetype? 

I did a little mockup [...] http://skypaint.com/btcpay/mimepay.html

Cool!

I have cooked up an email version,

• One encrypted email from Bob to Alice requesting payment and attaching your file.
• Another mail containing a copy of Alice's GPG keys so you can read the first mail.
• Currently for the benefit of those happy to download and open an mbox file.
• I suggest moving your ~/.gnupg/ out of the way while trying it, to avoid accumulating the cruft key.

Also may I suggest from my armchair,

• The message file looks quite minimal.  Can you put up a bells'n'whistles example with more fields, such as
  
  • Suggested txn fee.  If it took the form of a range it would allow newbie customers to exercise discretion with an "express payment .. cheapskate" slider bar...  but still be only a request or recommendation.
  • a nonce or id, to be recorded in the wallet.  This allows prompting "You paid this request on yyyy-mm-dd and it was confirmed an hour later.  Do you want to pay it again?"
  • a suggested txn message (how big are these? just an id?)
  • a symmetric key (reuse the nonce? take 20 bits as the nonce and bin the rest after a week?) to encrypt the txn message, because it is public
  • state how many confirmation blocks the merchant will wait for.
  • Some X-Foo: headers to show extensions.  X-Face: raises the issue of phishing...
  • dates...  bill issue (now) date, due date, request expiry date?  But I guess we don't want to re-invent the B2B monstrosity.
• It might be good to include some characteristic magic string, so file(1) can guess the mimetype.  I don't know a good way to do this.
• How would the merchant sign the payment request in a way that makes it clear what is being bought? Should the request contain mime attachments or be included in a multipart/mixed ?
• How does the txn message make it irrevocably clear that the payment is in answer to this request?  Suppose it ends up in court after wrong goods are delivered - customer has the offer to treat in the form of (( self-contained inventory HTML+images of shopping cart contents; request for payment; merchant signature )) and there is a public payment in the blockchain with a message identifying that request.
• Can the request delivery to existing browsers be improved with mime Accepts headers?  (I haven't dabbled with this aspect of the HTTP spec.)  Is it good for browsers to advertise acceptance of the payment-request type?

HTH,

[Bruce Wagner]

You guys are over my head...  but rather than the Bitcoin program needing to be running 24/7.....  What if the link opened the web-based MyBitcoin.com... inserting all the proper fields into a Send Money page....

[MrFlibble]

You guys are over my head...  but rather than the Bitcoin program needing to be running 24/7.....

If you're including me there, sorry.  I can try another explanation or answer some questions?  (But my IRL-lag may be high.)

I don't think bitcoind needs to be running.  The mimetype has an app to handle it, call it bitcoin_pay_gui (or plain bitcoin with some option flags).  When this starts it needs to check for a running bitcoin(d) and talk to it, else start one or do the operation itself.

To make the payment, ideally you have the latest block so you know your balance (yes?) but in cavalier mode you could issue the transaction on old money without checking you still own it.

Then the app should probably hang around to see some confirmation, or failures, and notify the user.  After this it can quit if nobody needs it.

What if the link opened the web-based MyBitcoin.com... inserting all the proper fields into a Send Money page....

Hmm, if the browser says it Accepts:application/bitcoin-payment-request then mybitcoin.com is irrelevant, but if it doesn't (very likely) then it's certainly worth putting a suitable link in the "page you get before it just gives you a file you can't yet deal with".  I'm not sure this is what Accepts: was intended for...

Presumably mybitcoin.com could usefully fetch & process this mimetype?  This seems less useful than a multi-format spec of standard keys & values to send when requesting payment from someone..?

[awwright]

Becides being discussed before, bitcoin: addresses musn't be using // in them because it's not a network location, the syntax is described in RFC 2396

[Cdecker]

That's why we need moderators. The discussion about a unified URI schema for bitcoin now is spread over 7+ threads and it's getting really hard to follow the overall discussion.

Please continue discussing the bitcoin URI scheme here: http://bitcointalk.org/index.php?topic=55