Bitcoin Forum
March 27, 2015, 06:55:13 AM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent] (New!)
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 [All]
  Print  
Author Topic: URI-scheme for bitcoin  (Read 12081 times)
ec
Newbie
*
Offline Offline

Activity: 7


View Profile WWW

Ignore
February 16, 2010, 08:51:42 PM
 #1

Hi, intrigued by the bitcoin-system, I have an idea:

The bitcoin addresses could be improved by implementing an URI-scheme like e.g. torrent magnet links.

So instead of 1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ, we could more unambiguous say bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ, and even configure browsers to redirect clicks on such links to a bitcoin client. This would allow one to implement "donate buttons" on homepages, "pay buttons" on webshops etc.

If an IP should be included, URIs allow this as bitcoin://HOST_OR_IP:PORT?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ. If wanted an amount could be specified as bitcoin:?amount=42.00;addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ (of course for the user to verify in the secure bitcoin-client).

Just my 0.02 ฿ (return them to bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ if you don't like them Wink)
1427439313
Hero Member
*
Offline Offline

Posts: 1427439313

View Profile Personal Message (Offline)

Ignore
1427439313
Reply with quote  #2

1427439313
Report to moderator
1427439313
Hero Member
*
Offline Offline

Posts: 1427439313

View Profile Personal Message (Offline)

Ignore
1427439313
Reply with quote  #2

1427439313
Report to moderator
Private Internet Access™ - No logs, Unlimited Bandwidth, PC Magazine's Editor's Choice
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1427439313
Hero Member
*
Offline Offline

Posts: 1427439313

View Profile Personal Message (Offline)

Ignore
1427439313
Reply with quote  #2

1427439313
Report to moderator
1427439313
Hero Member
*
Offline Offline

Posts: 1427439313

View Profile Personal Message (Offline)

Ignore
1427439313
Reply with quote  #2

1427439313
Report to moderator
ec
Newbie
*
Offline Offline

Activity: 7


View Profile WWW

Ignore
February 16, 2010, 09:09:40 PM
 #2

An URI-scheme could also be of use for implementing a mobile wallet with QR-codes, so that your buddy who wants to pay you X bitcoins don't have to enter your bitcoin-address manually, but only need to photograph the screen of your mobile phone.
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490


My avatar pic says it all


View Profile

Ignore
February 24, 2010, 02:37:55 AM
 #3

Yeah, I had totally thought of that too. A magnet link scheme would be awesome. Cheesy
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile

Ignore
February 24, 2010, 05:57:43 AM
 #4

That would be nice at point-of-sale.  The cash register displays a QR-code encoding a bitcoin address and amount on a screen and you photo it with your mobile.
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490


My avatar pic says it all


View Profile

Ignore
February 24, 2010, 06:39:16 AM
 #5

That would be so awesome... Smiley
Karmicads
Full Member
***
Offline Offline

Activity: 185



View Profile

Ignore
May 01, 2010, 06:06:53 AM
 #6

I'm wondering if anybody is doing anything about this idea, as I have been researching the possibility of implementing some Internet browser functionality, as per this thread and the wonderful developments described here. It seems that it may be easier first steps, (I'm learning as I go) to try this out and include it with whatever other features the Firefox add-on evolves.

Before this can happen there needs to be a consensus about what form the URI would take. I have done some quick research on the URI schemes and most approaches are frowned upon without W3C approval, there is one category whereby the W3C approves a tentative URI scheme and holds it in reserve, with no guarantees (like a provisional patent), but by far the most suitable scheme, seems to be the magnet URI, which was designed to find a resource by the hash being a product of its content uniqueness, rather than by specific address. Magnet was intended for use by applications on peer to peer networks and has reserved parameters for reference to application specific data. Basically, you simply preface the application specific parameter with an x as in xbitcoin1:?

Maybe it is good, not to try implementing a new top level URI scheme, as it is regarded as an ad lib maneuverer, if it is not recognized universally. Adopting the magnet system would avoid this, but in itself magnet is an informal, unregistered scheme. The beauty of magnet is that it can be shared and is open in that sense.

Now, that might all seem very good, because bitcoin is after all a P2P application and it's network does operate on similar principals, but what if the person clicking on the link is not a bitcoin user? What if you want to incorporate some information that is not carried in the existing network, such as the article being sold, shipping information and various other issues. My understanding is that bitcoin only handles the transaction itself, so the user is left to make all other arrangements, contracts and communications independent of bitcoin. Here's where the anonymity is compromised, because here, we are inclined to resort to conventional 'hierarchical  hardwired, or non-anonymous technologies. That's not a criticism of bitcoin by any stretch, because bitcoin is a fantastic way to transact, no question about it. But the transaction is only one side of the coin, if you'll pardon that cheesy pun. Grin

In the process of investigating URI's I was reminded of freenet and the magnet like system they use, and I ended up back there checking it out. Given that freenet is a user/identity-space intended for information storage, couldn't it also be used as a repository of human readable data files, particular and unique to each user, and incorporating any format of data you wish to use, for embellishing your transaction? Couldn't this be used for hooking the URI into a rich database of application specific data, that has been designed for the publishers own website functionality or business system? While your bitcoin node takes care of the actual transaction, the freenet node takes care of the individual data presented.

This should keep everything under the same kind of cryptographic P2P infrastructure, and allow infinite diversity of application specific context. I suppose a unique URI hash key, could be borne out of the combination of your freenet+bitcoin hashes and the file encrypted with your freenet key found by decrypting with your bitcoin key, while your bitcoin node can be addressed the other way around. Does that sound right? Of course, if you use your real identity on one, then I guess then, you real identity would be divulged on the other.

Anyhow, I'm sure there's some way to do it. Again, freenet also uses an unregistered URI scheme, but if a variant of magnet is adopted, that will not be a problem. The question remains, if people have hopes of bitcoin becoming a formal recognized currency and a very legitimate deal, then the strict adherence to all other internet protocols might be advisable. I have noted so far nothing in particular that would prevent the registration of a magnet/freenet like URI scheme. I haven't searched them all but one may even exist. Otherwise why not register one?

So the URI scheme needs to be agreed upon as to the classification (i.e. what kind magnet etc, as well do we go legit/formal or not) and format, such as how it is to be laid out:

Components Of A URI

This speaks to the conventions that Mozilla will account for in parsing a URI.

A typical magnet URI, looks like this

magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C

A freenet URI is like this:

http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf

To be recognized at all, the freenet program needs to be installed and this includes a Java powered web server that recognizes the resource as an item in identity space of the localhost. i.e. my browser sees the whole of freenet as being on my machine. I don't know if this identity space could be addressable without the user having to run a web-server, but I suspect the server is only for the ability to serve web pages as well as recognition of the localhost as the requisite top level domain. The 'http:' indicates that the freenet URI, is nothing special in itself, but the IP address (localhost) certainly is. I suspect a program can address the freenet user space, without incorporating a web server, and the universal links can be made as magnet URIs. As for those who don't have bitcoin installed, I don't know how the URI could be made to have a default fall back, to redirect visitors of that link. to the Sourceforge download for bitcoin. That may need to implemented in code and cookie or environ variable set to record the presence of bitcoin.

Other relevant sites I have visited in the course of this research include:


Any ideas/comments/feedback is/are welcome.  Wink
Steve

D҉ataWraith
Member
**
Offline Offline

Activity: 60



View Profile

Ignore
May 01, 2010, 01:40:37 PM
 #7

Before this can happen there needs to be a consensus about what form the URI would take. [snip] ...the most suitable scheme, seems to be the magnet URI, which was designed to find a resource by the hash being a product of its content uniqueness, rather than by specific address.
[snip]The beauty of magnet is that it can be shared and is open in that sense.

I think that using magnet-links just because they are already somewhat popular does not outweigh the disadvantages. Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.). Bitcoin would have to rely on application-specific xBitcoin-parameter(s), and since we probably don't want to mix files with bitcoin transactions in a single link, there's no really compelling reason not to use our own, seperate format, especially since magnet-links aren't officially recognized either.

Quote
In the process of investigating URI's I was reminded of freenet and the magnet like system they use, and I ended up back there checking it out. [snip] Couldn't this be used for hooking the URI into a rich database of application specific data, that has been designed for the publishers own website functionality or business system? While your bitcoin node takes care of the actual transaction, the freenet node takes care of the individual data presented.

Woah! Going from a lightweight URL-handler that brings up the Bitcoin client to requiring Freenet is a bit of a leap. This really should be optional.

However, it really would be very nice to add additional information to a transaction. Building on ec's initial post, and the need for further details, I think we should have the following url parameters (or shorter versions of them):

  • address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.
  • amount (optional): The amount to send.
  • message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)
  • details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.

1NvcPV6xi6yqo5yg8aWSkNdasPSAsGtt1m
Karmicads
Full Member
***
Offline Offline

Activity: 185



View Profile

Ignore
May 02, 2010, 02:15:51 AM
 #8

This just in:...

It seems there is, as it just so happens, an existing protocol precisely for interacting with stored data files on freenet  Grin <YAY!> Grin

Sorry, I'm not assuming that we must agree on the freenet URI functionality I suggested, just that It is exciting that it can be so readily incorporated, even for experimental purposes. Simply addressing a preconfigured freenet server should do the trick, but perhaps even the existing code can be slightly modified to directly address freenet (without the implicit web server included in the proper freenet install), but by including this FCP code, in the browser add-on, just the addressing and communicating functionality may be incorporated without the overhead of a full blown freenet http server. I assume at this point, the freenet web server, is only needed by the client for browsing freenet, not to service a node. As Bitcoin already addresses a similar P2P network, how hard would it be to make the bitcoin server do freenet inquiries? Could such trickery be included in the JSON intreface?
 
From: http://new-wiki.freenetproject.org/FCPv2

Quote
Purpose

The Freenet Client Protocol is a simple, text-based protocol designed to allow third-party applications to interact with Freenet. Supported functionality includes:

    * Inserting of data into Freenet
    * Retrieval of data from Freenet
    * Querying the status of Freenet
    * Managing the other Freenet nodes that are connected to your own node.


So, it seems you can pull data out of and post data into freenet at will.
Veeeeery interesting indeed.

Aside from that, in the course of looking for proxies or workarounds for freenet URI integration, I believe I solved an unrelated problem to do with my ISP blocking VoIP/SIP (as it's the local telco as well - and yes, I am changing providers very soon). I want VoIP, but my bastard anti-competitive ISP has crippled my modems firmware (which has an inbuilt 2 port analogue telephone adapter), and I hope this work around (Tor) gets past it (I'm not holding my breath) but  Link2VoIP, if you are reading this, I'm looking in your direction.  Wink
Karmicads
Full Member
***
Offline Offline

Activity: 185



View Profile

Ignore
May 02, 2010, 07:07:54 AM
 #9

Hi DataWraith

Quote
I think that using magnet-links just because they are already somewhat popular does not outweigh the disadvantages.


I hope I didn't give the impression that I either intend to use magnet links without more consideration of/ agreement with others, nor that my provisional support for them is based on their existing popularity. I'm honestly not into superficial popularity if I can help it. The reason to consider a magnet URI IMHO is owing to the Actual stated purpose and draft specifications

Quote
MAGNET is a work-in-progress URI specification, and collection
of standard practices/implementing code to allow a website to
seamlessly integrate with features made available by local
utility programs. In one way, it could be thought of as a
vendor- and project-neutral generalization of the "freenet:"
and "ed2k:" URI-schemes used by the Freenet and EDonkey2000
peer-to-peer networks, respectively.

It's stated purpose is specifically to allow websites to seamlessly integrate with features of local utility programs. It is intended to be vendor neutral and avoid having to reinvent the wheel and avoid further conflicts with other URI schemes. It also follows strong compliance with W3C standards and any scheme using the magnet convention would inherit that rigor.

Quote
NOTES ABOUT THE URI FORMAT:

  - Yes, it looks a little strange to have the "?" right after
    the ":", but by my reading of the relevant URL/URI RFCs,
    that fits the recommended common URI syntax well. (It also
    meshes nicely with the way the parameters are passed on to
    individual local apps.)

  - FYI, EDonkey URIs violate many provisos of RFCs 1738 and
    2396, including the use of "//" at the front of a non-
    hierarchical namespace and the use of illegal/disfavored
    (when not escaped) characters

  - Parameter names and values should officially be www-
    formencoded, just like HTTP web form GET submissions in the
    query-string, though in practice some characters that a
    strict reading of HTML-specs/RFC1738 would suggest should be
    encoded (like '.' and ':') seem not to be encoded.

  - The prefix 'x.' is reserved for application-specific new
    parameter experimentation. Any parameters not beginning 'x.'
    are only to be defined by official MAGNET specifications.

  - Other potential parameters might include a "fallback-
    location" for content that can't be found via P2P, P2P-
    system-specific identifiers (ed2k, sig2dat, freenet), other
    topic qualifiers ("length"), etc. These remain to be
    designed; comments wanted.


Quote
Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.).

Sorry DataWraith, but with all due respect, I have to disagree. The first issue is that files on a hard drive are mapped to a hierarchical namespace of nested locations, i.e. domains and directories. The fundamental difference, in approach of the many P2P networks is that the namespace is not hierarchal and the data it supports is referenced not by address but by the uniqueness of it's content. Whether the target is a file or anything else it's not referenced by a specific fixed address, but by the identity of it's unique contents. Identical files, are essentially the same identity and the P2P application can use multiple instances as multiple feeds to the same item. The parameters of magnet are well suited to any P2P application.

Quote

MAGNET URIS, ILLUSTRATED BY EXAMPLE:

(1)

  magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C

meaning: show me options pertaining to the "exact topic" (xt)
given by the supplied URI (specifically, an URN)

(2)

  magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&dn=Great+Speeches+-+Martin+Luther+King+Jr.+-+I+Have+A+Dream.mp3

meaning: show me options about this exact topic, but use
the included (unverified) "display name" for user convenience

(3)

  magnet:?kt=martin+luther+king+mp3

meaning: show me options about the "keyword topic" (kt)
given by the string

(4)

  magnet:?xt.1=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&xt.2=urn:sha1:TXGCZQTH26NL6OUQAJJPFALHG2LTGBC7

meaning: show me options about the two exact topics given

(5)

  magnet:?mt=http://weblog.foo/all-my-favorites.rss

meaning: show me the options for the "manifest topic" (mt)
fetchable via the given URI. This could also be an URN.
Manifest topics include lists of other items.



Quote
Woah! Going from a lightweight URL-handler that brings up the Bitcoin client to requiring Freenet is a bit of a leap. This really should be optional.

Well actually it's a URN handler and I didn't specify any limit to the 'weight' as you put it. I would be more concerned with robustness and not being painted into a corner myself. The effort to implement backward compatibility and forward extensibility, having been considered from the outset, is a small price IMHO. In any case I am only contemplating this, in the hope it can be done without installing freenet, at least the chunk of code needed to read and write to and from freenet should be much smaller if (as I suspect) the whole freenet web server is not needed. Also the URI should of course include this freenet functionality, as an optional parameter. So if not specified, the information to do the basic transaction would still be legitimate. It would not then be compulsory to use in publishing the URI, but the handler should still be able to take the parameter if it is used, otherwise the optional choice you are proposing is between two different incompatible URI schemes. Measure twice, cut once.

Quote
However, it really would be very nice to add additional information to a transaction. Building on ec's initial post, and the need for further details, I think we should have the following url parameters (or shorter versions of them):

    * address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.
    * amount (optional): The amount to send.
    * message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)
    * details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.

Not sure what you mean by address, other than the 'address' that is provided by your bitcoin signature (which is more like a name than a place). I cant see how you can hand out different addresses to different people, unless you already have some aliases defined. So you are suggesting an added naming system to encode and translate aliases for a bitcoin node, is that what you mean? That could be done without too much hassle I suppose.

The amount: Yup goes without saying.

Message: This is where URI data becomes unwieldy. A message is implicitly a useful amount of human communication, which was never intended to be delivered in the URI itself. The need to reference a supplementary document begins here. The payer can send their message in the software interface (either the standalone program or the Firefox add-on), The link, at a minimum, identifies the recipient and the amount, that must be passed to the software. If the receiving party wants to communicate some text, then they can do so in the document they are publishing (IE. where they are publishing the link). The text for the sending party, can use the normal route, as the link invokes the bitcoin interface and that provides the field to include a note. What message needs to be passed by the receiver (payee) that is not possible in the document in which they are publishing the link? What message needs to be passed by the payer, that is not possible in the interface, but is possible by clicking on the link? That would imply that the link invokes methods like post or get, that are exclusively http/s functionality, that is defeating the purpose of having a purpose made URI scheme. Post and Get functions need to be addressed within the hierarchical namespace of TCP/IP and/or physical file path names.

Details: I advocated from the outset, the desirability of the URI scheme, being able to reference a document with a richer data structure, that can be used to embellish upon the basic essential information passed by the obligatory parameters. I also suggested a proposed repository for those documents which lead to some accessibility issues, but if solved would enhance the anonymity of the bitcoin node and circumvent the reliance on non-P2P or hierarchical namespace. The possibility of taking a beautiful network addressing protocol and remapping it with (or kludging it onto) a regressive, inferior, butt ugly one, which requires all entities to adopt the analogy of a fixed location, and loose all hard wired associations if they are shifted, seems to me as tactful as giving a beautiful stone building a coat of cheap plastic paint; bright green paint. A URL for a parameter, Is precisely the kind of butchery I would rather avoid, because a URL is not a URN and the namespace it addresses, is hierarchical and must ultimately reside at a fixed IP.

As far as this "you could also link to freenet, i2p and tor to keep things anonymous." is concerned, you clearly haven't given it much thought. If I could just link to freenet, then I could just as easily incorporate freenet as the actual repository referenced in the URI to begin with. That's the problem. You can't just store files on freenet, and expect anybody to be able to retrieve them with a URL or a URN, on a regular website, unless the visitor has the client software to handle the link, the reference it gives will be useless. If I can make the URI handler address the freenet namespace, then I suggest it would much better to store the files there in the first place. Because http/s operates on a hierarchical namespace and P2P clients operate on non-hierarchical namespace, the one parameter can't be used to interdependently address both. It's a bit late for you to decide to become anonymous after you have fixed your identity to a physical locus.

If I have misunderstood you I apologize DataWraith, but you don't seem to appreciate the difference between the two namespace models, nor their relative advantages and liabilities. I am sill quite willing to consider any other system of schema. I am not rejecting your criticism out of hand, nor insisting my own preferences should be the default. I would prefer to simply make the best URI scheme possible regardless. Thanks for your consideration all the same.


EDIT:

Re my comment "The amount: Yup goes without saying." I take that back. I was thinking in terms of links only as instigators of payment events, but of course, if the amount and other parameters are left blank, it should then default to acting as an identifier link to instigate a payment at the behest of the payer. A simple donate button would only need one parameter and zero redirections/login/confirmation/calculate and change currency before you can finally send, to not see your transaction eating the dust of snailmail on horseback, in the event that you don't have a credit card. (Suck on that that PlayPal). That, along with the naming alias idea suggested by DataWraith AKA (having an address), if that;s what you meant DataWraith, is certainly worth implementing for my bitcoin.  Wink
D҉ataWraith
Member
**
Offline Offline

Activity: 60



View Profile

Ignore
May 02, 2010, 11:13:09 AM
 #10

Karmicaids, thanks for taking the time for such a detailed reply.

It seems there is, as it just so happens, an existing protocol precisely for interacting with stored data files on freenet  Grin <YAY!> Grin

Oh, I thought you meant that when you spoke of using freenet. The user runs freenet and Bitcoin would communicate with it using its control protocol. However, running Freenet requires considerable computer resources, especially bandwidth, and personally, I do not want to run a freenet node for that reason alone. That's why I wanted this to be optional.

Quote
I hope I didn't give the impression that I either intend to use magnet links without more consideration of/ agreement with others, nor that my provisional support for them is based on their existing popularity.

I had the impression that you did not want to re-invent the wheel, and that's why popularity played a part -- that the existing acceptance of magnet links in other software was a plus.

Quote
Quote
Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.).

Sorry DataWraith, but with all due respect, I have to disagree. The first issue is that files on a hard drive are mapped to a hierarchical namespace of nested locations, i.e. domains and directories. The fundamental difference, in approach of the many P2P networks is that the namespace is not hierarchal and the data it supports is referenced not by address but by the uniqueness of it's content. Whether the target is a file or anything else it's not referenced by a specific fixed address, but by the identity of it's unique contents. Identical files, are essentially the same identity and the P2P application can use multiple instances as multiple feeds to the same item. The parameters of magnet are well suited to any P2P application.

Okay, sorry, seems I haven't made entirely clear what I mean here. I'm aware of how magnet links refer to content, rather than a location in a hierachical namespace.

Perhaps it's just a difference of mental models: For me, a bitcoin transaction is, for lack of better words, not a thing so much as a process. In my mind, magnet links refer to things (usually a file -- whether by content hash or by location), and trying to use them to refer to a process strikes me as a little awkward. Magnet links identify things you then have to go fetch, while a bitcoin transaction is completely described by the link itself (although you still have to say "Yes, send the coins." once you click the link).

To me it seems that using magnet links would be to (ab)use them for something they were not meant to describe, as they orignated as a replacement for ed2k://, freenet://, et al., describing how to get a file.

A bitcoin-link should be more like mailto: than magnet: IMHO.

Quote
Well actually it's a URN handler and I didn't specify any limit to the 'weight' as you put it.

Yeah, my mistake, sorry.

Quote
In any case I am only contemplating this, in the hope it can be done without installing freenet, at least the chunk of code needed to read and write to and from freenet should be much smaller if (as I suspect) the whole freenet web server is not needed.

IIRC the web server is pretty much integrated into Freenet itself. You can use the simpler FCP protocol to talk to a Freenet instance, but because of the type of content on Freenet, not many people are willing to host a publicly accessible instance, so you would have to run your own. I don't begrudge that you want to be able to do this, I'm just not willing to do it myself. I'd much rather host a TOR hidden service -- that's why I suggested to use a general, full-featured URL as the details parameter, instead of making it freenet specific.

Quote
Quote
    * address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.
    * amount (optional): The amount to send.
    * message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)
    * details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.

Not sure what you mean by address, other than the 'address' that is provided by your bitcoin signature (which is more like a name than a place). I cant see how you can hand out different addresses to different people, unless you already have some aliases defined. So you are suggesting an added naming system to encode and translate aliases for a bitcoin node, is that what you mean? That could be done without too much hassle I suppose.

Well, yeah, I meant the bitcoin signature. I called it address, because that's what it says in the bitcoin client (i.e. "Change your address"). I indeed thought that one should use different aliases, just like the exchange sites currently do: You get an address (or signature, or whatever) to send coins to, and because that address was only given to you, the recipient knows the payment is from you.

A system to translate aliases would of course be nice, but I think that's better handled with an address book or mybitcoin.com or something.

Quote
Message: This is where URI data becomes unwieldy. A message is implicitly a useful amount of human communication, which was never intended to be delivered in the URI itself. If the receiving party wants to communicate some text, then they can do so in the document they are publishing (IE. where they are publishing the link). The text for the sending party, can use the normal route, as the link invokes the bitcoin interface and that provides the field to include a note. What message needs to be passed by the receiver (payee) that is not possible in the document in which they are publishing the link?

Yes, exactly! The text for the sending party can use the normal route. But what if I want to pre-specify the text that should be sent?

This has an analogue in mailto:-links: If you want someone to send you an email, you can also specify a subject he/she should use: mailto:alice@example.org?subject=Test. So if I am selling something on, say, ebay, I can give the buyer a bitcoin link that includes the message "Payment for Ebay auction #12345", so he/she does not have to enter it themselves, possibly making a mistake if the code is more cryptic than #12345.

Quote
Details: I advocated from the outset, the desirability of the URI scheme, being able to reference a document with a richer data structure, that can be used to embellish upon the basic essential information passed by the obligatory parameters. I also suggested a proposed repository for those documents which lead to some accessibility issues, but if solved would enhance the anonymity of the bitcoin node and circumvent the reliance on non-P2P or hierarchical namespace. The possibility of taking a beautiful network addressing protocol and remapping it with (or kludging it onto) a regressive, inferior, butt ugly one, which requires all entities to adopt the analogy of a fixed location, and loose all hard wired associations if they are shifted, seems to me as tactful as giving a beautiful stone building a coat of cheap plastic paint; bright green paint. A URL for a parameter, Is precisely the kind of butchery I would rather avoid, because a URL is not a URN and the namespace it addresses, is hierarchical and must ultimately reside at a fixed IP.

Sorry, I mistakenly tend to use the terms URI, URL, etc. interchangeably because you enter it into the address bar %). Again, sorry if this lead to confusion.

What I wanted here was to make this additional information general. Some examples might clarify this:


The creator of the link chooses where to put the additional details, and the recipient decides whether he needs the supplemental information badly enough to install Freenet/Tor/I2P. That's one of the reasons for including a short message in the link itself: the additional information should not be critical to the transaction.

Quote
As far as this "you could also link to freenet, i2p and tor to keep things anonymous." is concerned, you clearly haven't given it much thought. If I could just link to freenet, then I could just as easily incorporate freenet as the actual repository referenced in the URI to begin with.

But wouldn't that make the use of Freenet mandatory? I would like this to stay more flexible.

Also, if I were to run an online shop, I'd rather have people look the details up on my own website rather than them having to install freenet. That might also link my shop's reputation with Freenet, which given Freenet's reputation, might be undesirable.

Quote
That's the problem. You can't just store files on freenet, and expect anybody to be able to retrieve them with a URL or a URN, on a regular website, unless the visitor has the client software to handle the link, the reference it gives will be useless.

Yup. That's another reason for wanting to also allow normal HTTP(S) URLs. If I have not misunderstood, you seem to want to make the use of Freenet for transactions mandatory, which is something I strongly disagree with.

Quote
Because http/s operates on a hierarchical namespace and P2P clients operate on non-hierarchical namespace, the one parameter can't be used to interdependently address both. It's a bit late for you to decide to become anonymous after you have fixed your identity to a physical locus.

Not every single transaction needs bulletproof anonymity. Think Open Source projects receiving donations, or online shops. If you (a) need more details than the short message parameter provides, and (b) you want to be totally anonymous, you can just specify a freenet or Tor or I2P-URL (or URN? -- this is confusing :-/ ). If you don't need the added anonymity, you don't have to make the effort to run Freenet/Tor/I2P/whatever.

Quote
If I have misunderstood you I apologize DataWraith, but you don't seem to appreciate the difference between the two namespace models, nor their relative advantages and liabilities. I am sill quite willing to consider any other system of schema. I am not rejecting your criticism out of hand, nor insisting my own preferences should be the default. I would prefer to simply make the best URI scheme possible regardless. Thanks for your consideration all the same.

Well, we're all together in this. I just hope to arrive at the best possible system. :-)

Thank you for your thorough explanation, and patience with my suggestions.

1NvcPV6xi6yqo5yg8aWSkNdasPSAsGtt1m
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile

Ignore
May 16, 2010, 10:37:21 PM
 #11


There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>

Bitcoin can answer port 8330 on local loopback just as it does for JSON-RPC on 8332.  It would give an HTTP answer.


A bitcoin-link should be more like mailto: than magnet: IMHO.

I think we can do that.

Although it would be possible for Bitcoin to take care of business in the HTTP response by presenting HTML UI to the user, as a user I would wonder if some website is trying to trick me or if I'm really talking to my own Bitcoin server.

The HTTP response could simply be HTML with the JavaScript equivalent of the back button, sending it back to the page.  Bitcoin then pops up the Send Bitcoins dialog with the destination bitcoin address and amount already filled in.  It would work just like a mailto: link that pops up a new email with the address filled in.

127.0.0.1 loopback is accessible by any user on the machine, it doesn't have per-user separation, but it's OK because it would only serve the convenience function of pre-filling the fields in a dialog.  You'd still have to press Send.  We'd have to make sure the Send button is not selected so it couldn't jump into the foreground while you're typing a space or enter.


lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile

Ignore
June 11, 2010, 02:51:56 PM
 #12

There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>
That's a very pragmatic answer. I like it.

However, how would that work with the combined IP / Bitcoin Address URI (URN? URL?) scheme described here?
[link]http://bitcointalk.org/index.php?topic=158.msg1322#msg1322[/link]

I know it's been nearly a month, sorry.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1AFTbit16o6FNg2msnAbXVR2G3EVTWefmc
Vanity .onion address service - <8 character addresses free!
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile

Ignore
June 16, 2010, 12:15:47 AM
 #13

http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345
or
http://127.0.0.1:8330/?to=<bitcoinaddress><separatorchar>1.2.3.4&amount=200.00

But as long as the link is already doing the typing for you, I don't see much benefit in using a domain address instead of bitcoin address.  With a bitcoin address, the user can't send an unidentified payment.  They can't send payment until they've been given a correct bitcoin address to send to.

What would be nice about sending by domain is you could visually verify who it's going to.


A more crucial issue is what if the browser isn't allowed to connect to 127.0.0.1:
http://bitcointalk.org/index.php?topic=63.msg1589#msg1589

and if that's true, then what about that example freenet link that had 127.0.0.1 in it?
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile

Ignore
June 16, 2010, 06:14:05 AM
 #14

But as long as the link is already doing the typing for you, I don't see much benefit in using a domain address instead of bitcoin address.  With a bitcoin address, the user can't send an unidentified payment.  They can't send payment until they've been given a correct bitcoin address to send to.

What would be nice about sending by domain is you could visually verify who it's going to.
I think that hiding the complexity of Bitcoin addresses from the casual user is a good thing. Barring that, it should be possible to embed an observable but unalterable message with address transactions. Is there some reason this is technically infeasible?

A more crucial issue is what if the browser isn't allowed to connect to 127.0.0.1:
http://bitcointalk.org/index.php?topic=63.msg1589#msg1589

and if that's true, then what about that example freenet link that had 127.0.0.1 in it?
I think you're misunderstanding the issue. My browser will always be able to go to 127.0.0.1 (barring some strange IE settings or a virus). If I type the address into the URL bar or click a link, it will work fine. However, it isn't possible to use Javascript to complete POST requests between domains (or ports on the same domain).

Try clicking this link:
http://127.0.0.1/
You probably don't see anything (unless you're running a web server on your system), but the browser happily tries to take you there.

XMLHTTPRequest is what we were discussing in that other thread.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1AFTbit16o6FNg2msnAbXVR2G3EVTWefmc
Vanity .onion address service - <8 character addresses free!
sirius
Bitcoiner
Staff
Sr. Member
****
Offline Offline

Activity: 429



View Profile

Ignore
June 16, 2010, 08:26:14 AM
 #15

Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.

Identifi - Decentralized address book with trust ratings
I'm not a forum admin - please contact theymos instead.
bencoder
Member
**
Offline Offline

Activity: 90


View Profile

Ignore
June 16, 2010, 12:59:40 PM
 #16

Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.

You could do an iframe that pointed to something like http://127.0.0.1:8330?pay=domain.com&amount=x&return=<wheretoreturn.php> and then that iframe would contain a little bitcoin interface stating how much & who you're paying and a button to confirm or cancel the payment. If you confirm the payment then it sends the coins to the domain and then redirects to the return value in the query string. bitcoin could add a ?paid=true or ?paid=false to the return location as well so the return script on the domain could then check if it received the payment correctly, or cancel the order.

Edit: the bitcoin interface should also have a password before you can confirm the payment. Otherwise you could scan for port 8330 being open on anybody and then automatically have it send payments.
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile

Ignore
June 16, 2010, 07:38:32 PM
 #17

Edit: the bitcoin interface should also have a password before you can confirm the payment. Otherwise you could scan for port 8330 being open on anybody and then automatically have it send payments.
That's not exactly true. At the moment, Bitcoin only binds RPC to the loopback interface, 127.0.0.1. I would assume that this web interface would be the same. However, there SHOULD be a password to prevent trojans from trivially sending your wallet away. Wallet encryption needs to happen, too.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1AFTbit16o6FNg2msnAbXVR2G3EVTWefmc
Vanity .onion address service - <8 character addresses free!
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile

Ignore
July 18, 2010, 04:06:16 PM
 #18

I think you're misunderstanding the issue. My browser will always be able to go to 127.0.0.1 (barring some strange IE settings or a virus). If I type the address into the URL bar or click a link, it will work fine. However, it isn't possible to use Javascript to complete POST requests between domains (or ports on the same domain).
That's what I thought too.

Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.
Now I'm hearing a report that it IS possible for javascript to do a cross-domain POST request to 127.0.0.1.  Not other domains, but just specifically to that one.  Great...

If this is the case, then do not use the -server switch or bitcoind on a system where you do web browsing.

I'll get started on adding the password field.
melvster
Sr. Member
****
Offline Offline

Activity: 314


View Profile

Ignore
July 21, 2010, 12:47:06 PM
 #19

I'm wondering if anybody is doing anything about this idea, as I have been researching the possibility of implementing some Internet browser functionality, as per this thread and the wonderful developments described here. It seems that it may be easier first steps, (I'm learning as I go) to try this out and include it with whatever other features the Firefox add-on evolves.

Before this can happen there needs to be a consensus about what form the URI would take. I have done some quick research on the URI schemes and most approaches are frowned upon without W3C approval, there is one category whereby the W3C approves a tentative URI scheme and holds it in reserve, with no guarantees (like a provisional patent), but by far the most suitable scheme, seems to be the magnet URI, which was designed to find a resource by the hash being a product of its content uniqueness, rather than by specific address. Magnet was intended for use by applications on peer to peer networks and has reserved parameters for reference to application specific data. Basically, you simply preface the application specific parameter with an x as in xbitcoin1:?


This looks very cool!

I'm part of the dev team that works with Tim Berners-Lee of the W3C on web standard based projects.

I can run the idea of a bitcoin scheme being registered by some of the folks there ... but to be honest it may be overkill for what you need.

Why not use RDF(a) to model a bitcoin address in, for example, HTML5.

You just need either 1) a very simple ontology

<meta property="bitcoin:address" content="u34827uirhe243" />

Or use the FOAF and SOIC ontologies via OnlineAccount.

I've posted some notices to some of the W3C folks this morning, as well as the GNU Social / Diaspora working with the FSF, and the payswarm folks that are looking to standardize micorpayments.

Bottom line, I think the markup is very easy to capture the semantics of bitcoin in HTML.  

Love the project, hope we can all work something out! Smiley
darkskiez
Newbie
*
Offline Offline

Activity: 10


View Profile

Ignore
July 21, 2010, 12:47:59 PM
 #20


Using http://127.0.0.1:[bitcoinwebport]/whatever is a bit limiting, it requires that the user has the bitcoin client, and that the client is running.

Using bitcoin:?whatever however allows us to add a uri handler to the browser, so it launches the client with the information if it is not running, or opens a window if it is running.
In addition it allows websites to be registered as URI handlers, so people could register mybitcoin or other wallet service providing website to handle the request for them, without requiring the application. I find this a compelling argument to standardise on this style.


melvster
Sr. Member
****
Offline Offline

Activity: 314


View Profile

Ignore
July 21, 2010, 01:32:30 PM
 #21

I've inquired about this ...

From Dan Conolly

Quote
DanC: the URI scheme list is shared by the whole internet community, so you have to get them all to agree that it's a reasonable idea. It rarely is, though the URI scheme list _does_ have a gap around truely decentralized naming.

Let's see where it goes ...
HostFat
Staff
Legendary
*
Offline Offline

Activity: 1666



View Profile WWW

Ignore
July 22, 2010, 03:53:27 AM
 #22


Using http://127.0.0.1:[bitcoinwebport]/whatever is a bit limiting, it requires that the user has the bitcoin client, and that the client is running.

Using bitcoin:?whatever however allows us to add a uri handler to the browser, so it launches the client with the information if it is not running, or opens a window if it is running.
In addition it allows websites to be registered as URI handlers, so people could register mybitcoin or other wallet service providing website to handle the request for them, without requiring the application. I find this a compelling argument to standardise on this style.
Yes, I hope that you will add support to some URI-scheme while you are adding password support here: http://bitcointalk.org/index.php?topic=461.20

As online most secure Bitcoin wallet I currently advise Greenaddress - A good exchange / gateway Ripple, with support for multisig, since 2007: The Rock Trading (ref)
VENDO BITCOIN | CONTANTI - POSTEPAY - ALTRO | HOSTFAT.TK - 370-3244934 - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
bytemaster
Hero Member
*****
Offline Offline

Activity: 630

BitShares


View Profile WWW

Ignore
August 05, 2010, 03:12:28 PM
 #23

My proposal

bitcoin://btcaddress?name="address book name",amount=100.0

It contains all of the information necessary to send someone some money and lets the web browser launch the program.  A bitcoin "installer" could associate bitcoin:// with various web browsers / operating systems.


The above syntax also supports

bitcoin://IP:port?name=blah,amount=100,message=

Either way the bitcoin client is launched on the users machine (or a mybitcoin website is brought up) and all the information is entered with the option of adding the destination to your address book.

HostFat
Staff
Legendary
*
Offline Offline

Activity: 1666



View Profile WWW

Ignore
August 06, 2010, 01:05:16 PM
 #24

My proposal

bitcoin://btcaddress?name="address book name",amount=100.0

It contains all of the information necessary to send someone some money and lets the web browser launch the program.  A bitcoin "installer" could associate bitcoin:// with various web browsers / operating systems.


The above syntax also supports

bitcoin://IP:port?name=blah,amount=100,message=

Either way the bitcoin client is launched on the users machine (or a mybitcoin website is brought up) and all the information is entered with the option of adding the destination to your address book.
yes please! Add some supports to these kind of URI!
Now that we have password support, this is next step to do imho Cheesy

As online most secure Bitcoin wallet I currently advise Greenaddress - A good exchange / gateway Ripple, with support for multisig, since 2007: The Rock Trading (ref)
VENDO BITCOIN | CONTANTI - POSTEPAY - ALTRO | HOSTFAT.TK - 370-3244934 - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
HostFat
Staff
Legendary
*
Offline Offline

Activity: 1666



View Profile WWW

Ignore
August 16, 2010, 12:45:33 AM
 #25

Another idea:
A way to simple add a node while the client is already running and/or the newbie user doesn't know how to add something in the command line Cheesy
Code:
bitcoin://IP:port?addnode=1
( it's only the idea, you can suggest a better text to do the same thing Wink )

EDIT:
Situation without amound
bitcoin://IP:port?name=blah,message=
bitcoin://btcaddress?name="address book name"

Bitcoin will show the box "Send coins" with the b-address already written.
The user will have only to write the amount.
This will be good to make it easy random donations: ex: forum firms

My personal idea is that a project involving money needs before everything to be EASY to customers ( normal users ) than developers/sellers
So, I think that URI-scheme ( and autoupdate/warning message features ) must have an high priority than new apis support, better hashing and so on.
( as I said this is my personal idea Wink )

As online most secure Bitcoin wallet I currently advise Greenaddress - A good exchange / gateway Ripple, with support for multisig, since 2007: The Rock Trading (ref)
VENDO BITCOIN | CONTANTI - POSTEPAY - ALTRO | HOSTFAT.TK - 370-3244934 - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
17ujzChRb6VPQGyANVyktc1du
Guest

August 16, 2010, 06:16:27 PM
 #26

I don't see what good would bring a clickable link to add a node. Only advanced users would need this, and it will only lead to abuses. I only see bitcoins URI as a mean of payment.
Also i'm quite reluctant using bitcoin:// prefix without having some kind of hierarchy involved ie //root/path/to/resource.
I think it is better to look at something like data URI (http://en.wikipedia.org/wiki/Data_URI_scheme) :
Code:
data:[<MIME-type>][;charset=<encoding>][;base64],<data>
An other problem is format of numbers 100,0 vs 100.0 etc

Code:
bitcoin:period=12,monthly;address="me":17ujzChRb6VPQGyANVyktc1du2Hrjfwhsz,"friend":1FaBVwRg99UcH332AV6BSWmDCnTRHdro5B;amount=1.23;title="subscription to bitwow"
would ask 12 monthly payments of 1.23 to me & friend (ie i spent 12*2*1.23 in one year).

Of course except address nothing should be mandatory.

You could just write <a href="bitcoin:17ujzChRb6VPQGyANVyktc1du2Hrjfwhsz">Send me bitcoins !</a> to get a one shot payment to any amount anonymously.
HostFat
Staff
Legendary
*
Offline Offline

Activity: 1666



View Profile WWW

Ignore
September 16, 2010, 11:43:55 AM
 #27

Is there someone that can develop a patch to support these URI-schemes ?
how much will it cost?

As online most secure Bitcoin wallet I currently advise Greenaddress - A good exchange / gateway Ripple, with support for multisig, since 2007: The Rock Trading (ref)
VENDO BITCOIN | CONTANTI - POSTEPAY - ALTRO | HOSTFAT.TK - 370-3244934 - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
LZ
Staff
Legendary
*
Offline Offline

Activity: 1204


Satoshi everywhere!


View Profile WWW

Ignore
September 16, 2010, 02:14:24 PM
 #28

As far as I know, Satoshi and the Bitcoin community did not accept any specific URI-scheme yet.
In future it may be x-btc:, bitcoin:, https: or still http:. Or we will invent something much better.
I think that it is so early to use one of these ways before an internal standard will be accepted...

"Never invest unless you can afford to lose your entire investment."  ©  S3052
Feel free to contact me using Tox: 1EC1F6C383802827336F7CA03E0E6886356634457A4E70C3CE2807C6F4D46A79FD0B583EA33A
mizerydearia
Hero Member
*****
Offline Offline

Activity: 574



View Profile

Ignore
October 04, 2010, 01:53:59 AM
 #29

Is there someone that can develop a patch to support these URI-schemes ?
how much will it cost?

I'll add 5btc reward to provide this functionality.  Additionally I will donate 5btc for Bitcoin Payment Request mime type.  Anyone else interested in offering additional bounty to help inspire to have these developed sooner than later?
davux
Sr. Member
****
Offline Offline

Activity: 289


Firstbits.com/1davux


View Profile WWW

Ignore
November 10, 2010, 01:46:38 AM
 #30

In any case, a bitcoin address is an URI (idenfier), not an URL (locator). By nature Bitcoin has no notion of location, it only deals with identifiers.

So if we want to represent a bitcoin identifier, it shouldn't have "//" in the address. It's like a mailto:foo@bar.com or xmpp:foo@bar.com address. The simpler form would be something like bitcoin:1MYaBk1s6jjtJyXsErDU9F9JBLZLeihVit (but of course it should allow a name so that people can add it to their addressbook, an amount for sending bitcoins, etc.).

1DavuxH9tLqU4c7zvG387aTG4mA7BcRpp2
México (Oaxaca) – France - Leeds
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW

Ignore
November 14, 2010, 06:52:37 PM
 #31

I'm pretty interested in having a good URI schema for Bitcoin addresses. I think the most fitting would be somthing like this:
Quote
bitcoin:1U1jTCGkQYRaDVStZdDHMFWUMoSJi4HSc?dn=MyAddress&amount=10.00&ref=http%3A%2F%2Fblog.snyke.net%2F
Why? The address is clearly the only really important thing about these URIs, everything else is just cosmetics it is therefore comparable to the authority in URLs. Everything else is just additional (optional) parameters. Some common ones should include:
  • dn: descriptive name, a name for the address, so that it is easier to recognize in the address book
  • amount: only really interesting when actually having a payment (think about an invoice)
  • ref: a URI to the resource containing details about the transaction (only in combination of amount). For example to point to the invoice
Of course I'm open to suggestions :-)

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
slush
Legendary
*
Offline Offline

Activity: 1316



View Profile WWW

Ignore
November 20, 2010, 06:46:21 AM
 #32

I'm interested in bitcoin URI too. My vote is for bitcoin:1CFV3fjDzf9iCTD3TCfmhfgghgD3CbFS3K?optional_parameter=value where optional parameter can be amount etc. It perfectly matches original idea of URI.

But I'm writing here mainly because I found that this topic is relevant also with "dns lookups" issue here http://bitcointalk.org/index.php?topic=1785.msg22998#msg22998 . I think both activity should be joined - this thread should find widely acceptable form of URI/something and they should reuse this form for encoding for automatic lookups (and I vote for my method of HTML tags in this topic, of course Smiley ).

It would be great to code these features to client only once, not as two separate things
a) some kind of URI pasted from web sites (this thread)
b) another kind of lookups from DNSes and it's proprietary form of wallet ID encoded here.

Marek

Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW

Ignore
November 21, 2010, 03:18:42 PM
 #33

So shall we put it to vote which URI schema is to be used and promoted by us (the Bitcoin Forum users)?

Putting things together options are:
  • bitcoin://IP:port?addnode=1 only applicable to directly invoke commands on a running mainstream client
  • http://127.0.0.1:8330/?to=<bitcoinaddress><separatorchar>1.2.3.4&amount=200.00 again quite limiting
  • bitcoin:1U1jTCGkQYRaDVStZdDHMFWUMoSJi4HSc?dn=MyAddress&amount=10.00 Bitcoin address as main information, everything else is optional
  • bitcoin:period=12,monthly;address="me":17ujzChRb6VPQGyANVyktc1du2Hrjfwhsz,"friend":1FaBVwRg99UcH332AV6BSWmDCnTRHdro5B;amount=1.23;title="subscription to bitwow" same as above but without the address as main entity and with colons, semi-colons and commas as separator (basically a hash set)

Did I miss something?

Also I think before voting we all should agree on what resource (URI is Uniform Resource Identificator) we are actually trying to describe. The first few proposals concentrated on how to issue commands to the mainstream client, whereas the latter (to which I personally tend) try to describe a bitcoin address, along with additional information, that could be added to an address book and could be printed to receipts or invoices.

I'll start a poll once we gathered all proposals  Grin

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
slush
Legendary
*
Offline Offline

Activity: 1316



View Profile WWW

Ignore
November 21, 2010, 03:34:14 PM
 #34

Didn't miss anything important in your list.


I like a possibility to encode not just address and address, but also a periodicity. Why not to combine both methods - take standard format of URI and parameters for period payments from second obscure notation? Something like

bitcoin:<address of recipient>?acount=10.00&period=12,monthly&next_variable=

I vote for removing 'sender address'. We can discuss how often anybody needs to catch both side of transaction (seller address and buyer address) in constant URI? Paypal subscription links also contains only receiver's information and metainformation about payment (amount, period etc). It is on the client side which his wallet he will use for transaction.

So when you notice that URI format can also keep information about period payments, I think it is far best notation. But create poll and we will see if I'm not alone with my attitude Smiley.

theymos
Administrator
Legendary
*
expert
Online Online

Activity: 1876


View Profile
November 21, 2010, 06:25:31 PM
 #35

Did I miss something?

http://pastebin.com/VsBbmXQx

mikegogulski
Sr. Member
****
Offline Offline

Activity: 358



View Profile WWW

Ignore
November 22, 2010, 02:24:59 AM
 #36

Friends,

I agree most emphatically that a URI scheme for bitcoin is necessary and desirable.

That said, one of the most important things on the topic was presented by karmicads above in including a diagram entitled "components of a URI".

A "URI scheme" is an extremely simple thing. RFC 3986 (http://tools.ietf.org/html/rfc3986#page-17) defines a URI Scheme in ABNF as

scheme      = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

IANA maintains the official registry of (officially registered) URI schemes. The current list is at http://www.iana.org/assignments/uri-schemes.html. One will note that, for example, neither magnet nor freenet appear, despite their rather widespread deployment. Likewise skype:, callto:, aim:, and so on.

So, when we are talking about a URI scheme for Bitcoin, please forget about anything that might come after a colon, a slash, a question mark, an ampersand or a semicolon!

I've seen three concrete proposals for a Bitcoin URI scheme on this thread:

  • bitcoin
  • btc
  • x-btc

Personally, I think that "bitcoin" is the only appropriate option. We could, on this forum, agree right now that "bitcoin" will be Bitcoin's URI scheme, promulgate that fact and begin using it. I will create a specific thread for comments on this proposal right after I post this message.

At the point when someone can persuasively make the case in a formal application against the criteria set out in BCP35 (http://tools.ietf.org/html/bcp35), that URI scheme can become officially registered.

With regards to the term "URI scheme", remember: everything after the colon is irrelevant!

Now I've stepped in it for sure. Certainly there are very important details remaining regarding how URIs utilizing the bitcoin: URI scheme would be implemented (see theymos above) and how the decisions regarding those details would be made.

Based on this, and at the risk of being overly pedantic, I respond to Satoshi above: anything starting with http: can't be a Bitcoin URI. What you're getting at there, rather, is a URI format intended to be used as a template for communicating with a local Bitcoin server over the HTTP protocol. It would seem that most of the capability described there has been implemented via the JSON-RPC interface, though via POST rather than a GET.

PS: Datawraith's comment about a Bitcoin URI being more like a mailto URI seems right to me.
PPS: Piggybacking on magnet: seems wrong to me.
PPPS: @melvster: RDF gives me a boner. More?

FREE ROSS ULBRICHT, allegedly one of the Dread Pirates Roberts of the Silk Road
inertia
Jr. Member
*
Offline Offline

Activity: 34



View Profile WWW

Ignore
November 22, 2010, 03:31:30 AM
 #37

I think bitcoin:<address> is the bare minimum, and probably what most people would want.  Think about how often you get an e-mail from a mailto: address that's pre-loaded with a subject.  I never got any, even though I always used it since the late 90's.

If you want a e-mail feedback over the web, you'll have back-end validation to reduce user errors.  Why would this be any less so when receiving a payment?

I think it would be more likely that a browser plug-in will pick up bare addresses before a URI-scheme is widely recognized by people who author web pages.

Anyway, maybe I don't want to send money to a particular address I encounter.  If it's a static address, for a charity or a developer, maybe I'd like to take a peek at the address details first, like this.

I'm all for a URI-scheme, it would be great, but either way something has to interpret it.  And a browser plug-in is more likely to do what I want.

You should try my Minecraft server.
Anonymous
Guest

November 22, 2010, 05:08:37 AM
 #38

I know one thing for sure no one will want to harvest your bitcoin address and send you spam the way they do with email addresses  Smiley

Well that is spam I wouldnt mind at all..... Cheesy
inertia
Jr. Member
*
Offline Offline

Activity: 34



View Profile WWW

Ignore
November 22, 2010, 07:32:58 AM
 #39

Well that is spam I wouldnt mind at all..... Cheesy

"Oh man.  I just got another 25 x 0.69 BTC spams.  Those guys won't let up!"  Grin

You should try my Minecraft server.
Anonymous
Guest

November 22, 2010, 10:10:47 AM
 #40

Well that is spam I wouldnt mind at all..... Cheesy

"Oh man.  I just got another 25 x 0.69 BTC spams.  Those guys won't let up!"  Grin


lol bitstalker.
sandos
Member
**
Offline Offline

Activity: 106


View Profile

Ignore
November 22, 2010, 11:10:45 AM
 #41

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!

Smiley
awwright
Newbie
*
Offline Offline

Activity: 25


View Profile

Ignore
December 02, 2010, 12:18:46 AM
 #42

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
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW

Ignore
December 04, 2010, 12:27:24 PM
 #43

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.

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
Bruce Wagner
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
December 04, 2010, 09:09:07 PM
 #44

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
Hero Member
*****
Offline Offline

Activity: 490


My avatar pic says it all


View Profile

Ignore
December 04, 2010, 09:13:21 PM
 #45

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
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
December 04, 2010, 09:20:38 PM
 #46

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
Hero Member
*****
Offline Offline

Activity: 490


My avatar pic says it all


View Profile

Ignore
December 04, 2010, 11:45:11 PM
 #47

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
Newbie
*
Offline Offline

Activity: 4


View Profile

Ignore
December 07, 2010, 11:56:09 AM
 #48

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
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
December 08, 2010, 05:58:50 AM
 #49

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
Guest

December 08, 2010, 07:15:55 AM
 #50

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


konaya
Newbie
*
Offline Offline

Activity: 4


View Profile

Ignore
December 08, 2010, 03:55:06 PM
 #51

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.
Pages: 1 2 3 [All]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!