Bitcoin Forum
December 10, 2016, 06:32:28 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: URI-scheme for bitcoin  (Read 16616 times)
melvster
Sr. Member
****
Offline Offline

Activity: 341


View Profile
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 ...
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481394748
Hero Member
*
Offline Offline

Posts: 1481394748

View Profile Personal Message (Offline)

Ignore
1481394748
Reply with quote  #2

1481394748
Report to moderator
1481394748
Hero Member
*
Offline Offline

Posts: 1481394748

View Profile Personal Message (Offline)

Ignore
1481394748
Reply with quote  #2

1481394748
Report to moderator
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2296


I support freedom of choice


View Profile WWW
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

Eternity Wall: Messages lasting forever - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
bytemaster
Hero Member
*****
Offline Offline

Activity: 728

BitShares


View Profile WWW
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.

https://steemit.com  Blogging is the new Mining
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2296


I support freedom of choice


View Profile WWW
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

Eternity Wall: Messages lasting forever - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2296


I support freedom of choice


View Profile WWW
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 )

Eternity Wall: Messages lasting forever - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - 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: 2296


I support freedom of choice


View Profile WWW
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?

Eternity Wall: Messages lasting forever - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
LZ
Staff
Legendary
*
Offline Offline

Activity: 1456


Satoshi everywhere!


View Profile WWW
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
mizerydearia
Hero Member
*****
Offline Offline

Activity: 574



View Profile
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
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
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: 1358



View Profile WWW
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
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: 1358



View Profile WWW
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
Offline Offline

Activity: 2506


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

Did I miss something?

http://pastebin.com/VsBbmXQx

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
mikegogulski
Sr. Member
****
Offline Offline

Activity: 360



View Profile WWW
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
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
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.
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!