URI-scheme for bitcoin

[sandos]

Also i'm quite reluctant using bitcoin:// prefix without having some kind of hierarchy involved ie //root/path/to/resource.

You're not alone, I guess, since you're not "supposed" to use // if your URI is not hierarchical. And I have to violently agree with this, don't use // for bitcoin-addresses unless they're domain-names!

[1714063758]

1714063758

[1714063758]

1714063758

[1714063758]

1714063758

[1714063758]

1714063758

[awwright]

Also keep in mind, whatever URI is designed, it really NEEDS to contain a public key hash in it or some other way of verifying the recipient. Sending to a random IP address, even if secured with SSL, can result in sending to the wrong person. Even if it's something like bitcoin://keyhash:IPaddress/?message=... you need to know that the correct person is at the other end of that encrypted communications like. This assumes that the Bitcoin send-to-IP will be encrypted.

[Cdecker]

Theymos went ahead and added his, previously pastebin hosted, schema definition to the Wiki, I guess we should really start thinking about merging all the ideas before someone start implementing the one rather than the other and we end up with completely incompatible URIs.

[Bruce Wagner]

Has this been decided?

       bitcoin:  

It's as simple as that.

Everything after the colon is negotiable.....?

It seems obvious to me that the components are:

• recipient bitcoin address  (mandatory)
• bitcoin amount  (optional)
• recurring - frequency  (optional)
• recurring - ends-on [never/until]  (optional)
• recipient addressbook label  (optional)
• message  (optional)

On the Bitcoin Client app (or web-based app)...  all these fields should be set as the DEFAULT data... but still editable.   First, the App asks for a password...  Then, presents the Send Money windows with all these values inserted as default values....  

Then, clicking Send should bring up an "Are You Sure?" dialog whenever the last transaction recipient's address is the SAME as the current transaction recipient's address (even if the last transaction was 3 weeks ago).   Unauthorized transactions, Accidental transactions, and Duplicate transactions must all be prevented by the app (at least asking for a password, and popping up an "Are You Sure?" warning).

Example...

       bitcoin:15kDhRAcpgsugmh6mQsTcCHdvbsuYncEEV?btc=25.50?=freq=monthly?=endson=never?label=Arvixe?message="We appreciate your business!"  


Why can't we simply start using this NOW.

Chromium and Firefox are open source.    Can't a browser plug-in handle adding the URI handling immediately.  If we can get the standard adopted by every computer in the future, great, but Bitcoin merchants already are invested enough to want to use such a standard.   And no one will be trying to click "Pay with Bitcoin" if they don't have a Bitcoin client installed (or a web-based hook plug-in installed).

The button can say:     "Pay with Bitcoin"    with a tiny link next to it, "What's Bitcoin?"     <--- to help those who don't know what bitcoin is

Can't this be implemented TODAY.... without asking anyone's "permission"...?

[The Madhatter]

Your recurring payment suggestion is too simplistic.

It should be able to do trials and up to 3 steps of billing. (Most sites don't need more than 3, we could make it unlimited I suppose).

Example: 4 BTC for the first 7 days, then 100 BTC every 30 days after that until canceled.

Example #2: 1 BTC for the first 90 days, 40 BTC every month for 6 months, until canceled.

There are lots of sites that really need to offer trials. If you leave them in the dark, Bitcoin will suffer.

[Bruce Wagner]

Your recurring payment suggestion is too simplistic.

It should be able to do trials and up to 3 steps of billing. (Most sites don't need more than 3, we could make it unlimited).

Example: 4 BTC for the first 7 days, then 100 BTC every 30 days after that until canceled.

There are lots of sites that really need to offer trials.

That sounds good... but even PayPal can't do that.   Let's at least get something up and working now.   I suppose additional parameters could be added as needed.

Like....

bitcoin:15kDhRAcpgsugmh6mQsTcCHdvbsuYncEEV?btc=4?=freq=daily?=endson=7?btc2=100?=freq2=monthly?=endson2=never?label=Arvixe?account=punl-9482054-3402?message="new trial subscription"?=processingdonation=0.02   

Obviously, we'd have to all agree on the format.... because the apps would have to build in functionality to handle such complex recurring transactions.  That's functionality that (obviously) does not exist in the clients today.   So those extra fields would simply be ignored in older clients that can't handle recurring payments.  Or clients that can only handle one level of recurring payment schedule.   I've never seen any mainstream app that can handle more than one recurring payment schedule as a single entry.   For example, PayPal can't do that.  Online bank bill-pay services can't do that.   They only do:    PAYEE, AMOUNT, and FREQUENCY.   That's it!   Not even an end date.

So....  we have to start somewhere.   Let's get the foundation built.   We can worry about the flooring and drapery choices a bit later.

I love that satoshi mentioned the idea of making this URI into a QR Code way back in July or something...  because I had the same idea.   ALL the new phones apps scan a QR Code, that the QR Code displayed at a store's cash register could contain all the specific details about THAT transaction.... maybe even a unique Bitcoin address just for that transaction...?  But for sure, an account number, invoice number, or some such number to automatically correlate your payment to your cash register sale.

Of course, online merchants' sites could automatically generate a new UNIQUE uri just for THAT SPECIFIC customer invoice also... all automated.

[The Madhatter]

That sounds good... but even PayPal can't do that.

Uhh.. Yes it can. It could always do that. It can rebill on subscriptions up to 3 levels deep. I know PayPal's API inside out and backwards.

If the Bitcoin recurring payment system can't do "trials" you can kiss 80% of the recurring business goodbye.

[konaya]

Setting up recurring payment schemes is a different problem, IMHO, and one that deserves to be dealt with separately.

Specifying recurring payments in the URI would be easy for simple payments like "once a month", but would be somewhat awkward in more advanced schemes. Specifying something like "4 BTC per day for the first 7 days, then 100 BTC every 30 days after that until canceled" in a variable=value fashion would be awkward at best, and it would be trickier to implement and harder to read for both humans and machines.

I would propose that recurring payments are dealt with separately, by putting together a payment scripting language. Consider this python-esque pseudocode:

Code:

function main(addr):
	for i in range(0,7): pay(addr,4)

	while isvalid(self):
		for i in range(0,30):
			if i == 0:
				pay(addr,100)
		

I'm not proposing that one will need to learn how to program to write a payment scheme. The actual scripting language could look something more like this:

Code:

pay 4 to [address] once every 1 day for 7 days
pay 100 to [address] once every 30 days

The above code snippet would be easy to read for humans and machines alike. My point is that URIs are good for defining variables, not for defining functions; payment schemes are functions. I suggest that recurring payments should be kept out of the URI specification altogether.

[Bruce Wagner]

Could a URI call such a function...?

Maybe a URI could specify a simple one-time payment OR a simple one-level recurring payment (like $60 per month for 12 months) OR it could call such a function (for fancy custom recurring scheduling)...?

Are we then expecting the Bitcoin client (app) to parse and process such a function?

That seems like a lot of burden to dump onto every Bitcoin app in existence.  No?

[Anonymous]

Could this be managed with mybitcoin setting up cronjobs that manage your deposited coins ?

[konaya]

Could a URI call such a function...?

A URI is only one way of interacting with Bitcoin. A function would presumably include the address, and they would both come in a file; hence, a MIME type. As I said, it's an unrelated problem with an unrelated solution.

Maybe a URI could specify a simple one-time payment OR a simple one-level recurring payment (like $60 per month for 12 months) OR it could call such a function (for fancy custom recurring scheduling)...?

Yes; simple scheduling could be specified in the URI. It will be somewhat crude, but it would work.

Are we then expecting the Bitcoin client (app) to parse and process such a function?

That seems like a lot of burden to dump onto every Bitcoin app in existence.  No?

Not really. There is a lot of things a decent Bitcoin app is expected to do already; why would this be any different? Or don't. Make it a separate scheduling program that interfaces with the main Bitcoin daemon. My point is: As Bitcoin grows, advanced scheduling functionality will be wanted. Then, various Bitcoin apps will develop this functionality on their own. And what would be the problem with that? No standardisation. On the other hand, if we specify a scripting language for advanced scheduling before the need arises, all future Bitcoin apps will (hopefully) follow that standard.