* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases [not found] <9109000381434268897@unknownmsgid> @ 2011-12-13 8:55 ` Cameron Garnham 0 siblings, 0 replies; 54+ messages in thread From: Cameron Garnham @ 2011-12-13 8:55 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2153 bytes --] Namecoin makes sense; as we can use the same private keys to spend the namecoin as spending the bitcoins. Namecoin happens to be the only secure guaranteed global unique human rememberable string system that exists. I suggest that sending bitcoins to a namecoin name is the way to go... It makes even more sense since namecoin started merged mining. On 13 December 2011 08:03, Cameron Garnham <da2ce7@gmail•com> wrote: > > Sent from my Windows Phone > De: Amir Taaki > Enviado: 13/12/2011 0:43 > Para: bitcoin-development@lists•sourceforge.net > Asunto: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases > > I'm confused about the problem we're trying to solve. > > I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on > the wall a picture of their QR code and a bitcoin address. I don't own > a mobile phone so the QR code is > useless. Then I remembered FirstBits, went to my terminal and typed > 1brmlab. I got their bitcoin address from the website and copied that, > then opened my terminal and pasted that in to send 1 BTC. > > And > these proposals for Namecoin, would make bitcoin implementations > dependent on unproven technology. HTTPS/DNSSEC have been around a long > time and are responsible for many mission critical systems. There's a > lot of momentum behind those projects. Namecoin by contrast, could die > tomorrow. And it isn't a big deal that they're centralised. This is a > convenience for end users and does not affect the core system much. > > tl;dr: usability > > > > ------------------------------------------------------------------------------ > Systems Optimization Self Assessment > Improve efficiency and utilization of IT resources. Drive out cost and > improve service delivery. Take 5 minutes to use this Systems Optimization > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Cameron Garnham: email: da2ce7@gmail•com website: http://da2ce7.blogspot.com telephone: +61405227831 [-- Attachment #2: Type: text/html, Size: 3227 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] [BIP 15] Aliases
@ 2011-12-12 23:16 Zell Faze
2011-12-12 23:37 ` Jorge Timón
0 siblings, 1 reply; 54+ messages in thread
From: Zell Faze @ 2011-12-12 23:16 UTC (permalink / raw)
To: bitcoin-development
I agree with Luke-Jr. We need to try to find a decentralized solution if we are going to implement BIP 15. Bitcoin needs to remain decentralized in every aspect of the protocol or we lose its greatest strength.
I feel like the HTTPS idea would be a great idea for a client feature, but not really something that should be added to the protocol.
--- On Mon, 12/12/11, Luke-Jr <luke@dashjr•org> wrote:
> From: Luke-Jr <luke@dashjr•org>
> Subject: Re: [Bitcoin-development] [BIP 15] Aliases
> To: bitcoin-development@lists•sourceforge.net, "Amir Taaki" <zgenjix@yahoo•com>
> Date: Monday, December 12, 2011, 5:32 PM
> FirstBits looks nice at glance, but
> is bound to create a gold-rush to grab
> every nice-looking FirstBits address.
>
> HTTPS is only as secure as the (centralized) CAs, thus not
> really any better
> than TXT records.
>
> I don't think an address of some form is avoidable.
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Bitcoin-development] [BIP 15] Aliases 2011-12-12 23:16 [Bitcoin-development] " Zell Faze @ 2011-12-12 23:37 ` Jorge Timón 2011-12-12 23:41 ` Luke-Jr 0 siblings, 1 reply; 54+ messages in thread From: Jorge Timón @ 2011-12-12 23:37 UTC (permalink / raw) To: Zell Faze; +Cc: bitcoin-development I don't think Amir wants to put it into the protocol, but I still don't like much the proposal if it has to rely on servers. As an aside, even if firstbits it's not useful enough for the human memory, it is still useful for QR-codes like in the case of green addresses's POS instant payments. Would it be too strange to use namecoin? Some devices may need to rely on block exploring servers, but it is the easiest decentralized solution that comes to mind. 2011/12/13, Zell Faze <zellfaze@yahoo•com>: > I agree with Luke-Jr. We need to try to find a decentralized solution if we > are going to implement BIP 15. Bitcoin needs to remain decentralized in > every aspect of the protocol or we lose its greatest strength. > > I feel like the HTTPS idea would be a great idea for a client feature, but > not really something that should be added to the protocol. > > --- On Mon, 12/12/11, Luke-Jr <luke@dashjr•org> wrote: > >> From: Luke-Jr <luke@dashjr•org> >> Subject: Re: [Bitcoin-development] [BIP 15] Aliases >> To: bitcoin-development@lists•sourceforge.net, "Amir Taaki" >> <zgenjix@yahoo•com> >> Date: Monday, December 12, 2011, 5:32 PM >> FirstBits looks nice at glance, but >> is bound to create a gold-rush to grab >> every nice-looking FirstBits address. >> >> HTTPS is only as secure as the (centralized) CAs, thus not >> really any better >> than TXT records. >> >> I don't think an address of some form is avoidable. > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Jorge Timón ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] [BIP 15] Aliases 2011-12-12 23:37 ` Jorge Timón @ 2011-12-12 23:41 ` Luke-Jr [not found] ` <CAGQP0AGBKKEqhaJZj-Rw400AjrVHE9_EMve=RWdqoaOaDsTgtw@mail.gmail.com> 0 siblings, 1 reply; 54+ messages in thread From: Luke-Jr @ 2011-12-12 23:41 UTC (permalink / raw) To: bitcoin-development On Monday, December 12, 2011 6:37:56 PM Jorge Timón wrote: > Would it be too strange to use namecoin? This has the same problem as FirstBits, except .bit domains are dirt cheap, whereas vanitygen at least slows down grabbing all the common words... ^ permalink raw reply [flat|nested] 54+ messages in thread
[parent not found: <CAGQP0AGBKKEqhaJZj-Rw400AjrVHE9_EMve=RWdqoaOaDsTgtw@mail.gmail.com>]
* [Bitcoin-development] Fwd: [BIP 15] Aliases [not found] ` <CAGQP0AGBKKEqhaJZj-Rw400AjrVHE9_EMve=RWdqoaOaDsTgtw@mail.gmail.com> @ 2011-12-13 0:00 ` Jorge Timón 2011-12-13 0:42 ` Amir Taaki 0 siblings, 1 reply; 54+ messages in thread From: Jorge Timón @ 2011-12-13 0:00 UTC (permalink / raw) To: bitcoin-development Is the point is to have different hosts like in jtimon@gmail•com, jtimon@timon•es, etc. so if jtimon is already taken I can take another host? What about reserving directly the string "jtimon@nottaken•org" or "jtimon::public::receiving::bitcoin" in namecoin? I'm confused about the problem we're trying to solve. 2011/12/13, Luke-Jr <luke@dashjr•org>: > On Monday, December 12, 2011 6:37:56 PM Jorge Timón wrote: >> Would it be too strange to use namecoin? > > This has the same problem as FirstBits, except .bit domains are dirt cheap, > whereas vanitygen at least slows down grabbing all the common words... > ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 0:00 ` [Bitcoin-development] Fwd: " Jorge Timón @ 2011-12-13 0:42 ` Amir Taaki 2011-12-13 2:32 ` Daniel F 2011-12-13 10:55 ` Mike Hearn 0 siblings, 2 replies; 54+ messages in thread From: Amir Taaki @ 2011-12-13 0:42 UTC (permalink / raw) To: bitcoin-development > I'm confused about the problem we're trying to solve. I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of their QR code and a bitcoin address. I don't own a mobile phone so the QR code is useless. Then I remembered FirstBits, went to my terminal and typed 1brmlab. I got their bitcoin address from the website and copied that, then opened my terminal and pasted that in to send 1 BTC. And these proposals for Namecoin, would make bitcoin implementations dependent on unproven technology. HTTPS/DNSSEC have been around a long time and are responsible for many mission critical systems. There's a lot of momentum behind those projects. Namecoin by contrast, could die tomorrow. And it isn't a big deal that they're centralised. This is a convenience for end users and does not affect the core system much. tl;dr: usability ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 0:42 ` Amir Taaki @ 2011-12-13 2:32 ` Daniel F 2011-12-13 2:37 ` Amir Taaki 2011-12-13 10:55 ` Mike Hearn 1 sibling, 1 reply; 54+ messages in thread From: Daniel F @ 2011-12-13 2:32 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development > I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of their QR code and a bitcoin address. I don't own a mobile phone so the QR code is > useless. Then I remembered FirstBits, went to my terminal and typed > 1brmlab. I got their bitcoin address from the website and copied that, > then opened my terminal and pasted that in to send 1 BTC. ok, imagine if firstbits didn't exist. instead of going to firstbits, you would have gone to your terminal, opened up brmlabs website, and copied the address from there? there may be some arguments for name-> address translation, but i'm sorry to say, that your example is not one of them. if anything, it seems to suggest that firstbits is completely useless, since it saves approximately zero effort. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 2:32 ` Daniel F @ 2011-12-13 2:37 ` Amir Taaki 2011-12-13 2:43 ` Luke-Jr 2011-12-13 2:52 ` Daniel F 0 siblings, 2 replies; 54+ messages in thread From: Amir Taaki @ 2011-12-13 2:37 UTC (permalink / raw) To: bitcoin-development lol, way to miss the point nanotube. FirstBits *is* useless, but not for the reasons you specified. But simply because the resources it needs rises exponentially as the number of participants in the network grows linearly. The point is that if FirstBits were built into the implementation, that would allow me to simply send to 1brmlab. The proposal here is not for a website where people can lookup bitcoin addresses, but a shared naming scheme between bitcoin implementations. Here's the story again: > I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of their QR code and a bitcoin address. I don't own a mobile phone so the QR code is > useless. Then I remembered FirstBits, went to my terminal and typed > 1brmlab. I got their bitcoin address from the website and copied that, > then opened my terminal and pasted that in to send 1 BTC. In our revised history, I simply send 1 BTC to brmlab BOOM. Club Mate ----- Original Message ----- From: Daniel F <nanotube@gmail•com> To: Amir Taaki <zgenjix@yahoo•com> Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net> Sent: Tuesday, December 13, 2011 2:32 AM Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases > I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of their QR code and a bitcoin address. I don't own a mobile phone so the QR code is > useless. Then I remembered FirstBits, went to my terminal and typed > 1brmlab. I got their bitcoin address from the website and copied that, > then opened my terminal and pasted that in to send 1 BTC. ok, imagine if firstbits didn't exist. instead of going to firstbits, you would have gone to your terminal, opened up brmlabs website, and copied the address from there? there may be some arguments for name-> address translation, but i'm sorry to say, that your example is not one of them. if anything, it seems to suggest that firstbits is completely useless, since it saves approximately zero effort. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 2:37 ` Amir Taaki @ 2011-12-13 2:43 ` Luke-Jr 2011-12-13 2:52 ` Daniel F 1 sibling, 0 replies; 54+ messages in thread From: Luke-Jr @ 2011-12-13 2:43 UTC (permalink / raw) To: bitcoin-development, Amir Taaki On Monday, December 12, 2011 9:37:06 PM Amir Taaki wrote: > In our revised history, I simply send 1 BTC to brmlab And then Joe Address Squatter gets 1 BTC. BOOM. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 2:37 ` Amir Taaki 2011-12-13 2:43 ` Luke-Jr @ 2011-12-13 2:52 ` Daniel F 1 sibling, 0 replies; 54+ messages in thread From: Daniel F @ 2011-12-13 2:52 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development On Mon, Dec 12, 2011 at 9:37 PM, Amir Taaki <zgenjix@yahoo•com> wrote: > lol, way to miss the point nanotube. > > FirstBits *is* useless, but not for the reasons you specified. But simply because the resources it needs rises exponentially as the number of participants in the network grows linearly. > > The point is that if FirstBits were built into the implementation, that would allow me to simply send to 1brmlab. The proposal here is not for a website where people can lookup bitcoin addresses, but a shared naming scheme between bitcoin implementations. Here's the story again: well, it's easy to miss the point when the example you use doesn't make the point you think you're making. :D but ok, yes, it would be nice to send directly to something like 1brmlab from the client. i suppose figuring out how to make sure that 1brmlab actually does send to whom you think it sends, is left to the details of implementation, but that's a separate question. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 0:42 ` Amir Taaki 2011-12-13 2:32 ` Daniel F @ 2011-12-13 10:55 ` Mike Hearn 2011-12-13 11:42 ` Christian Decker 1 sibling, 1 reply; 54+ messages in thread From: Mike Hearn @ 2011-12-13 10:55 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1818 bytes --] > > I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the > wall a picture of their QR code and a bitcoin address. I don't own a mobile > phone so the QR code is > useless. Fixed addresses like that are a temporary thing during Bitcoins maturation period. They lead to merchants exposing data they probably don't realize they're exposing, like their income, which is basically unacceptable for any payment system. There's no point trying to optimize a case where: 1) You are in the minority (no phone?) 2) The "perfect experience" leaks private data in such a way that would be deemed a gross security breach by any serious payment processor. OK, some thoughts on the general proposal, from the POV of what it'd take for a large deployment, like for every Gmail or every Facebook user. In terms of ease of implementation it is ordered HTTPS/HTTP then DNS trailing by a large margin. Big sites, even small sites, typically have high-speed load balancing and demuxing already implemented for HTTP[S] and it's usually easy to add new endpoints. The same is *not* true of DNS, and whilst coding up a custom DNS server is possible it's definitely a worse fit. FirstBits seems out of the question for the same privacy reasons as given above. No banking system worth its salt would let everyone look up other peoples income. The simplest approach would be to request a full public key with an HTTPS request like foo@domain -> https://domain/_bitcoin/getnewkey?user=foo&label=Payment%20from%20Bob If you then want to turn the resulting public key into an address before creating a transaction you can obviously do that. BTW the BIP is pretty hard to read. Your spec for the HTTPS proposal is a big pile of source code. I think it's the same as above, but it's hard to tell without more effort. [-- Attachment #2: Type: text/html, Size: 2347 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 10:55 ` Mike Hearn @ 2011-12-13 11:42 ` Christian Decker 2011-12-13 12:32 ` Jorge Timón 2011-12-13 15:55 ` Walter Stanish 0 siblings, 2 replies; 54+ messages in thread From: Christian Decker @ 2011-12-13 11:42 UTC (permalink / raw) To: Mike Hearn; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3822 bytes --] I think the scope of this BIP is not so well defined right now. We need a way for merchants to translate a human readable, and more importantly human-writeable, address into a bitcoin address. I agree with Mike that a fixed address is not the way to go, because addresses should be used once for a single transaction to be able to track payments. While firstbits sounds attractive at first, I think we can all agree that it just isn't feasible and would not allow per-transaction addresses. DNS sounds interesting for fixed addresses, but caching and propagation make it difficult to use for per-transaction addresses that are to be generated ad-hoc. HTTP(S) is the best option I think, merchants are probably using HTTP anyway for their shops. So something like http://merchant.com/btc/transaction/1234 sounds reasonable. But I think it should not be over-engineered, it should be a simple HTTP(S) request to a merchant specified URL that returns an ASCII document containing either a bitcoin: URI or simply the bitcoin address or even a 301 redirect. It's no use to start defining URL schemes, it should be left to the merchants to define how to structure them. This would allow a merchant to decide if he prefers per-transaction addresses, per-user transactions, fixed addresses or any combination. Regards, cdecker On Tue, Dec 13, 2011 at 11:55 AM, Mike Hearn <mike@plan99•net> wrote: > I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the >> wall a picture of their QR code and a bitcoin address. I don't own a mobile >> phone so the QR code is >> useless. > > > Fixed addresses like that are a temporary thing during Bitcoins maturation > period. They lead to merchants exposing data they probably don't realize > they're exposing, like their income, which is basically unacceptable for > any payment system. > > There's no point trying to optimize a case where: > > 1) You are in the minority (no phone?) > 2) The "perfect experience" leaks private data in such a way that would be > deemed a gross security breach by any serious payment processor. > > OK, some thoughts on the general proposal, from the POV of what it'd take > for a large deployment, like for every Gmail or every Facebook user. In > terms of ease of implementation it is ordered HTTPS/HTTP then DNS trailing > by a large margin. Big sites, even small sites, typically have high-speed > load balancing and demuxing already implemented for HTTP[S] and it's > usually easy to add new endpoints. The same is *not* true of DNS, and > whilst coding up a custom DNS server is possible it's definitely a worse > fit. > > FirstBits seems out of the question for the same privacy reasons as given > above. No banking system worth its salt would let everyone look up other > peoples income. > > The simplest approach would be to request a full public key with an HTTPS > request like > > foo@domain -> > https://domain/_bitcoin/getnewkey?user=foo&label=Payment%20from%20Bob > > If you then want to turn the resulting public key into an address before > creating a transaction you can obviously do that. > > BTW the BIP is pretty hard to read. Your spec for the HTTPS proposal is a > big pile of source code. I think it's the same as above, but it's hard to > tell without more effort. > > > ------------------------------------------------------------------------------ > Systems Optimization Self Assessment > Improve efficiency and utilization of IT resources. Drive out cost and > improve service delivery. Take 5 minutes to use this Systems Optimization > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 4946 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 11:42 ` Christian Decker @ 2011-12-13 12:32 ` Jorge Timón 2011-12-13 13:06 ` Gavin Andresen 2011-12-13 15:55 ` Walter Stanish 1 sibling, 1 reply; 54+ messages in thread From: Jorge Timón @ 2011-12-13 12:32 UTC (permalink / raw) Cc: bitcoin-development No decentralized solution for non-fixed addresses comes to mind. If we're going to always rely on servers, we should definitely offer dynamic addresses. There was a bitcoin service in the forum to which merchants send different addresses and the service manages the payments for the merchant without holding his private keys. The service identified each shopping cart by a combination of the total amount and the selected address for that cart. I don't remember the name of the service though. It could easily implement aliases (the same alias for various rotating addresses). Of course, the service provider still knows your income and you still need to provide new addresses to maintain your privacy. I say this just in case it inspires someone. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 12:32 ` Jorge Timón @ 2011-12-13 13:06 ` Gavin Andresen 2011-12-13 15:46 ` Amir Taaki ` (2 more replies) 0 siblings, 3 replies; 54+ messages in thread From: Gavin Andresen @ 2011-12-13 13:06 UTC (permalink / raw) To: Jorge Timón; +Cc: bitcoin-development I agree with Mike Hearn and Christian Decker-- paying to 'somebody@foo•com' should become, behind the scenes, a HTTPS query to https://foo.com/something. If you just want to (say) donate to eff.org, then paying to '@eff.org' aught to work nicely. And if namecoin ever takes off you'll pay to 'somebody@foo•bit'. It seems to me that if it was DNS-based, the address should be something like 'somebody.bitcoin.foo.com'. But I think it is unlikely people will setup and run a custom DNS server just to support bitcoin payments. -- -- Gavin Andresen ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 13:06 ` Gavin Andresen @ 2011-12-13 15:46 ` Amir Taaki 2011-12-13 16:22 ` Andy Parkins 2011-12-13 15:47 ` Luke-Jr 2011-12-16 17:36 ` Khalahan 2 siblings, 1 reply; 54+ messages in thread From: Amir Taaki @ 2011-12-13 15:46 UTC (permalink / raw) To: bitcoin-development Maybe I wasn't clear enough in the document, but this is the intent with the HTTPS proposal. genjix@foo•org Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system responds with a bitcoin address. Whether the system gives you a new address from a pool of addresses, or contacts the merchant behind the scenes is implementation defined. I'll clarify it later. This is the relevant line: string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" + pszEncodedNick; Between HTTPS service and server service, I lean slightly towards HTTPS (automatic encrypted connection, CAs + all benefits of DNS). But still interested in arguments in favour of a server service (daemon answering queries). ----- Original Message ----- From: Gavin Andresen <gavinandresen@gmail•com> To: Jorge Timón <timon.elviejo@gmail•com> Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net> Sent: Tuesday, December 13, 2011 1:06 PM Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases I agree with Mike Hearn and Christian Decker-- paying to 'somebody@foo•com' should become, behind the scenes, a HTTPS query to https://foo.com/something. If you just want to (say) donate to eff.org, then paying to '@eff.org' aught to work nicely. And if namecoin ever takes off you'll pay to 'somebody@foo•bit'. It seems to me that if it was DNS-based, the address should be something like 'somebody.bitcoin.foo.com'. But I think it is unlikely people will setup and run a custom DNS server just to support bitcoin payments. -- -- Gavin Andresen ------------------------------------------------------------------------------ Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists•sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 15:46 ` Amir Taaki @ 2011-12-13 16:22 ` Andy Parkins 2011-12-14 19:22 ` D.H. 2011-12-16 0:07 ` slush 0 siblings, 2 replies; 54+ messages in thread From: Andy Parkins @ 2011-12-13 16:22 UTC (permalink / raw) To: bitcoin-development, Amir Taaki [-- Attachment #1: Type: Text/Plain, Size: 2925 bytes --] On 2011 December 13 Tuesday, Amir Taaki wrote: > Maybe I wasn't clear enough in the document, but this is the intent with > the HTTPS proposal. I don't like the idea of a hard-coded mapping at all. We shouldn't be making choices on behalf of server operators. It's up to them how they arrange their domain names and paths. I also agree that DNS is not the technology to use. DNS is a nightmare. > genjix@foo•org > > Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system > responds with a bitcoin address. Whether the system gives you a new > address from a pool of addresses, or contacts the merchant behind the > scenes is implementation defined. > > I'll clarify it later. This is the relevant line: > > string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" + > pszEncodedNick; > > Between HTTPS service and server service, I lean slightly towards HTTPS > (automatic encrypted connection, CAs + all benefits of DNS). But still > interested in arguments in favour of a server service (daemon answering > queries). Why bother with an encoding scheme at all? If the address genjix@foo•org always maps to https://foo.org/bitcoin-alias/?handle=genjix Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" and "?handle=" and the original email-looking "genjix@foo•org". Just use the URL. Then the author of the service can use whatever they want. "Can I pay you 10 BTC?" "Sure, send it to 'https://bitcoinalias.foo.org/genjix/'" While I might implement my alias server like this: "Sure, send it to 'https://google.com/bitcoin/?andyparkins'" "Sure, send it to 'https://parkins.co.uk/" ... or any other URL they want -- any of which suit might suit me and my webserver better than whatever mapping would otherwise be hard-coded. The world is already very familiar with URLs so this is no more scary than the email address. What's more, the email address form looks _too much_ like an email address, and will only lead to confusion ... "send it to genjix@foo•org" "so I use outlook express for that, right?" "erm, no, you put it in your bitcoin client". The URL form could easily be made to detect a browser connecting rather than a bitcoin client (and this is an area that would benefit from a standards document -- define the headers and user agent triggers that an alias server expects) and give them better instructions. https can be specified as the default, so "https://" can be optional when they're typing. If, in the future, bitcoin gets a distributed peer-to-peer alias system, then a new URL type can be added easily "bcalias://andyparkins" might automatically find my node in the network and query it for an address (or whatever). All of the above is exactly why OpenID chose to use URLs for ID. Andy -- Dr Andy Parkins andyparkins@gmail•com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 16:22 ` Andy Parkins @ 2011-12-14 19:22 ` D.H. 2011-12-14 20:07 ` Luke-Jr 2011-12-16 0:07 ` slush 1 sibling, 1 reply; 54+ messages in thread From: D.H. @ 2011-12-14 19:22 UTC (permalink / raw) To: bitcoin-development > Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" and> "?handle=" and the original email-looking "genjix@foo•org". Just use the URL.> Then the author of the service can use whatever they want. I like this a lot. It's very simple to understand and would be very easy to implement and set up. "Sure, send it to david.bitcoin.se". D.H. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-14 19:22 ` D.H. @ 2011-12-14 20:07 ` Luke-Jr 2011-12-14 20:17 ` D.H. 2011-12-14 20:21 ` Joel Joonatan Kaartinen 0 siblings, 2 replies; 54+ messages in thread From: Luke-Jr @ 2011-12-14 20:07 UTC (permalink / raw) To: bitcoin-development On Wednesday, December 14, 2011 2:22:12 PM D.H. wrote: > > Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" > > and> "?handle=" and the original email-looking "genjix@foo•org". Just > > use the URL.> Then the author of the service can use whatever they want. > > I like this a lot. It's very simple to understand and would be very > easy to implement and set up. > > "Sure, send it to david.bitcoin.se". That's not a valid URI. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-14 20:07 ` Luke-Jr @ 2011-12-14 20:17 ` D.H. 2011-12-14 20:21 ` Joel Joonatan Kaartinen 1 sibling, 0 replies; 54+ messages in thread From: D.H. @ 2011-12-14 20:17 UTC (permalink / raw) To: Luke-Jr, bitcoin-development >> "Sure, send it to david.bitcoin.se".>> That's not a valid URI. I'm not sure I get your point. If someone tells you "hey, check out the web page at xkcd.com", is that your response or do you just open up your web browser and type "xkcd.com"? D.H. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-14 20:07 ` Luke-Jr 2011-12-14 20:17 ` D.H. @ 2011-12-14 20:21 ` Joel Joonatan Kaartinen 2011-12-14 22:51 ` Jorge Timón 1 sibling, 1 reply; 54+ messages in thread From: Joel Joonatan Kaartinen @ 2011-12-14 20:21 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development On Wed, 2011-12-14 at 15:07 -0500, Luke-Jr wrote: > > "Sure, send it to david.bitcoin.se". > > That's not a valid URI. I realize I'm responding to an useless nitpick with another useless nitpick but here goes. It doesn't have to be a valid URI. As long as the recipient (or the software he's using) can make it into a valid URI. My web-browser definitely would open http://david.bitcoin.se/ from that. For bitcoin clients, https:// should be the guess it tries. - Joel ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-14 20:21 ` Joel Joonatan Kaartinen @ 2011-12-14 22:51 ` Jorge Timón 2011-12-14 23:02 ` Rick Wesson 0 siblings, 1 reply; 54+ messages in thread From: Jorge Timón @ 2011-12-14 22:51 UTC (permalink / raw) To: bitcoin-development What if we specify "bitcoin" to make it easier for software (maybe the browser, a plugin for the browser, the bitcoin client analyzing the clipboard...) to easily detect that you expect a bitcoin address when going to url? If puted in the bitcoin client, the "bitcoin://" is optional (? and can also be replaced by http ?) since from the context you already expect an address or an url that will give you the address. In the browser: bitcoin://address bitcoin://rest_of_url In the bitcoin client: address rest_of_url bitcoin://address bitcoin://rest_of_url http://rest_of_url ?? Maybe in the bitcoin client you can put any site and the client downloads the web to look for occurrences of "bitcoin://" (? or just valid addresses ?) in it. It caches and shows them to you to decide what to do with each one. I have used other programs (jdownloader) that read the clipboard looking for patterns in links and is very convenient. Maybe then parameters for the client can be added to this. bitcoin://address?amount=10.53 bitcoin://rest_of_url?amount=10.53&green_address=r bitcoin://rest_of_url?amount=10.53&green_address=r&green_address_list=address1,address2,address3 Whatever the community have planned for bitcoin URIs. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-14 22:51 ` Jorge Timón @ 2011-12-14 23:02 ` Rick Wesson 2011-12-14 23:27 ` Luke-Jr 0 siblings, 1 reply; 54+ messages in thread From: Rick Wesson @ 2011-12-14 23:02 UTC (permalink / raw) To: Jorge Timón; +Cc: bitcoin-development I was looking at the wiki entry for this and noticed that your description of DNSSEC is incorrect. It is an internet standard and is widely deployed in the root (.), many TLDs, ccTLDs and second leverl domains. Also understand when the IETF or ICANN adopts new (we worked on DNSSEC no less than 10 years) standard the horizon is at least 20 years. Nothing and I really mean nothing is adopted in mass over shorter time scales. I also am largely in favor of using secured zones to publish TXT records to digital currencies. I've been thinking mainly about TXT using the following format for bitcoin. _btc.<lhs>.<rhs> you can look up the following record _btc.rick.wesson.us (from rick@wesson•us) which yealds ; <<>> DiG 9.6-ESV-R4-P3 <<>> _btc.rick.wesson.us txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45136 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;_btc.rick.wesson.us. IN TXT ;; ANSWER SECTION: _btc.rick.wesson.us. 299 IN TXT "BTC=1\; 1GCVXLfF1TcpnnDLJRHk845NZhuJWQTnUD" ;; Query time: 147 msec while this isn't a secured zone, any leverage of DNSSEC would require the application to have direct hooks into the stub-resolver, rather than just leveraging the OS's implementation. just some food for thought... -rick 2011/12/14 Jorge Timón <timon.elviejo@gmail•com>: > What if we specify "bitcoin" to make it easier for software (maybe the > browser, a plugin for the browser, the bitcoin client analyzing the > clipboard...) to easily detect that you expect a bitcoin address when > going to url? > If puted in the bitcoin client, the "bitcoin://" is optional (? and > can also be replaced by http ?) since from the context you already > expect an address or an url that will give you the address. > > In the browser: > > bitcoin://address > bitcoin://rest_of_url > > In the bitcoin client: > > address > rest_of_url > bitcoin://address > bitcoin://rest_of_url > http://rest_of_url ?? > > Maybe in the bitcoin client you can put any site and the client > downloads the web to look for occurrences of "bitcoin://" (? or just > valid addresses ?) in it. It caches and shows them to you to decide > what to do with each one. > I have used other programs (jdownloader) that read the clipboard > looking for patterns in links and is very convenient. > > Maybe then parameters for the client can be added to this. > > bitcoin://address?amount=10.53 > bitcoin://rest_of_url?amount=10.53&green_address=r > bitcoin://rest_of_url?amount=10.53&green_address=r&green_address_list=address1,address2,address3 > > Whatever the community have planned for bitcoin URIs. > > ------------------------------------------------------------------------------ > Cloud Computing - Latest Buzzword or a Glimpse of the Future? > This paper surveys cloud computing today: What are the benefits? > Why are businesses embracing it? What are its payoffs and pitfalls? > http://www.accelacomm.com/jaw/sdnl/114/51425149/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-14 23:02 ` Rick Wesson @ 2011-12-14 23:27 ` Luke-Jr 2011-12-15 1:22 ` Rick Wesson 0 siblings, 1 reply; 54+ messages in thread From: Luke-Jr @ 2011-12-14 23:27 UTC (permalink / raw) To: bitcoin-development; +Cc: Jorge On Wednesday, December 14, 2011 6:02:25 PM Rick Wesson wrote: > I also am largely in favor of using secured zones to publish TXT > records to digital currencies. I've been thinking mainly about TXT > using the following format for bitcoin. > > _btc.<lhs>.<rhs> Don't confuse BTC (Bitcoin unit) with BC (Bitcoin in general / protocol)... The hard part of using DNS will be sticking to the standard good practice of using a new address for every transaction. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-14 23:27 ` Luke-Jr @ 2011-12-15 1:22 ` Rick Wesson 2011-12-15 3:57 ` Zell Faze 0 siblings, 1 reply; 54+ messages in thread From: Rick Wesson @ 2011-12-15 1:22 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development understand that not *everyone* wants or will adhere to that best practice and in my NSHO it isn't. -rick 2011/12/14 Luke-Jr <luke@dashjr•org>: > On Wednesday, December 14, 2011 6:02:25 PM Rick Wesson wrote: >> I also am largely in favor of using secured zones to publish TXT >> records to digital currencies. I've been thinking mainly about TXT >> using the following format for bitcoin. >> >> _btc.<lhs>.<rhs> > > Don't confuse BTC (Bitcoin unit) with BC (Bitcoin in general / protocol)... > The hard part of using DNS will be sticking to the standard good practice of > using a new address for every transaction. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 1:22 ` Rick Wesson @ 2011-12-15 3:57 ` Zell Faze 2011-12-15 4:56 ` Kyle Henderson 0 siblings, 1 reply; 54+ messages in thread From: Zell Faze @ 2011-12-15 3:57 UTC (permalink / raw) To: Luke-Jr, Rick Wesson; +Cc: bitcoin-development Could we combine this proposal and the HTTPS proposal? The DNSSEC TXT record could give instructions on how to query an HTTPS server to get the address. Then we get the dynamism of HTTPS without having a rigid URL scheme for querying the server along with the advantages of DNSSEC. --- On Wed, 12/14/11, Rick Wesson <rick@support-intelligence•com> wrote: > From: Rick Wesson <rick@support-intelligence•com> > Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases > To: "Luke-Jr" <luke@dashjr•org> > Cc: bitcoin-development@lists•sourceforge.net > Date: Wednesday, December 14, 2011, 8:22 PM > understand that not *everyone* wants > or will adhere to that best > practice and in my NSHO it isn't. > > -rick > > 2011/12/14 Luke-Jr <luke@dashjr•org>: > > On Wednesday, December 14, 2011 6:02:25 PM Rick Wesson > wrote: > >> I also am largely in favor of using secured zones > to publish TXT > >> records to digital currencies. I've been thinking > mainly about TXT > >> using the following format for bitcoin. > >> > >> _btc.<lhs>.<rhs> > > > > Don't confuse BTC (Bitcoin unit) with BC (Bitcoin in > general / protocol)... > > The hard part of using DNS will be sticking to the > standard good practice of > > using a new address for every transaction. > > ------------------------------------------------------------------------------ > 10 Tips for Better Server Consolidation > Server virtualization is being driven by many needs. > > But none more important than the need to reduce IT > complexity > while improving strategic productivity. Learn More! > http://www.accelacomm.com/jaw/sdnl/114/51507609/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 3:57 ` Zell Faze @ 2011-12-15 4:56 ` Kyle Henderson 2011-12-15 6:04 ` Zell Faze 0 siblings, 1 reply; 54+ messages in thread From: Kyle Henderson @ 2011-12-15 4:56 UTC (permalink / raw) To: Zell Faze; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 491 bytes --] Just so we're clear, what is the need for HTTP at all? A query for a string and an answer can all be handled via DNS. On Thu, Dec 15, 2011 at 4:57 PM, Zell Faze <zellfaze@yahoo•com> wrote: > Could we combine this proposal and the HTTPS proposal? > > The DNSSEC TXT record could give instructions on how to query an HTTPS > server to get the address. Then we get the dynamism of HTTPS without > having a rigid URL scheme for querying the server along with the advantages > of DNSSEC. > > [-- Attachment #2: Type: text/html, Size: 739 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 4:56 ` Kyle Henderson @ 2011-12-15 6:04 ` Zell Faze 2011-12-15 6:41 ` Walter Stanish 2011-12-15 15:42 ` Rick Wesson 0 siblings, 2 replies; 54+ messages in thread From: Zell Faze @ 2011-12-15 6:04 UTC (permalink / raw) To: Kyle Henderson; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1369 bytes --] It is a lot easier to set up an HTTP server to dynamically respond with addresses than a DNS record. It is considered a good practice to use a different address for every payment. ------------------------ "It stopped being just a website a long time ago. For many of us, most of us, Wikipedia has become an indispensable part of our daily lives." — Jimmy Wales, Founder of Wikipedia Help protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate --- On Wed, 12/14/11, Kyle Henderson <k@old•school.nz> wrote: From: Kyle Henderson <k@old•school.nz> Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases To: "Zell Faze" <zellfaze@yahoo•com> Cc: "Luke-Jr" <luke@dashjr•org>, "Rick Wesson" <rick@support-intelligence•com>, bitcoin-development@lists•sourceforge.net Date: Wednesday, December 14, 2011, 11:56 PM Just so we're clear, what is the need for HTTP at all? A query for a string and an answer can all be handled via DNS. On Thu, Dec 15, 2011 at 4:57 PM, Zell Faze <zellfaze@yahoo•com> wrote: Could we combine this proposal and the HTTPS proposal? The DNSSEC TXT record could give instructions on how to query an HTTPS server to get the address. Then we get the dynamism of HTTPS without having a rigid URL scheme for querying the server along with the advantages of DNSSEC. [-- Attachment #2: Type: text/html, Size: 2342 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 6:04 ` Zell Faze @ 2011-12-15 6:41 ` Walter Stanish 2011-12-15 7:45 ` Jordan Mack 2011-12-15 7:48 ` Jorge Timón 2011-12-15 15:42 ` Rick Wesson 1 sibling, 2 replies; 54+ messages in thread From: Walter Stanish @ 2011-12-15 6:41 UTC (permalink / raw) To: Zell Faze; +Cc: bitcoin-development >> Just so we're clear, what is the need for HTTP at all? >> A query for a string and an answer can all be handled via DNS. > It is a lot easier to set up an HTTP server to dynamically respond > with addresses than a DNS record. Interesting that you bring up the effort factor. The notion that every individual will want to run their own DNS or HTTP based alias system to dispense transaction-specific bitcoin addresses seems - on this basis - alone a little far fetched. Such a system would provide very little added value at significant hassle to the small subset of users who could be bothered setting up such a scheme. Also, remember that most people in the world don't even know what DNS is, nor do they have the capacity or motivation to set up a program on a web server for what amounts to minor ongoing time savings and some vanity thrills. To my mind, it is far more likely that third party hosted services (such as providers of hosted wallet, conventional currency holding and exchange services) will provide aliasing resolution, and that these alias resolution services will operate on an alias@provider mechanism (for example, IIBAN and its 'institution' codes @ ). In addition, during the 'pre-transaction exchange' that the alias resolution process essentially represents, additional value could be added by these types of service providers by providing functionality presently excluded from Bitcoin but relevant to real world financial systems. For example this 'pre-transaction exchange' process might include, in addition to alias resolution, transaction metadata exchange (transaction description, invoice/order number, taxation information, schedules of fees and charges, pre-arranged currency exchange rates if filling an payment for an amount quoted in another (eg: conventional) currency, shipping terms, transaction reversal (cancellation) terms, escrow terms, etc.) Regards, Walter Stanish Payward Inc. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 6:41 ` Walter Stanish @ 2011-12-15 7:45 ` Jordan Mack 2011-12-15 7:52 ` Jorge Timón 2011-12-15 7:48 ` Jorge Timón 1 sibling, 1 reply; 54+ messages in thread From: Jordan Mack @ 2011-12-15 7:45 UTC (permalink / raw) To: bitcoin-development I believe it is also worth mentioning the possible susceptibility of a DOS attack on a publicly available alias system. Assuming that an alias lookup triggers the creation of a new Bitcoin address, the private key would need to be retained indefinitely. If gone unnoticed, this could consume considerable resources over time. Unlike system logs and such, this is not something that can be so easily pruned. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 7:45 ` Jordan Mack @ 2011-12-15 7:52 ` Jorge Timón 0 siblings, 0 replies; 54+ messages in thread From: Jorge Timón @ 2011-12-15 7:52 UTC (permalink / raw) Cc: bitcoin-development 2011/12/15, Jordan Mack <jordanmack@parhelic•com>: > I believe it is also worth mentioning the possible susceptibility of a > DOS attack on a publicly available alias system. Assuming that an alias > lookup triggers the creation of a new Bitcoin address, the private key > would need to be retained indefinitely. If gone unnoticed, this could > consume considerable resources over time. Unlike system logs and such, > this is not something that can be so easily pruned. You're right. Then servers should not use a different address with every lookup. Maybe don't change it more than once per min/hour/whatever, maybe wait to see a payment to that address to start giving another one... ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 6:41 ` Walter Stanish 2011-12-15 7:45 ` Jordan Mack @ 2011-12-15 7:48 ` Jorge Timón 2011-12-15 8:26 ` Walter Stanish 2011-12-15 15:44 ` Rick Wesson 1 sibling, 2 replies; 54+ messages in thread From: Jorge Timón @ 2011-12-15 7:48 UTC (permalink / raw) Cc: bitcoin-development Andy sounded very convincing when talking in favor of URLs. What's wrong with his proposal? 2011/12/15, Walter Stanish <walter@stani•sh>: > To my mind, it is far more likely that third party hosted services > (such as providers of hosted wallet, conventional currency holding and > exchange services) will provide aliasing resolution, and that these > alias resolution services will operate on an alias@provider mechanism > (for example, IIBAN and its 'institution' codes @ ). Why don't just... bitcoin://url.without.explicitly.specifying.provider bitcoin://alias@provider bitcoin://IIBAN@authorizedBitcoinInstitution ?? By the way, I don't like the fact that a single authorized institution needs to map the IIBANs to bitcoin addresses. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 7:48 ` Jorge Timón @ 2011-12-15 8:26 ` Walter Stanish 2011-12-15 10:01 ` Andy Parkins ` (2 more replies) 2011-12-15 15:44 ` Rick Wesson 1 sibling, 3 replies; 54+ messages in thread From: Walter Stanish @ 2011-12-15 8:26 UTC (permalink / raw) To: Jorge Timón; +Cc: bitcoin-development >> Why don't just... >> >> bitcoin://url.without.explicitly.specifying.provider >> bitcoin://alias@provider >> bitcoin://IIBAN@authorizedBitcoinInstitution ?? > Andy sounded very convincing when talking in favor of URLs. What's > wrong with his proposal? A URI identifies a resource and is in effect an alias itself. Identifying a resource is different from interacting with it. So, while <resource-type>://<resource-type-specific-alias> will work sufficiently for the identification, it does not explain the interaction. Interaction is a requirement, since there seems to be a widely felt need to preserve anonymity through the use of temporary addresses. Generating a temporary address requires some actual processing to achieve, since the issuing of the new address cannot be done without interacting with the entity hosting the wallet (unless I'm missing something?). > By the way, I don't like the fact that a single authorized institution > needs to map the IIBANs to bitcoin addresses. This is not the case. Please read my earlier response to Gavin and the IIBAN specification itself to clarify. That would be a total breach of privacy since the entity would have access to financial information on all transactions using the IIBAN identifiers... prior to transactions being executed. It *is* true that under the current IIBAN proposal there would be one entity (IANA) in charge of issuing namespace portions ('institution codes' - probably best to rename these...), however: - The policy is strict and something similar to 'give one out to anyone except existing financial instutions with the pre-existing capacity to issue IBAN'. - IANA have a pretty reasonable track record - This suggestion, like the entire proposal, is open for discussion and modification. If you can think of a more efficient and fair way of assigning namespace prefixes to random entities on the internet that doesn't require someone *without* an established track record of doing this for the internet community to take up IANA's place, then I'd be happy to hear it. Whilst a bitcoin-like 'community consensus' system is conceivably possible to deploy in its place, I don't think it's necessary. Regards, Walter Stanish Payward, Inc. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 8:26 ` Walter Stanish @ 2011-12-15 10:01 ` Andy Parkins 2011-12-15 11:08 ` Jorge Timón 2011-12-16 8:46 ` Pieter Wuille 2 siblings, 0 replies; 54+ messages in thread From: Andy Parkins @ 2011-12-15 10:01 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: Text/Plain, Size: 2680 bytes --] On 2011 December 15 Thursday, Walter Stanish wrote: > > Andy sounded very convincing when talking in favor of URLs. What's > > wrong with his proposal? > > A URI identifies a resource and is in effect an alias itself. > Identifying a resource is different from interacting with it. So, > while <resource-type>://<resource-type-specific-alias> will work > sufficiently for the identification, it does not explain the > interaction. Quite so; the BIP15 standard shouldn't be setting the format of the URI; it should be setting what the format of the client-server conversation is. Effectively, what headers will a requesting client send? What headers should a server require? What will a server respond? > Interaction is a requirement, since there seems to be a widely felt > need to preserve anonymity through the use of temporary addresses. I think that's missing the point; any aliasing scheme is definitely reducing your anonymity, neccessarily so -- the alias has to be looked up somewhere, that somewhere reduces anonymity. If anonymity is what you want, stick with just a bitcoin address. The point of an aliasing server is surely to be able to give a single, unchanging, well known label to a transacting party, but still enable that party to generate a new address per transaction. I want my webshop to be able to say "please pay 3.20 BTC to https://mywebshop.com/payments/orderid=27282" to enable the automatic connection from orderid to bitcoin address (which my payment system can then monitor for payment receipt). (This is just one example). > Generating a temporary address requires some actual processing to > achieve, since the issuing of the new address cannot be done without > interacting with the entity hosting the wallet (unless I'm missing > something?). Well yes; but then the client has no idea what address to send to unless it connects to that URI... interaction/address generation is done when that connection is made. In short: I don't really think that this aliasing system should be concerning itself with preserving anonymity of the receiving party. That is almost certainly already gone (I'm hardly likely to send money to someone I don't know unless I like gifting random cash). The sending party loses a little anonymity because their IP is revealed when they connect to the aliasing system. But there is very little anonymity in a supplier-client relationship anyway (you have to say what goods you want, and where you want them, and you had to interact with a website when you were ordering already). Andy -- Dr Andy Parkins andyparkins@gmail•com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 8:26 ` Walter Stanish 2011-12-15 10:01 ` Andy Parkins @ 2011-12-15 11:08 ` Jorge Timón 2011-12-15 11:22 ` Christian Decker 2011-12-16 5:42 ` Walter Stanish 2011-12-16 8:46 ` Pieter Wuille 2 siblings, 2 replies; 54+ messages in thread From: Jorge Timón @ 2011-12-15 11:08 UTC (permalink / raw) To: Walter Stanish; +Cc: bitcoin-development 2011/12/15, Walter Stanish <walter@stani•sh>: > Interaction is a requirement, since there seems to be a widely felt > need to preserve anonymity through the use of temporary addresses. > Generating a temporary address requires some actual processing to > achieve, since the issuing of the new address cannot be done without > interacting with the entity hosting the wallet (unless I'm missing > something?). I thought the interaction was just the server answering with an address (maybe also amount and other details). But we don't have to define how the server will get that address. Some possibilities: -A static address: less anonymity, but some people may not care. Say a donation address. -The servers stores the recipient private keys and generates a new one for each payment. -The server stores a set of addresses provided by the recipient and it manages what address it gives in each request (like in the web service I told you I can't find). > It *is* true that under the current IIBAN proposal there would be one > entity (IANA) in charge of issuing namespace portions ('institution > codes' - probably best to rename these...), however: > ... IANA reserves some namespace for bitcoin. All right. The problem comes later. " * Systems such as [BITCOIN] have quirks that require slightly delayed settlement due to the nature of their decentralized, consensus-based approach to fiscal transfer. Users requiring instant settlement MAY thus see benefit in the use of a centralized proxy system or organization as an instantaneous financial settlement provider (the 'institution'). " As I understand it (probably I'm wrong, because I haven't read the whole IIBAN draft) there would be a "bitcoin institution" that would map bitcoin addresses to the bitcoin subspace of the IIBAN. " * IANA MAY delegate management of portions of the IIBAN name space through such institutions." If we can find a deterministic method to map the subspace the all possible bitcoin addresses, everything's fine again. But if that's not possible, we would need a central institution to manage the mapping and that would be a step back in decentralization. I can't find the answer of Gavin's question "How is the mapping done?" in your post. I'll re-read it though. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 11:08 ` Jorge Timón @ 2011-12-15 11:22 ` Christian Decker 2011-12-16 5:42 ` Walter Stanish 1 sibling, 0 replies; 54+ messages in thread From: Christian Decker @ 2011-12-15 11:22 UTC (permalink / raw) To: Jorge Timón; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1637 bytes --] > But we don't have to > define how the server will get that address. > Some possibilities: > > -A static address: less anonymity, but some people may not care. Say a > donation address. > -The servers stores the recipient private keys and generates a new one > for each payment. > -The server stores a set of addresses provided by the recipient and it > manages what address it gives in each request (like in the web service > I told you I can't find). > Exactly, I think we should starting separating the minimal protocol that is to be supported by everybody, and the rest can be summed up in a few best practices, no need to standardize the part that to the user is transparent. I was on the same lines as Andy, which is that in order to have require a payment I probably have an order/transaction pending with my vendor or have an account to be filled, so there's a 1-to-1 mapping between the details page and the bitcoin address I have to send to. As a further possibility we could use <meta> tags like the OpenID server delegation mechanism. It would allow customers to open the transaction details page, see that everything is ok, then paste the same URL into the bitcoin client, the bitcoin client retrieves the URL, parses the meta tag and knows what to send where. Alternatively the Bitcoin Client sends an Accept header which tells the server to return just the address. As for the format I'd say either a Bitcoin address or a Bitcoin URI [1] which ought to be flexible enough as it includes amount and messages, for the customer to be able to track transactions. Regards, Chris [1] https://en.bitcoin.it/wiki/URI_Scheme [-- Attachment #2: Type: text/html, Size: 1952 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 11:08 ` Jorge Timón 2011-12-15 11:22 ` Christian Decker @ 2011-12-16 5:42 ` Walter Stanish 1 sibling, 0 replies; 54+ messages in thread From: Walter Stanish @ 2011-12-16 5:42 UTC (permalink / raw) To: Jorge Timón; +Cc: bitcoin-development >> Interaction is a requirement, since there seems to be a widely felt >> need to preserve anonymity through the use of temporary addresses. >> Generating a temporary address requires some actual processing to >> achieve, since the issuing of the new address cannot be done without >> interacting with the entity hosting the wallet (unless I'm missing >> something?). > > I thought the interaction was just the server answering with an > address (maybe also amount and other details). But we don't have to > define how the server will get that address. > Some possibilities: > > -A static address: less anonymity, but some people may not care. Say a > donation address. Sure, but this falls short of requirements for most users. > -The servers stores the recipient private keys and generates a new one > for each payment. Equivalent to hosted wallet, which is decentralization in a BIG way, but apparently a very popular choice (for pragmatic reasons). Probably not going away. > -The server stores a set of addresses provided by the recipient and it > manages what address it gives in each request (like in the web service > I told you I can't find). True. However, probably a poor user experience for most users re: provision of temporary addresses to the alias host. Also the knowledge of which entity for which inbound payment has been allocated which temporary address would be a significant complexity in the alias host / end user relationship that you gloss over. This is important for businesses, since inbound payments are only really possible to track - AFAIK (correct me if I'm wrong, the two exceptions being the edge case of people requesting inbound transactions where every single transaction is of a unique amount and no 'partial payment' (2x transactions for one inbound payment) and the case where every single inbound payer's sending address is previously known) - by issuing unique recipient addresses to each client. In short, it's kind of similar to hosted wallet as well, since you need to absolutely trust your host (they could tell people wishing to make payments to you to pay someone else instead!). > IANA reserves some namespace for bitcoin. All right. > The problem comes later. > " > * Systems such as [BITCOIN] have quirks that require slightly > delayed settlement due to the nature of their decentralized, > consensus-based approach to fiscal transfer. Users requiring > instant settlement MAY thus see benefit in the use of a > centralized proxy system or organization as an instantaneous > financial settlement provider (the 'institution'). > " > As I understand it (probably I'm wrong, because I haven't read the > whole IIBAN draft) there would be a "bitcoin institution" that would > map bitcoin addresses to the bitcoin subspace of the IIBAN. Many people can get namespace management rights as 'institutions' (in the current draft's terminology), then manage the assignement of IIBANs within that space as they wish. There would be many institutions with many IIBANs. The association of a bitcoin address (or many addresses, or the capacity to generate temporary addresses as required) with an IIBAN would be the responsibility of either that namespace manager ('institution') or the individual who has acquired that IIBAN via that namespace manager ('insitution'). > " * IANA MAY delegate management of portions of the IIBAN name space > through such institutions." > > If we can find a deterministic method to map the subspace the all > possible bitcoin addresses, everything's fine again. But if that's not > possible, we would need a central institution to manage the mapping > and that would be a step back in decentralization. Many institutions, many policies, no absolute centralization, though admittedly increased centralization. However, this is a problem shared with two of your proposals (the subset not disqualified as failing to meet most user's requirements) when you consider that most users (if you consider 'the whole world's mobile devices' a potential userbase, as I prefer to do) do not have the technical skills to configure, secure and manage their own 'always on' alias service hosts, nor the capacity to host blockchain copies on those devices (either due to space or bandwidth requirements. As an aside, this is a large part of the unfortunate reality that is tending to push Bitcoin towards hosted wallet solutions) > I can't find the answer of Gavin's question "How is the mapping done?" > in your post. I'll re-read it though. Near the top, beginning "It seems a clarification is in order, apologies for not being clearer." (Re-reading, it's still not that clear!) Regards, Walter Stanish Payward, Inc. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 8:26 ` Walter Stanish 2011-12-15 10:01 ` Andy Parkins 2011-12-15 11:08 ` Jorge Timón @ 2011-12-16 8:46 ` Pieter Wuille 2 siblings, 0 replies; 54+ messages in thread From: Pieter Wuille @ 2011-12-16 8:46 UTC (permalink / raw) To: bitcoin-development On Thu, Dec 15, 2011 at 04:26:38PM +0800, Walter Stanish wrote: > Interaction is a requirement, since there seems to be a widely felt > need to preserve anonymity through the use of temporary addresses. > Generating a temporary address requires some actual processing to > achieve, since the issuing of the new address cannot be done without > interacting with the entity hosting the wallet (unless I'm missing > something?). Just replying to this one comment: yes, some interaction is always necessary, but not necessarily directly with the entity hosting the wallet. There are some EC crypto tricks to do this (often mentioned under "deterministic wallets" before): The wallet-hosting entity has a private key x, with public key X. The address-generating entity knows X, and generates a fresh private key y for each transaction. For each, it calculates Z=y*X, and asks the client to pay to hash160(Z). Afterwards, it can send a bunch of y's to the wallet hosting service, which can reconstruct z=y*x for each. Alternatively, the y's can be generated according to a predefined scheme instead. -- Pieter ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 7:48 ` Jorge Timón 2011-12-15 8:26 ` Walter Stanish @ 2011-12-15 15:44 ` Rick Wesson 1 sibling, 0 replies; 54+ messages in thread From: Rick Wesson @ 2011-12-15 15:44 UTC (permalink / raw) To: Jorge Timón; +Cc: bitcoin-development > Why don't just... > > bitcoin://url.without.explicitly.specifying.provider > bitcoin://alias@provider > bitcoin://IIBAN@authorizedBitcoinInstitution ?? > > By the way, I don't like the fact that a single authorized institution > needs to map the IIBANs to bitcoin addresses. The IANA is a good institution to rely on for mapping things, much history and wise execution there. -rick ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-15 6:04 ` Zell Faze 2011-12-15 6:41 ` Walter Stanish @ 2011-12-15 15:42 ` Rick Wesson 1 sibling, 0 replies; 54+ messages in thread From: Rick Wesson @ 2011-12-15 15:42 UTC (permalink / raw) To: Zell Faze; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1929 bytes --] Are we designing protocols or applications, its easier and better for all involved if we design a protocol and then let the applications implement it. Lets stick to understanding how labels (dns) or URIs can be leveraged to securly obtain a bitcoin address, rather than reviewing capabilities of current applications. -rick On Wed, Dec 14, 2011 at 10:04 PM, Zell Faze <zellfaze@yahoo•com> wrote: > It is a lot easier to set up an HTTP server to dynamically respond with > addresses than a DNS record. It is considered a good practice to use a > different address for every payment. > > ------------------------ > "It stopped being just a website a long time ago. For many of us, most of > us, Wikipedia has become an indispensable part of our daily lives." > — Jimmy Wales, *Founder of Wikipedia* > <http://2e740a1a.qvvo.com/> > > Help protect it now. Please make a donation today: > http://www.wikimediafoundation.org/wiki/Donate > > > --- On *Wed, 12/14/11, Kyle Henderson <k@old•school.nz>* wrote: > > > From: Kyle Henderson <k@old•school.nz> > > Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases > To: "Zell Faze" <zellfaze@yahoo•com> > Cc: "Luke-Jr" <luke@dashjr•org>, "Rick Wesson" < > rick@support-intelligence•com>, bitcoin-development@lists•sourceforge.net > Date: Wednesday, December 14, 2011, 11:56 PM > > > Just so we're clear, what is the need for HTTP at all? > > A query for a string and an answer can all be handled via DNS. > > On Thu, Dec 15, 2011 at 4:57 PM, Zell Faze <zellfaze@yahoo.com<http://mc/compose?to=zellfaze@yahoo.com> > > wrote: > > Could we combine this proposal and the HTTPS proposal? > > The DNSSEC TXT record could give instructions on how to query an HTTPS > server to get the address. Then we get the dynamism of HTTPS without > having a rigid URL scheme for querying the server along with the advantages > of DNSSEC. > > > [-- Attachment #2: Type: text/html, Size: 3358 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 16:22 ` Andy Parkins 2011-12-14 19:22 ` D.H. @ 2011-12-16 0:07 ` slush 2011-12-16 15:52 ` Rick Wesson 1 sibling, 1 reply; 54+ messages in thread From: slush @ 2011-12-16 0:07 UTC (permalink / raw) To: Andy Parkins; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 4219 bytes --] I really like this proposal with standard URLs. All other proposals like DNS mapping or email aliases converted to URLs with some weird logic looks strange to me. Plain URLs (returning address in response body, redirecting to URI "bitcoin:<address>" or anything else) are very clear solution, easy to implement in clients and very easy to understand by people. It's also extremely flexible - almost everybody can somewhere setup static file containing his "personal" addresses or it's very easy to integrate such solution with eshops (providing custom address for given order) etc. I'm definitely for this solution. Best, slush On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins <andyparkins@gmail•com> wrote: > On 2011 December 13 Tuesday, Amir Taaki wrote: > > > Maybe I wasn't clear enough in the document, but this is the intent with > > the HTTPS proposal. > > I don't like the idea of a hard-coded mapping at all. We shouldn't be > making > choices on behalf of server operators. It's up to them how they arrange > their > domain names and paths. > > I also agree that DNS is not the technology to use. DNS is a nightmare. > > > genjix@foo•org > > > > Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system > > responds with a bitcoin address. Whether the system gives you a new > > address from a pool of addresses, or contacts the merchant behind the > > scenes is implementation defined. > > > > I'll clarify it later. This is the relevant line: > > > > string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" + > > pszEncodedNick; > > > > Between HTTPS service and server service, I lean slightly towards HTTPS > > (automatic encrypted connection, CAs + all benefits of DNS). But still > > interested in arguments in favour of a server service (daemon answering > > queries). > > Why bother with an encoding scheme at all? If the address > > genjix@foo•org > > always maps to > > https://foo.org/bitcoin-alias/?handle=genjix > > Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" and > "?handle=" and the original email-looking "genjix@foo•org". Just use the > URL. > Then the author of the service can use whatever they want. > > "Can I pay you 10 BTC?" > "Sure, send it to 'https://bitcoinalias.foo.org/genjix/'" > > While I might implement my alias server like this: > > "Sure, send it to 'https://google.com/bitcoin/?andyparkins'" > "Sure, send it to 'https://parkins.co.uk/" > > ... or any other URL they want -- any of which suit might suit me and my > webserver better than whatever mapping would otherwise be hard-coded. The > world is already very familiar with URLs so this is no more scary than the > email address. What's more, the email address form looks _too much_ like > an > email address, and will only lead to confusion ... "send it to > genjix@foo•org" > "so I use outlook express for that, right?" "erm, no, you put it in your > bitcoin client". > > The URL form could easily be made to detect a browser connecting rather > than a > bitcoin client (and this is an area that would benefit from a standards > document -- define the headers and user agent triggers that an alias server > expects) and give them better instructions. > > https can be specified as the default, so "https://" can be optional when > they're typing. If, in the future, bitcoin gets a distributed peer-to-peer > alias system, then a new URL type can be added easily > "bcalias://andyparkins" > might automatically find my node in the network and query it for an address > (or whatever). > > All of the above is exactly why OpenID chose to use URLs for ID. > > > > Andy > > -- > Dr Andy Parkins > andyparkins@gmail•com > > > ------------------------------------------------------------------------------ > Systems Optimization Self Assessment > Improve efficiency and utilization of IT resources. Drive out cost and > improve service delivery. Take 5 minutes to use this Systems Optimization > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 5930 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-16 0:07 ` slush @ 2011-12-16 15:52 ` Rick Wesson 2011-12-16 16:36 ` slush 2011-12-16 17:10 ` Andy Parkins 0 siblings, 2 replies; 54+ messages in thread From: Rick Wesson @ 2011-12-16 15:52 UTC (permalink / raw) To: slush; +Cc: bitcoin-development On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@centrum•cz> wrote: > I really like this proposal with standard URLs. All other proposals like DNS > mapping or email aliases converted to URLs with some weird logic looks > strange to me. wow, really. Maybe you could review some RFCs, there are thousands of examples where some really smart engineers chose the exact opposite path which you propose below. -rick > Plain URLs (returning address in response body, redirecting to URI > "bitcoin:<address>" or anything else) are very clear solution, easy to > implement in clients and very easy to understand by people. It's also > extremely flexible - almost everybody can somewhere setup static file > containing his "personal" addresses or it's very easy to integrate such > solution with eshops (providing custom address for given order) etc. I'm > definitely for this solution. > > Best, > slush > > On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins <andyparkins@gmail•com> wrote: >> >> On 2011 December 13 Tuesday, Amir Taaki wrote: >> >> > Maybe I wasn't clear enough in the document, but this is the intent with >> > the HTTPS proposal. >> >> I don't like the idea of a hard-coded mapping at all. We shouldn't be >> making >> choices on behalf of server operators. It's up to them how they arrange >> their >> domain names and paths. >> >> I also agree that DNS is not the technology to use. DNS is a nightmare. >> >> > genjix@foo•org >> > >> > Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system >> > responds with a bitcoin address. Whether the system gives you a new >> > address from a pool of addresses, or contacts the merchant behind the >> > scenes is implementation defined. >> > >> > I'll clarify it later. This is the relevant line: >> > >> > string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" + >> > pszEncodedNick; >> > >> > Between HTTPS service and server service, I lean slightly towards HTTPS >> > (automatic encrypted connection, CAs + all benefits of DNS). But still >> > interested in arguments in favour of a server service (daemon answering >> > queries). >> >> Why bother with an encoding scheme at all? If the address >> >> genjix@foo•org >> >> always maps to >> >> https://foo.org/bitcoin-alias/?handle=genjix >> >> Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" >> and >> "?handle=" and the original email-looking "genjix@foo•org". Just use the >> URL. >> Then the author of the service can use whatever they want. >> >> "Can I pay you 10 BTC?" >> "Sure, send it to 'https://bitcoinalias.foo.org/genjix/'" >> >> While I might implement my alias server like this: >> >> "Sure, send it to 'https://google.com/bitcoin/?andyparkins'" >> "Sure, send it to 'https://parkins.co.uk/" >> >> ... or any other URL they want -- any of which suit might suit me and my >> webserver better than whatever mapping would otherwise be hard-coded. The >> world is already very familiar with URLs so this is no more scary than the >> email address. What's more, the email address form looks _too much_ like >> an >> email address, and will only lead to confusion ... "send it to >> genjix@foo•org" >> "so I use outlook express for that, right?" "erm, no, you put it in your >> bitcoin client". >> >> The URL form could easily be made to detect a browser connecting rather >> than a >> bitcoin client (and this is an area that would benefit from a standards >> document -- define the headers and user agent triggers that an alias >> server >> expects) and give them better instructions. >> >> https can be specified as the default, so "https://" can be optional when >> they're typing. If, in the future, bitcoin gets a distributed >> peer-to-peer >> alias system, then a new URL type can be added easily >> "bcalias://andyparkins" >> might automatically find my node in the network and query it for an >> address >> (or whatever). >> >> All of the above is exactly why OpenID chose to use URLs for ID. >> >> >> >> Andy >> >> -- >> Dr Andy Parkins >> andyparkins@gmail•com >> >> >> ------------------------------------------------------------------------------ >> Systems Optimization Self Assessment >> Improve efficiency and utilization of IT resources. Drive out cost and >> improve service delivery. Take 5 minutes to use this Systems Optimization >> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-16 15:52 ` Rick Wesson @ 2011-12-16 16:36 ` slush 2011-12-16 17:10 ` Andy Parkins 1 sibling, 0 replies; 54+ messages in thread From: slush @ 2011-12-16 16:36 UTC (permalink / raw) To: Rick Wesson; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1350 bytes --] OK, I'm ignoring your sarcastic style, I just wanted to support the URL idea, which is KISS attitude, in the oposite of everything else proposed here. I'm really affraid of over-engineering the aliases, which will make it hard to implement in clients. Somebody noticed account implementation in standard client - yes, it's good example of fail. I still don't see any serious issue with the URL proposals. And sipa's idea of posting back the transaction ID is also interesting, prividing yet another flexibility in implementation and possible usage. Btw, Rick, feel free to provide me some relevant RFCs which are solving similar problems like BIP 15. And no, it's not sarcasm, I really want to learn something new. Until now I just feel we're reinventing wheel or raping some stuff which we should not touch at all (DNS). slush On Fri, Dec 16, 2011 at 4:52 PM, Rick Wesson <rick@support-intelligence•com>wrote: > On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@centrum•cz> wrote: > > I really like this proposal with standard URLs. All other proposals like > DNS > > mapping or email aliases converted to URLs with some weird logic looks > > strange to me. > > wow, really. Maybe you could review some RFCs, there are thousands of > examples where some really smart engineers chose the exact opposite > path which you propose below. > > -rick > > [-- Attachment #2: Type: text/html, Size: 1950 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-16 15:52 ` Rick Wesson 2011-12-16 16:36 ` slush @ 2011-12-16 17:10 ` Andy Parkins 2011-12-16 17:41 ` Rick Wesson 1 sibling, 1 reply; 54+ messages in thread From: Andy Parkins @ 2011-12-16 17:10 UTC (permalink / raw) To: Rick Wesson; +Cc: bitcoin-development [-- Attachment #1: Type: Text/Plain, Size: 569 bytes --] On 2011 December 16 Friday, Rick Wesson wrote: > On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@centrum•cz> wrote: > > I really like this proposal with standard URLs. All other proposals like > > DNS mapping or email aliases converted to URLs with some weird logic > > looks strange to me. > > wow, really. Maybe you could review some RFCs, there are thousands of > examples where some really smart engineers chose the exact opposite > path which you propose below. Could you point me at an example? Andy -- Dr Andy Parkins andyparkins@gmail•com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-16 17:10 ` Andy Parkins @ 2011-12-16 17:41 ` Rick Wesson 2011-12-16 18:29 ` Amir Taaki 2011-12-16 20:54 ` Andy Parkins 0 siblings, 2 replies; 54+ messages in thread From: Rick Wesson @ 2011-12-16 17:41 UTC (permalink / raw) To: Andy Parkins; +Cc: bitcoin-development Its a negative example -- in that the IETF does not specify anything in the PATH part of the URI. The scheme, sure, but not in the path, there are many types of URI schemes ( start with RFC 2396 ) There is significant upside to having your own scheme and having apps understand how to integrate with it. Frankly, having just one client (I understand there are more) is an artifact that hinders acceptance and participation. If you want to go the route of https then specifying a scheme is your path forward I still believe that it is experience that is leading this thread down the rat-hole of CGI and HTTP requests. The stuff isn't magic, it is just what you are used to. Review the bitcoin protocol, there is an elegance there -- not found in the https schemes proposed thus far. CGI isn't a protocol, nor does it address usability/identity issues. Providing a mapping from user@authority•tld addresses usability and identity. I'd like to see an elegant transformation, specifically I take to task anyone that advocates https://authority/foo/user?tx=1zhd789632uilos as elegant. -rick On Fri, Dec 16, 2011 at 9:10 AM, Andy Parkins <andyparkins@gmail•com> wrote: > On 2011 December 16 Friday, Rick Wesson wrote: >> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@centrum•cz> wrote: >> > I really like this proposal with standard URLs. All other proposals like >> > DNS mapping or email aliases converted to URLs with some weird logic >> > looks strange to me. >> >> wow, really. Maybe you could review some RFCs, there are thousands of >> examples where some really smart engineers chose the exact opposite >> path which you propose below. > > Could you point me at an example? > > > Andy > > -- > Dr Andy Parkins > andyparkins@gmail•com ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-16 17:41 ` Rick Wesson @ 2011-12-16 18:29 ` Amir Taaki 2011-12-16 19:06 ` Gavin Andresen 2011-12-16 20:54 ` Andy Parkins 1 sibling, 1 reply; 54+ messages in thread From: Amir Taaki @ 2011-12-16 18:29 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3424 bytes --] You have to be seriously joking to call the bitcoin protocol elegant. A message based system over TCP with constantly changing endians that needs to lookup its own IP address on several websites is not elegant. It is functioning, not elegant. Also it is kind of dick to come guns blaring and start insulting slush who runs one of the biggest mining pools and is working on electrum, and sipa who develops the satoshi bitcoin. Khalahan said: > Namecoin is a peer-to-peer generic name/value datastore system Namecoin has the same problem as DNS. From the document: "The disadvantage of DNS TXT records is that updating a record takes time. This encourages people to not use new addresses per transaction which has certain security issues." ________________________________ From: Rick Wesson <rick@support-intelligence•com> To: Andy Parkins <andyparkins@gmail•com> Cc: bitcoin-development@lists•sourceforge.net Sent: Friday, December 16, 2011 5:41 PM Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases Its a negative example -- in that the IETF does not specify anything in the PATH part of the URI. The scheme, sure, but not in the path, there are many types of URI schemes ( start with RFC 2396 ) There is significant upside to having your own scheme and having apps understand how to integrate with it. Frankly, having just one client (I understand there are more) is an artifact that hinders acceptance and participation. If you want to go the route of https then specifying a scheme is your path forward I still believe that it is experience that is leading this thread down the rat-hole of CGI and HTTP requests. The stuff isn't magic, it is just what you are used to. Review the bitcoin protocol, there is an elegance there -- not found in the https schemes proposed thus far. CGI isn't a protocol, nor does it address usability/identity issues. Providing a mapping from user@authority•tld addresses usability and identity. I'd like to see an elegant transformation, specifically I take to task anyone that advocates https://authority/foo/user?tx=1zhd789632uilos as elegant. -rick On Fri, Dec 16, 2011 at 9:10 AM, Andy Parkins <andyparkins@gmail•com> wrote: > On 2011 December 16 Friday, Rick Wesson wrote: >> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@centrum•cz> wrote: >> > I really like this proposal with standard URLs. All other proposals like >> > DNS mapping or email aliases converted to URLs with some weird logic >> > looks strange to me. >> >> wow, really. Maybe you could review some RFCs, there are thousands of >> examples where some really smart engineers chose the exact opposite >> path which you propose below. > > Could you point me at an example? > > > Andy > > -- > Dr Andy Parkins > andyparkins@gmail•com ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists•sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development [-- Attachment #2: Type: text/html, Size: 5069 bytes --] ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-16 18:29 ` Amir Taaki @ 2011-12-16 19:06 ` Gavin Andresen 2011-12-16 19:22 ` Rick Wesson 2011-12-16 20:58 ` Andy Parkins 0 siblings, 2 replies; 54+ messages in thread From: Gavin Andresen @ 2011-12-16 19:06 UTC (permalink / raw) To: bitcoin-development First: everybody please try to focus on the issues/ideas, and try to avoid this becoming a flame war. Second: I think Walter Stanish made several good points that may have been missed in all the long posts and discussion, the main one being: The banking industry has been dealing with many of these issues for years; I think we should not dismiss their experience. I think there is also a huge public relations benefit to using a standard like IIBAN instead of inventing our own. Having a Bitcoin Payment Routing Address (or whatever it ends up being called) that looks like the number issues by big financial institutions will give people the warm fuzzies. I don't really care what happens behind the scenes, as long as it is as secure as an HTTPS connection (RE: CA pwnage: there's no such thing as perfect security, and until a more secure solution comes along HTTPS is the best we've got). And I'll reiterate that there doesn't have to be just one solution. My only concern is that IIBAN is Yet Another Fledgling Standard, and those little details that remain to be worked out could take years to actually work out. -- -- Gavin Andresen ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-16 19:06 ` Gavin Andresen @ 2011-12-16 19:22 ` Rick Wesson 2011-12-16 20:58 ` Andy Parkins 1 sibling, 0 replies; 54+ messages in thread From: Rick Wesson @ 2011-12-16 19:22 UTC (permalink / raw) To: Gavin Andresen; +Cc: bitcoin-development Agreed, I find measured dialog much more valuable. I also agree that standards take time and are messy, though choosing a standard allows additional participation and can drive interopability. One does not need to accept IBANN but we should participate in the dialog in its development. internet-drafts don't make it through the process unchanged. IBANN is a starting point not the end of the discussion. -rick On Fri, Dec 16, 2011 at 11:06 AM, Gavin Andresen <gavinandresen@gmail•com> wrote: > First: everybody please try to focus on the issues/ideas, and try to > avoid this becoming a flame war. > > Second: I think Walter Stanish made several good points that may have > been missed in all the long posts and discussion, the main one being: > > The banking industry has been dealing with many of these issues for > years; I think we should not dismiss their experience. > > I think there is also a huge public relations benefit to using a > standard like IIBAN instead of inventing our own. Having a Bitcoin > Payment Routing Address (or whatever it ends up being called) that > looks like the number issues by big financial institutions will give > people the warm fuzzies. > > I don't really care what happens behind the scenes, as long as it is > as secure as an HTTPS connection (RE: CA pwnage: there's no such > thing as perfect security, and until a more secure solution comes > along HTTPS is the best we've got). > > And I'll reiterate that there doesn't have to be just one solution. > > My only concern is that IIBAN is Yet Another Fledgling Standard, and > those little details that remain to be worked out could take years to > actually work out. > > -- > -- > Gavin Andresen > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-16 19:06 ` Gavin Andresen 2011-12-16 19:22 ` Rick Wesson @ 2011-12-16 20:58 ` Andy Parkins 1 sibling, 0 replies; 54+ messages in thread From: Andy Parkins @ 2011-12-16 20:58 UTC (permalink / raw) To: bitcoin-development On Friday 16 Dec 2011 19:06:52 Gavin Andresen wrote: > I think there is also a huge public relations benefit to using a > standard like IIBAN instead of inventing our own. Having a Bitcoin > Payment Routing Address (or whatever it ends up being called) that > looks like the number issues by big financial institutions will give > people the warm fuzzies. I can see the PR advantages, but isn't mapping from one massively long, multi-character, human-opaque number (IBAN) to another (bitcoin address) a bit of a waste of time? Surely the point of all this is to provide at least the possibility of a human-readable name for a bitcoin-address? Isn't there a possibility that one day we might want to be able to say "send me those bitcoins you owe me to bitcoin.yahoo.co.uk/andyparkins"? Or similar? Andy -- Dr Andy Parkins andyparkins@gmail•com ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-16 17:41 ` Rick Wesson 2011-12-16 18:29 ` Amir Taaki @ 2011-12-16 20:54 ` Andy Parkins 2011-12-16 21:50 ` Rick Wesson 1 sibling, 1 reply; 54+ messages in thread From: Andy Parkins @ 2011-12-16 20:54 UTC (permalink / raw) To: Rick Wesson; +Cc: bitcoin-development On Friday 16 Dec 2011 17:41:25 Rick Wesson wrote: > Its a negative example -- in that the IETF does not specify anything > in the PATH part of the URI. The scheme, sure, but not in the path, > there are many types of URI schemes ( start with RFC 2396 ) You seem to have jumped off the topic; you mentioned that there were thousands of RFCs that we should review over why we shouldn't use a URI; and you've pointed at an RFC that shows how a URI can be used. While you're right that CGI and HTTP aren't magic; they are commonplace; and it's important when we want an infinitely expandable mapping system that people can use technology they are already familiar with. People already have web servers, people already understand URIs. It's not "just what we are used to"; people who can cope with development of the bitcoin protocol aren't going to be worried about protocol complexity. It is a concern about what the rest of the world will have to do to get a bitcoin alias. > Providing a mapping from user@authority•tld addresses usability and No it doesn't address usability at all, because it falls down on the first attempt: what if I want to supply a URI that allows my web service to link an invoice number to an issued bitcoin address? You've forced every mapping service to be identical, and limited. > identity. I'd like to see an elegant transformation, specifically I > take to task anyone that advocates > https://authority/foo/user?tx=1zhd789632uilos as elegant. You've been unfair, the equivalent of your "user@authority•tld" is "https://authority.tld/user" or "https://user.authority.tld/" or "https://google.com/bitcoin/user" or any of an infinite number of other variations that _I_ as the mapper get to choose rather than whoever wrote the BIP; all of which are arguably no less "elegant" than that simple email. There is no equivalent in the other direction though. For someone who want's to supply the TX to their mapping server... where does it go in "user@authority•tld"? Andy -- Dr Andy Parkins andyparkins@gmail•com ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-16 20:54 ` Andy Parkins @ 2011-12-16 21:50 ` Rick Wesson 0 siblings, 0 replies; 54+ messages in thread From: Rick Wesson @ 2011-12-16 21:50 UTC (permalink / raw) To: Andy Parkins; +Cc: bitcoin-development On Fri, Dec 16, 2011 at 12:54 PM, Andy Parkins <andyparkins@gmail•com> wrote: [snip] > > You've been unfair, the equivalent of your "user@authority•tld" is > "https://authority.tld/user" or "https://user.authority.tld/" or > "https://google.com/bitcoin/user" or any of an infinite number of other > variations that _I_ as the mapper get to choose rather than whoever wrote > the BIP; all of which are arguably no less "elegant" than that simple email. > > There is no equivalent in the other direction though. For someone who > want's to supply the TX to their mapping server... where does it go in > "user@authority•tld"? actually there are many differences. Specifying a standard using a HTTP(s) transport for a look-up isn't something that has been done in the PATH portion of the URI and that I was pointing out that there is *NO* RFC that specifies such for a look-up provide the inverse of many protocol specifications that did *not* choose that methodology. What has happened is various schemes are specified, developed and deployed. I am sure you are familure with many. sip:// ftp:// etc:// many are described at http://en.wikipedia.org/wiki/URI_scheme NAPTR records (see http://en.wikipedia.org/wiki/NAPTR_record) are another area that deserves research for those that desire URI schemes. Understand that I am mearly advocating that as a group this work be done in standards development process, and that IBANN is one such effort. -rick ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 13:06 ` Gavin Andresen 2011-12-13 15:46 ` Amir Taaki @ 2011-12-13 15:47 ` Luke-Jr 2011-12-16 17:36 ` Khalahan 2 siblings, 0 replies; 54+ messages in thread From: Luke-Jr @ 2011-12-13 15:47 UTC (permalink / raw) To: bitcoin-development; +Cc: Jorge On Tuesday, December 13, 2011 8:06:15 AM Gavin Andresen wrote: > I agree with Mike Hearn and Christian Decker-- paying to > 'somebody@foo•com' should become, behind the scenes, a HTTPS query to > https://foo.com/something. If you just want to (say) donate to > eff.org, then paying to '@eff.org' aught to work nicely. Seems like introducing a gaping security risk to me. > It seems to me that if it was DNS-based, the address should be > something like 'somebody.bitcoin.foo.com'. But I think it is unlikely > people will setup and run a custom DNS server just to support bitcoin > payments. Could always use a fixed address and email somebody@foo•com a signed message. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 13:06 ` Gavin Andresen 2011-12-13 15:46 ` Amir Taaki 2011-12-13 15:47 ` Luke-Jr @ 2011-12-16 17:36 ` Khalahan 2011-12-16 17:48 ` Gregory Maxwell 2 siblings, 1 reply; 54+ messages in thread From: Khalahan @ 2011-12-16 17:36 UTC (permalink / raw) To: bitcoin-development Namecoin is a peer-to-peer generic name/value datastore system. Don't forget it's not limited to .bit usage ! So, directly mapping things to .bit url would not be the optimal way of using namecoin. Namecoin is specificaly designed to map things to names in a fully decentralized way. So, it's the perfect starting point to map names to other things (a public bitcoin address, an url, etc) You won't have all the advantages of namecoin when using other systems like DNS and HTTP(S) as the first entry point. What is namecoin ? * proven technology : - do not mix the namecoin technology and the dot-bit namespace with .bit domains (dot-bit domains needs dot-bit compatible dns servers or proxies + namecoin and have a small visibility due to the nature of top-to-bottom domain name system controlled by ICANN, namecoin needs only namecoin to store data !) - as proven and secure as bitcoin - merged mining provides a secure network * decentralized : - a lot of nodes, and you can have your own node - everybody can register his own name, by itself with the namecoin software (bitcoin could even allow registration directly from it, easily) or by using a name provider - everybody can become a name provider (register for your friends and resell names). * no single point of failure : - DNS and HTTPS have several limitations (Man in the Middle attacks, no reliable authority of certifications, domain seizure, ...) * designed for that : - namecoin uses a system of namespaces to separate each usages : http://dot-bit.org/Main_Page#Namespaces. For example, the "personal namespace" draft (http://dot-bit.org/Personal_Namespace) could be extended to support mapping to a bitcoin address, or a dedicated namespace can be used if prefered (the "bitcoin/" or "alias/" or "map/" prefixes for example). * easily connectable to bitcoin - they both use RPC and json to exchange informations, so connecting one to the other is really easy - bitcoin could even allow registration of names by sending an RPC request to namecoin * extensible and not limited : - you are not forced to store a bitcoin address directly in namecoin, you can also store an url or a domain name - allows additional security : add a certificate fingerprint combined with an https url (so, using DNS or HTTP(S) is not a major problem anymore if the first point of entry is really secure and configurable [and you use and self-signed certificate]) - really easy to update - simple for simple cases - possibility to use a nick, an email address or a domain as name - other methods to get bitcoins addresses can be added later, protocol is extensible Examples of possible registered names in namecoin with the "personal namespace" (with the "p/" prefix) : * An individual person with well known public addresses : "p/khal": { "email": "khal@dot-bit•org", "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T", "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9" } * Another individual person with well known public addresses : "p/khal@dot-bit•org": { "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T", "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9" } * A merchant accepting payments in bitcoin, namecoin, paypal or othercoin (to show you how the whole namespace could be used) : "p/mymerchant.com": { "bitcoin": { "url": "https://payto.mymerchant.com/bitcoin/", "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926" "cert": "https://payto.mymerchant.com/certificate.pem", }, "namecoin": { "url": "https://payto.mymerchant.com/namecoin/", "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926" }, "paypal": "xxxxxx@yyyyyyyyy•zzz", "othercoin": "oxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" } * A merchant with a public address, an url to generate custom addresses and a domain name (not sure if this case is really usefull, maybe as fallback) "p/mymerchant2": { "bitcoin": { "url": "https://payto.mymerchant.com/bitcoin/", "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926", "dns": "_bitcoin.payto.mymerchant.com", "address": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T", } } * How to use it in bitcoin ? Several possibilities of address syntax : - khal, khal@dot-bit•org, mymerchant.com, mymerchant2 : no syntax limit - mymerchant2@bitcoin : will conflict with names already containing a @ - mymerchant2@namecoin : same - namecoin:mymerchant2 : strange syntax, confusing with the "uri scheme" - namecoin://mymerchant2 : same - other ? Here is how things would be processed when people put an address to pay to in the bitcoin client : * address : khal -> RPC to namecoin for "p/khal" -> json processing for "p/khal->bitcoin" -> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T * address : khal@dot-bit•org -> RPC to namecoin for "p/khal@dot-bit•org" -> json processing for "p/khal@dot-bit•org->bitcoin" -> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T * address : mymerchant.com -> RPC to namecoin for "p/mymerchant.com" -> json processing for "p/mymerchant.com->bitcoin" -> json processing for "p/mymerchant.com->bitcoin->url" and "p/mymerchant.com->bitcoin->fpr" -> https request to "https://payto.mymerchant.com/bitcoin/" -> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy * address : mymerchant2 -> RPC to namecoin for "p/mymerchant2" -> json processing for "p/mymerchant2->bitcoin" -> json processing for "p/mymerchant2->bitcoin->url" and "p/mymerchant2->bitcoin->fpr" -> https request to "https://payto.mymerchant.com/bitcoin/" -> result : error (website unavailable, page not found, timeout, etc) -> json processing for "p/mymerchant2->bitcoin->dns" -> dns request for "_bitcoin.payto.mymerchant.com" -> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy Le 13/12/2011 14:06, Gavin Andresen a écrit : > I agree with Mike Hearn and Christian Decker-- paying to > 'somebody@foo•com' should become, behind the scenes, a HTTPS query to > https://foo.com/something. If you just want to (say) donate to > eff.org, then paying to '@eff.org' aught to work nicely. > > And if namecoin ever takes off you'll pay to 'somebody@foo•bit'. > > It seems to me that if it was DNS-based, the address should be > something like 'somebody.bitcoin.foo.com'. But I think it is unlikely > people will setup and run a custom DNS server just to support bitcoin > payments. > -- Best Regards, Khalahan http://dot-bit.org/ ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-16 17:36 ` Khalahan @ 2011-12-16 17:48 ` Gregory Maxwell 0 siblings, 0 replies; 54+ messages in thread From: Gregory Maxwell @ 2011-12-16 17:48 UTC (permalink / raw) To: Khalahan; +Cc: bitcoin-development On Fri, Dec 16, 2011 at 12:36 PM, Khalahan <khal@dot-bit•org> wrote: > Namecoin is a peer-to-peer generic name/value datastore system. > Don't forget it's not limited to .bit usage ! So, directly mapping > things to .bit url would not be the optimal way of using namecoin. > > Namecoin is specificaly designed to map things to names in a fully > decentralized way. So, it's the perfect starting point to map names to > other things (a public bitcoin address, an url, etc) > You won't have all the advantages of namecoin when using other systems > like DNS and HTTP(S) as the first entry point. How can one construct a zero-trust (or nearly zero trust) namecoin resolver without having a copy of the ever growing complete namecoin block chain? The bitcoin lite node mechanism will not work because a peer could return stale records or no-result and you would have no evidence of their deception. (In the case of lite bitcoin nodes, telling you about old transactions is harmless because you control your own transactions). ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 11:42 ` Christian Decker 2011-12-13 12:32 ` Jorge Timón @ 2011-12-13 15:55 ` Walter Stanish 2011-12-13 16:15 ` Jorge Timón 2011-12-13 16:48 ` Gavin Andresen 1 sibling, 2 replies; 54+ messages in thread From: Walter Stanish @ 2011-12-13 15:55 UTC (permalink / raw) To: Christian Decker; +Cc: bitcoin-development Interesting thread. Given the following paragraph and the limited feedback garnered upon its announcement to this list last month, I couldn't help but chime in again to mention IIBAN, an Internet Standards Draft available at http://tools.ietf.org/html/draft-iiban-00 (A related proposal for internet connected financial market identification, IMIC, is also available: http://tools.ietf.org/html/draft-imic-00) which - fair declaration of bias - I authored on behalf of my employer, Payward Inc., while working on Bitcoin-related development. > I think the scope of this BIP is not so well defined right now. We need a > way for merchants to translate a human readable, and more importantly > human-writeable, address into a bitcoin address. I believe that IIBAN solves this problem fairly elegantly: (1) Mature transposition error detection (think "Oops, that's a zero not an 'oh'! I wrote it wrong!"). This functions via checksum digits using a known algorithm, leveraging decades of experience in conventional financial institutions. The same functionality provides for simple suggested error correction on common transposition errors (0->O, 1->I, etc.). (2) Fixed length. (3) Far shorter than both bitcoin addresses and many national bank account numbers at 13 characters (less than half of the size of a bitcoin address). (4) Fewer characters (no lowercase), resulting in less transposition issues and greater legibility. (5) Superset-compatible with existing financial networks utilizing the IBAN standard (mandated in Europe, increasingly popular elsewhere), resulting in greater ease of uptake. (5) Centralized, delegatable namespace allocation but with clear rules governing allocation that aim to minimize potential room for any potential abuse of power. (6) Settlement system neutral - ie: not bitcoin-centric. By leaving Bitcoin to be Bitcoin, Bitcoin developers can focus on core concerns rather than becoming embroiled in formatting and user experience concerns. Also, a single address could be paid via multiple channels (conventional financial systems, bitcoin, LETS systems, etc.) resulting in greater ease of uptake and higher user confidence over time since published banking information is no longer held hostage to the assumed longevity, liquidity, legality or other liabilities of an individual settlement system (such as Bitcoin). (7) Provides defined private address spaces for internal transfers (eg: within an organization's own systems, for financial simulations, MMORPGs, etc.) and a documentation/public works of fiction address space to address common usage concerns in similar network addressing schemes. (8) Heterogeneous management of different parts of the address space. Whilst the proposed IANA (Internet Assigned Numbers Authority) management of IIBAN's initial institution namespace is indeed centralized and will no doubt raise eyebrows from within parts of the community for that reason alone, the IIBAN draft is liberal in its assignment policy, which can be viewed within the draft document linked to above, and whose terms are binding for IANA. It's also worth noting that four of the most similar global systems deployed today, SWIFT's BIC and IBAN, the ITU's E.164 international telephone numbering scheme and IANA's IP address space management are implemented as similar centralized-but-delegated style schemes. Furthermore, due to the flat nature of the registry, a http://convergence.io/ style 'trust agility' model (ie: multiple 'centralized' parties share their network view, and user-prioritized source consensus/acceptance/approval determine end-user perspective) is wholly compatible. In closing, a quick mention that a new version of the IIBAN draft will be released very shortly including a draft IIBAN institutions registry that will be established in order to facilitate implementation and testing. Drop me an email if you'd like a portion of the address space and your early assignment will appear within that draft. Regards, Walter Stanish Payward, Inc. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 15:55 ` Walter Stanish @ 2011-12-13 16:15 ` Jorge Timón 2011-12-13 16:48 ` Gavin Andresen 1 sibling, 0 replies; 54+ messages in thread From: Jorge Timón @ 2011-12-13 16:15 UTC (permalink / raw) Cc: bitcoin-development > (6) Settlement system neutral - ie: not bitcoin-centric. ... > Also, a single address could be paid via multiple channels > (conventional financial systems, bitcoin, LETS systems, etc.) > resulting in greater ease of uptake and higher user confidence over > time since published banking information is no longer held hostage to > the assumed longevity, liquidity, legality or other liabilities of an > individual settlement system (such as Bitcoin). I like this part. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 15:55 ` Walter Stanish 2011-12-13 16:15 ` Jorge Timón @ 2011-12-13 16:48 ` Gavin Andresen 2011-12-14 2:30 ` Walter Stanish 1 sibling, 1 reply; 54+ messages in thread From: Gavin Andresen @ 2011-12-13 16:48 UTC (permalink / raw) To: Walter Stanish; +Cc: bitcoin-development RE: IIBAN numbers: Nifty! Thanks for the pointers, I think we should avoid reinventing wheels whenever possible. When composing my last response in this thread I wrote, and then erased: "There doesn't have to be one solution: I'd like to see some experimentation, with clients supporting different schemes for bitcoin address aliases, and maybe supporting plugins to extend the schemes supported (a plugin would take a string, do some behind-the-scenes-magic, and return a bitcoin address or public key)." Defining Bitcoin as an IIBAN "institution", with 36^6 "accounts", seems like a forward-thinking idea, although I'm not clear on exactly how those 2.2billion "accounts" would get allocated and mapped into bitcoin addresses. I imagine some central organization that maps IIBAN account numbers to domain names... and then clients (or plugins in the clients) query that trusted central organization and then the account holder's domain to get a (possibly unique) public key or bitcoin address. As long as IIBANs are not the ONLY way of aliasing bitcoin addresses to more-human-friendly strings I think that would be a fine way to do it. -- -- Gavin Andresen ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 2011-12-13 16:48 ` Gavin Andresen @ 2011-12-14 2:30 ` Walter Stanish 0 siblings, 0 replies; 54+ messages in thread From: Walter Stanish @ 2011-12-14 2:30 UTC (permalink / raw) To: Gavin Andresen; +Cc: bitcoin-development > Nifty! Thanks for the pointers, I think we should avoid reinventing > wheels whenever possible. Hear hear! > When composing my last response in this thread I wrote, and then erased: > > "There doesn't have to be one solution: I'd like to see some > experimentation, with clients supporting different schemes for bitcoin > address aliases, and maybe supporting plugins to extend the schemes > supported (a plugin would take a string, do some > behind-the-scenes-magic, and return a bitcoin address or public key)." Sure. Alias systems are a usability focused requirement and as such should probably not be mandated by the network itself, anyway. > Defining Bitcoin as an IIBAN "institution", with 36^6 "accounts", > seems like a forward-thinking idea, although I'm not clear on exactly > how those 2.2billion "accounts" would get allocated and mapped into > bitcoin addresses. It seems a clarification is in order, apologies for not being clearer. Under the IIBAN scheme, whilst Bitcoin *could* define some default mechanism for automatically creating IIBANs that map to Bitcoin addresses (for example, Bitcoin client authors could provide hosted lookup), this was not the style of integration in mind while writing the IIBAN draft. Rather than simply defining Bitcoin as a single 'institution' (namespace segment) within the IIBAN standard, Payward Inc. envisages large numbers of parties (including individuals or small groups of individuals) operating individual Bitcoin-related (or LETS, or other alternate currency) services to register as institutions (really just 'namespace holders') within the IIBAN registry. Each such party may then define its own mapping system between Bitcoin, LETS, or other alternate currency financial endpoints that it 'manages' (proxies for) and IIBAN, within its namespace. As detailed within the IIBAN proposal, this process could be peer to peer or centralized, supporting one time or short-term use addresses as well as permanent addresses. A permanent address within IIBAN could map via the institution managing that portion of the IIBAN address space to a single use address on the Bitcoin network. Institutions are important for the following reasons (from http://tools.ietf.org/html/draft-iiban-00#section-4.3.2): With the advent of decentralized virtual currencies such as [BITCOIN] the conventional idea of a financial institution (such as a bank) may be seen by some as somewhat superfluous. However, the notion remains useful: * Conventional currencies will not disappear in the conceivable future, so the notion of financial institutions is expected to endure at least as providers of currency exchange and holding services. * Systems such as [BITCOIN] have quirks that require slightly delayed settlement due to the nature of their decentralized, consensus-based approach to fiscal transfer. Users requiring instant settlement MAY thus see benefit in the use of a centralized proxy system or organization as an instantaneous financial settlement provider (the 'institution'). * IANA MAY delegate management of portions of the IIBAN name space through such institutions. Furthermore from http://tools.ietf.org/html/draft-iiban-00#section-4.3.1: [Under IIBAN's combined issue paradigm] proxied issue is facilitated through IANA managed institution registration, provision for two types of privately issued addresses is reserved within this document, and registered institutions COULD provide DHT or similar mechanisms for the management of their delegated name space. The combined issue paradigm offers adequate provision for both manageability and decentralization, whilst maintaining heterogeneity. So the idea is that many institutions each provide mappings between IIBAN and Bitcoin, in a range of ways, and we do not see the emergence of a single mandated standard. There is no suggestion that Bitcoin developers should implement a hard-coded mechanism. > I imagine some central organization that maps IIBAN account numbers to > domain names... and then clients (or plugins in the clients) query > that trusted central organization and then the account holder's domain > to get a (possibly unique) public key or bitcoin address. This style of solution - in which a central organization becomes aware of every single IIBAN-based transaction in the network - is not necessary or desirable. Instead, under the IIBAN recommendation IANA would publish the registry of IIBAN institutions for everyone to use without the need to query any party. In the case of a financial transfer, a client or peer instutition seeking to send funds to an IIBAN-denominated address would use some hitherto-underfined mechanism* for translating the appropriate entry within that registry (corresponding to the transfer's destination address) to some kind of internet node representing the institution's systems. * This mechanism may necessitate the storage of public keys within the IIBAN institution registry and will be addressed within the next version of the IIBAN draft. Community input is encouraged. In a second yet-to-be-define protocol**, various settlement-system neutral (ie: not specific to Bitcoin, LETS, or any other system) transaction-related metadata would then be exchanged, prior to any actual transaction. Such metadata could include aspects of the transaction such as description, financial system endpoint ('account') holder name, account exists verification, settlement path negotiation (based upon feasibility, transaction overheads, latency, etc.), which party is to pay overheads, information mandated by local jurisdiction such as business tax numbers (required in some countries of Europe, I believe, for domestic B2B settlements), etc. ** This mechanism does need to be defined, and Payward Inc. has completed a not insubstantial amount of research in to existing protocols and concerns within this area, which touches upon high frequency automated banking, financial market support, and interbank settlement policy. An additional Internet Draft proposing one such potential mechanism will probably be published 'soon'. At the conclusion of this metadata exchange, the two nodes would have either aborted the transaction, suspended it to seek human input (such as settlement path selection based upon fee and latency metadata garnered), or agreed upon financial settlement system specific information to use in executing the transaction itself, likely out of band. In the case of Bitcoin, this *might* include information such as the blockcount after which the transaction will be considered settled by the receiving institution, an effective 'gentleman's agreement' on the terms of any opt-in notion of reversibility, a one time Bitcoin address provided by the recipient institution for the sender to make a Bitcoin transaction to, etc. From the perspective of a settlement system such as Bitcoin, IIBAN's provision of settlement system neutral financial endpoint identification provides the benefits outlined in the previous email, as well as the possibility to publish a permanent, fixed address without disclosing one's corresponding Bitcoin-derived income. From the broader perspective of effective financial system innovation, it hopes to provide a common basis upon which many such systems can conceivably interoperate, regardless of their underlying systemic differences. > As long as IIBANs are not the ONLY way of aliasing bitcoin addresses > to more-human-friendly strings I think that would be a fine way to do > it. Thank you for your vote of confidence. Regards, Walter Stanish Payward Inc. ^ permalink raw reply [flat|nested] 54+ messages in thread
end of thread, other threads:[~2011-12-16 21:51 UTC | newest]
Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <9109000381434268897@unknownmsgid>
2011-12-13 8:55 ` [Bitcoin-development] Fwd: [BIP 15] Aliases Cameron Garnham
2011-12-12 23:16 [Bitcoin-development] " Zell Faze
2011-12-12 23:37 ` Jorge Timón
2011-12-12 23:41 ` Luke-Jr
[not found] ` <CAGQP0AGBKKEqhaJZj-Rw400AjrVHE9_EMve=RWdqoaOaDsTgtw@mail.gmail.com>
2011-12-13 0:00 ` [Bitcoin-development] Fwd: " Jorge Timón
2011-12-13 0:42 ` Amir Taaki
2011-12-13 2:32 ` Daniel F
2011-12-13 2:37 ` Amir Taaki
2011-12-13 2:43 ` Luke-Jr
2011-12-13 2:52 ` Daniel F
2011-12-13 10:55 ` Mike Hearn
2011-12-13 11:42 ` Christian Decker
2011-12-13 12:32 ` Jorge Timón
2011-12-13 13:06 ` Gavin Andresen
2011-12-13 15:46 ` Amir Taaki
2011-12-13 16:22 ` Andy Parkins
2011-12-14 19:22 ` D.H.
2011-12-14 20:07 ` Luke-Jr
2011-12-14 20:17 ` D.H.
2011-12-14 20:21 ` Joel Joonatan Kaartinen
2011-12-14 22:51 ` Jorge Timón
2011-12-14 23:02 ` Rick Wesson
2011-12-14 23:27 ` Luke-Jr
2011-12-15 1:22 ` Rick Wesson
2011-12-15 3:57 ` Zell Faze
2011-12-15 4:56 ` Kyle Henderson
2011-12-15 6:04 ` Zell Faze
2011-12-15 6:41 ` Walter Stanish
2011-12-15 7:45 ` Jordan Mack
2011-12-15 7:52 ` Jorge Timón
2011-12-15 7:48 ` Jorge Timón
2011-12-15 8:26 ` Walter Stanish
2011-12-15 10:01 ` Andy Parkins
2011-12-15 11:08 ` Jorge Timón
2011-12-15 11:22 ` Christian Decker
2011-12-16 5:42 ` Walter Stanish
2011-12-16 8:46 ` Pieter Wuille
2011-12-15 15:44 ` Rick Wesson
2011-12-15 15:42 ` Rick Wesson
2011-12-16 0:07 ` slush
2011-12-16 15:52 ` Rick Wesson
2011-12-16 16:36 ` slush
2011-12-16 17:10 ` Andy Parkins
2011-12-16 17:41 ` Rick Wesson
2011-12-16 18:29 ` Amir Taaki
2011-12-16 19:06 ` Gavin Andresen
2011-12-16 19:22 ` Rick Wesson
2011-12-16 20:58 ` Andy Parkins
2011-12-16 20:54 ` Andy Parkins
2011-12-16 21:50 ` Rick Wesson
2011-12-13 15:47 ` Luke-Jr
2011-12-16 17:36 ` Khalahan
2011-12-16 17:48 ` Gregory Maxwell
2011-12-13 15:55 ` Walter Stanish
2011-12-13 16:15 ` Jorge Timón
2011-12-13 16:48 ` Gavin Andresen
2011-12-14 2:30 ` Walter Stanish
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox