Aliases

I wrote this pre-draft:

https://en.bitcoin.it/wiki/BIP_0015

It's merely a starter for discussions.

Aliases are a way to lookup bitcoin addresses so I can type genjix@genjix•net instead of 1jkddsjdskjwnk2j3kj232kjdkj

OK, my thoughts. My order of preference is: web service, server service, DNS TXT records.

FirstBits + Vanitygen is out of the question in my mind. Not robust enough.

I like web service since anyone can trivially set one up. You can provide a PHP script and a text file (that users edit) that people upload to XFreeWebHost and then they're instantly set to go. Setting up a web host is very easy nowadays- as easy as click click click.

The other ideas are not so easy.

Also HTTPS + CA is the most secure of the bunch.

I'm curious to hear any other ideas too.

Thanks.

----- Original Message ----- From: Amir Taaki <zgenjix@yahoo•com> To: "bitcoin-development@lists•sourceforge•net" <bitcoin-development@lists•sourceforge•net> Cc: Sent: Monday, December 12, 2011 10:21 PM Subject: [BIP 15] Aliases

I wrote this pre-draft:

https://en.bitcoin.it/wiki/BIP_0015

It's merely a starter for discussions.

Aliases are a way to lookup bitcoin addresses so I can type genjix@genjix•net instead of 1jkddsjdskjwnk2j3kj232kjdkj

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.

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.

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
>

Are there any PGP key servers that support EC key pairs? OpenPGP Spec RFC2440 defines key types for EC, just not sure if they were ever implemented on the keyserver side. Could even have a similar 'web of trust' using private keys to sign people's identities similar to PGP.

Will

On 12 December 2011 23:16, Zell Faze <zellfaze@yahoo•com> wrote:

> 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
>

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...

On Tue, 2011-12-13 at 00:37 +0100, Jorge Timón wrote:

> 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.

Firstbits isn't acceptable for anything. As Amir originally pointed out, it doesn't scale well and worst of all it fills the blockchain with a ton of crap to get 1 satoshi at an address so that it is "registered".

>
> 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.

Firstbits is unacceptable because it causes unnecessary harm to each Bitcoin node. However, if one were to use a chain specifically crafted for such a purpose isn't terrible. That said, it still doesn't scale well and if it becomes popular virtually every implementation would have to rely on trusted servers at which point you are better off going back to an HTTPS/DNSSEC-based implementation

Matt

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...
>

> 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

> 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.

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.

>> 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...

Grabbing is no more an issue than mining Bitcoins is an issue. Sure, domain grabbers will have the domains first, but they want to profit and therefore are willing to sell them for whatever price they can get. Just like the trading of any other limited resource, this process sounds like somebody is getting rich for nothing, but it does tend to put the limited resources to good use as people who waste good domains can't afford them in the long run. The problem with Firstbits is that the names already grabbed have fixed private keys that are known by their originators. That makes the names untradable. This may be fixable with split keys, but a lot of "good" 1firstbits are already made useless in this way.

Names in Namecoin can be transferred/traded securely, strong cryptography is built in and it shares mining without bloating the Bitcoin block chain. I see it as a decentralized DNS alternative at a time when domain seizures are on the rise, even absent any court order.

So I would use one of the DNS-based solutions that Amir suggested and simply require standard-compliant clients to be able to look up .bit (i.e. Namecoin) domains as well. That way we have a pragmatic solution, but one that also provides security and true decentralization for the more paranoid of our users.

On 12/13/2011 12:41 AM, Luke-Jr wrote:

> 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...
>
> ------------------------------------------------------------------------------
> 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
>

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.

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.

I like the user@server•com model. The protocol should be done entirely in DNS, though, not using HTTP connections to the server. Then the protocol can easily be used with Namecoin or other DNS replacements/enhancements later. Crypto to prevent MITM attacks can be an optional part of the protocol.

Almost all users will be unable to set up *any* always-on Internet service to answer queries, so I'm not too concerned about how easy it is to set up the server software.

I agree that FirstBits is bad for this. Unlike DNS, "registrations" last forever because private keys can't be transferred safely. All short names will be taken quickly. It will also be very expensive for clients to query this themselves.

The CA model is broken and it should never be used by Bitcoin.

@Matt I didn't thought about firstbits scalability, but the "registering crap" and squatting arguments don't apply to green addresses because no one wants fancy or easy to memorize names there. Is just a way to make the bitcoin addresses shorter in the green addresses protocol to be able to have various of them in the same QR-code.

@Amir I see, the point is to be able to type the alias directly into the client.

I like the DNS proposal. This would allow for both well known working centralized technology and namecoin (not proven, but decentralized) options to be used.

2011/12/13, theymos <theymos@mm•st>:

> I like the user@server•com model. The protocol should be done entirely
> in DNS, though, not using HTTP connections to the server. Then the
> protocol can easily be used with Namecoin or other DNS
> replacements/enhancements later. Crypto to prevent MITM attacks can be
> an optional part of the protocol.
>
> Almost all users will be unable to set up *any* always-on Internet
> service to answer queries, so I'm not too concerned about how easy it is
> to set up the server software.
>
> I agree that FirstBits is bad for this. Unlike DNS, "registrations" last
> forever because private keys can't be transferred safely. All short
> names will be taken quickly. It will also be very expensive for clients
> to query this themselves.
>
> The CA model is broken and it should never be used by Bitcoin.
>
> ------------------------------------------------------------------------------
> 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
>

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
>

>
> 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.

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
>
>

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.

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.

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.

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.

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.

> (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.

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

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.

> 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.

> 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.

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.

>> "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.

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

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.

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

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.

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.

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
>

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.
>
>

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.

>> 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.

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.

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.

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...

>> 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.

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

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.

> 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

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.
>
>
>

> 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

Bitcoin already has code and a protocol for transactions to IP
addresses. Why not reuse that for dynamic address lookup? Just a few
changes are necessary to enable complete user@server•com handling:
- Extend the protocol so that "reply" messages can be signed by a fixed
  public key
- Extend "checkorder" messages so they can specify an account to
  send BTC to. Or standardize on how to put the account into the
  message field.
- Enable DNS lookups for IP transactions. The DNS-only proposals could
  also be used here to avoid having to use the IP transaction protocol
  sometimes. The public key for signing "reply" messages can be gotten
  from TXT records. This will be safe with DNSSEC and Namecoin. With
  plain DNS Bitcoin could take a SSH-like approach and ask the user to
  verify the public key the first time it is used, remembering it later.

DoS attacks are already handled by the IP transactions code: the same IP address is always given the same bitcoin address until it pays to that bitcoin address.

This is maybe the best idea. I added it: https://en.bitcoin.it/wiki/BIP_0015#IP_Transactions

Things I like about this: - IP transactions are useful, but have a security flaw. This mitigates their security problems. - The code for IP transactions is already in Satoshi client. If other clients want to add IP transactions, then it can be done with minimal fuss/bloat. I feel that for any protocol extension, less is more. The less code needed, the better the extension. Not always but generally we want to avoid bitcoin protocol bloat which *will* happen far in the future. The only way to mitigate how spaghettified the standard will be in the future, is by careful cautious planning now.

- We can have a proxy node running 24/7 for us, serving our public keys in lieu of us.

________________________________ From: theymos <theymos@mm•st> To: bitcoin-development@lists•sourceforge•net Sent: Thursday, December 15, 2011 7:59 PM Subject: Re: [Bitcoin-development] [BIP 15] Aliases

Bitcoin already has code and a protocol for transactions to IP
addresses. Why not reuse that for dynamic address lookup? Just a few
changes are necessary to enable complete user@server•com handling:
- Extend the protocol so that "reply" messages can be signed by a fixed
  public key
- Extend "checkorder" messages so they can specify an account to
  send BTC to. Or standardize on how to put the account into the
  message field.
- Enable DNS lookups for IP transactions. The DNS-only proposals could
  also be used here to avoid having to use the IP transaction protocol
  sometimes. The public key for signing "reply" messages can be gotten
  from TXT records. This will be safe with DNSSEC and Namecoin. With
  plain DNS Bitcoin could take a SSH-like approach and ask the user to
  verify the public key the first time it is used, remembering it later.

DoS attacks are already handled by the IP transactions code: the same IP address is always given the same bitcoin address until it pays to that bitcoin address.

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
>
>

This is the first proposal I've seen regarding mapping something like user@host that actually makes sense to me.

Bitcoin itself is decentralised by design, in my opinion it seems obvious that it needs to continue to maintain this feature.

On Fri, Dec 16, 2011 at 8:59 AM, theymos <theymos@mm•st> wrote:

> Bitcoin already has code and a protocol for transactions to IP
> addresses. Why not reuse that for dynamic address lookup? Just a few
> changes are necessary to enable complete user@server•com handling:
> - Extend the protocol so that "reply" messages can be signed by a fixed
>  public key
> - Extend "checkorder" messages so they can specify an account to
>  send BTC to. Or standardize on how to put the account into the
>  message field.
> - Enable DNS lookups for IP transactions. The DNS-only proposals could
>  also be used here to avoid having to use the IP transaction protocol
>  sometimes. The public key for signing "reply" messages can be gotten
>  from TXT records. This will be safe with DNSSEC and Namecoin. With
>  plain DNS Bitcoin could take a SSH-like approach and ask the user to
>  verify the public key the first time it is used, remembering it later.
>
> DoS attacks are already handled by the IP transactions code: the same IP
> address is always given the same bitcoin address until it pays to that
> bitcoin address.
>
>

On Thu, 2011-12-15 at 13:59 -0600, theymos wrote:

> Bitcoin already has code and a protocol for transactions to IP
> addresses. Why not reuse that for dynamic address lookup? Just a few
> changes are necessary to enable complete user@server•com handling:

I'm not against this, but I think its way overcomplicated when compared to the DNS or HTTPS methods.

> - Extend the protocol so that "reply" messages can be signed by a fixed
>   public key
> - Extend "checkorder" messages so they can specify an account to
>   send BTC to. Or standardize on how to put the account into the
>   message field.

OK, not too debatable, but considering how terrible bitcoind's account handling is, the second might not be easy to get right...

> - Enable DNS lookups for IP transactions. The DNS-only proposals could
>   also be used here to avoid having to use the IP transaction protocol
>   sometimes. The public key for signing "reply" messages can be gotten
>   from TXT records. This will be safe with DNSSEC and Namecoin. With
>   plain DNS Bitcoin could take a SSH-like approach and ask the user to
>   verify the public key the first time it is used, remembering it later.

This is where I think this method becomes way overcomplicated. Not only do you have to update the IP-Transaction code, but now you have to implement the full DNS System that is the other option as well. Note that to make this secure, we have to have a full DNSSEC-capable resolver built-into bitcoind (there are libs, but it has to happen). Yes you can ask the user "does this fingerprint look right to you? Y/N" but that always opens you up to a ton of users getting screwed out of coins and I don't think it should be enabled, except in bitcoind, and since the main target of this whole alias system is bitcoin-qt users, well...

Matt

> Bitcoin itself is decentralised by design, in my opinion it seems obvious
> that it needs to continue to maintain this feature.

What's the real issue?

- People want to use alternate representations ('aliases') of bitcoin addresses, for various reasons. - The blockchain is the only way to create distributed consensus within the bitcoin network. - Very few people - even those who wish to have a permanent alias - want to have it map to a permanent bitcoin address, since this discloses their financial history (eg: income for a business) to the public - Some people want throw-away (single use) aliases, others want permanent ones. This means many addresses. - Blockchain bloat is already acknowledged as an issue. - The blockchain is not really a good option.

Leaving out the blockchain, there are still ways to implement aliasing.

What is the core problem for an extra-blockchain aliasing system?

At the core is usability - people basically want aliases to make it easier to type in or remember addresses. So a solution that sacrifices usability too far is a broken one.

Another requirement is absolute security. A user of the aliasing system is going to trust it to translate a particular alias to a bitcoin address - ie: 'where my money goes with absolutely zero chance (by default) of getting it back if it's sent somewhere wrong by accident'. Such an accident might be mistyping an alias. It might also be a hijacking of the alias resolution system (eg: a DNS based system without DNSSEC, etc.). As a case in point, we already see very well organized attacks by domain squatters in order to steal traffic or effect phishing under the DNS system.

So... to help see which qualities are meaningful for such an alias system, let's look at what types of solutions to these problems exist within conventional (ie: mature) financial systems.

First, arbitrary aliases are not in use. This means that memory-based mnemonics are not subject to predictable squatting-style attacks. For our purposes, this means that if you are payments@business1•com, I can't go and register payments@busines1•com and take a portion of your inbound cash whenever a client tries to pay you and typos on the send address. Likewise, if you're 'someuser@hostedwalletservice•com' I can't go and register as 'someuse@hostedwalletservice•com' and pull the same heist. IIBAN is the only aliasing proposal I have seen mentioned within this thread that adopts this strategy, the others all maintain this vulnerability through DNS. HTTP relies on DNS.

Second, checksum systems detect transposition errors. This is a very powerful feature, which (I can't be bothered googling for stats, but just think about it) cuts out the vast majority of such errors instantly, at the time of input, before money changes hands or anything touches the financial settlement networks. IIBAN adopts exactly the same mature and proven MOD97-based two digit checksum feature that is used within the IBAN standard, proposed by the European Union with the benefit of decades of banking experience in many member states and now growing rapidly in use around the world. (For something as expensive and painful to implement as a nationally-mandated banking standard affecting all member banks, a growth rate of 'a few countries per year' is a pretty serious growth curve!) With checksums, it's even possible to auto-suggest corrections based upon common transposition errors and help the user to check those parts of the alias for common errors more quickly.

Third, conventional financial systems typically require recipient name (and sometimes address, or business tax numbers in some countries' domestic schemes) as part of the transaction. This secondary data facilitates error checking since an incorrectly supplied destination address can be checked against these properties. Of course, Bitcoin presently has no such secondary input with which to verify the destination of a transfer, and since blockchain bloat is an acknowledged issue and very few bitcoin users would like to see their names appear against their transactions within the blockchain (visible to all, for eternity!) it also seems that this feature is not going to be added and for good reason. However, within an external (and not necessarily bitcoin specific) higher-level 'transaction negotation' protocol (alluded to in earlier posts as a logical extension of the pre transaction alias resolution mechanism, and being a pre transaction connection of some nature between a payer and payee, or their proxying/representing institution, in the case of hosted wallets/aliases), such external destination validation features could be added. (Many types are possible... data-based as per name/address validation, cryptographic validation schemes, etc.)

Finally, an increasing number of countries use an aliasing scheme (IBAN) that is familiar to users. Doing so for digital currencies such as Bitcoin increases usability (by eliminating novelty, and in the case of IIBAN which is not specific to any given currency, the need to register, recall and manage yet another account identifier), which was one of the original goals. None of the other proposals mentioned have this property.

I won't go in to other benefits previously mentioned of the IIBAN proposal, but I still cannot see any reason to either: - Include aliasing within bitcoind itself - Re-invent the wheel - Scare off non-technical users - Dodge the fact that there are unique properties of bitcoin that will always remain and should perhaps simply be acknowledged and worked around OUTSIDE of the codebase, rather than within. Unix/internet philosophy is that it's usually best to keep code as simple as possible, to 'do one thing' and 'do it well'. For bitcoind (despite sharing a codebase with the GUI), that something is achieving a distributed internet-based financial system that is free from legacy centralized currencies. It is *not* worrying about making it look pretty or easy to use, which can be achieved by layering totally external systems through simply translating various alternate representations ('aliases') to the well defined bitcoin addressing scheme.

Just to avoid any notion of table-banging (Hah! A lost cause?), this will be the last IIBAN-related post I will make on this thread, but there will be some further announcements in the near future.

Keep up the good work everyone.

Regards, Walter Stanish Payward Inc.

>> 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.

On Mon, Dec 12, 2011 at 02:21:09PM -0800, Amir Taaki wrote:

> I wrote this pre-draft:
>
>
> https://en.bitcoin.it/wiki/BIP_0015
>
> It's merely a starter for discussions.

Interesting discussion so far, with many nice ideas.

I'll try to give my opinion and comment on some in batch here.

First of all, I'm a big proponent of moving away from using base58 strings as addresses. They are not flexible and not human-friendly. I did an own proposal to improve the situation some time ago, see

  https://gist.github.com/1237788

There was little reaction, and maybe the reason is we shouldn't try to solve/fix everything at once.

a) IP transactions-like system with DNS resolution

Not only does this give you nice identifiers, but it also moves the responsibility of getting the transaction accepted by the network from the sender to the receiver - the one who actually cares about getting his money.

The authentication problem that was present in the original IP transactions system can either be mitigated by trusting the existing SSL public-key intrastructure (which not everyone may like) or (as Satoshi suggested) adding bitcoin address-based authentication on top (separate from the address used in the transaction itself). So you get an identifier like <url>$<btcaddress>, and the communication to <url> would be authenticated using <btcaddress>. This is obviously not useful as human-typable alias, but is no problem for clickable URLs on websites that want to provide the additional security.

I'm not sure about using the bitcoin p2p protocol here - i think there are easier (or at least more widely deployed) protocols like HTTP. So maybe ...

b) HTTPS Web Service

we can just use an HTTPS web service, that provides the bitcoin address to be used in the transaction to a client that queries a URL. This immediately makes the identifier double as a clickable URL, and a merchant could add metadata to the URL to make the transaction easily trackable.

As for the possibility for spoofing: relying on DNSSEC is currently difficult i believe (though i'm not entirely up-to-date about its deployment). Again, alternatives are the SSL PKI, or bitcoin address-based authentication (basically doing SSL but using bitcoin pubkeys to authenticate)

c) user@hostname-like identifiers

These look very good, and conveniently match the e-mail system's identifiers. However, I believe they are only useful for one purpose: user-to-user payments. For anything somewhat more business-y you probably want to use a clickable URL, and hide all address information entirely from the user. Still, for user-to-user payments they are nice.

I'm not convinced about the hardcoding of the "https://" and "/bitcoin-alias/?handle=" parts, though. These seem very arbitrarily chosen to me, but if you consider an HTTPS-based variant of a bitcoin ip-transactions-like system, the proposed "account" parameter to checkorder would probably become a CGI parameter anyway...

d) DNS TXT lookups

I'm not entirely against this, but only allowing a fixed bitcoin address to be returned would far too strongly encourage the use of fixed addresses in transactions. If anything, it should be an identifier for one of the other proposals (which do allow interaction, or at least creation of a fresh bitcoin address) that is returned.

To conclude: my suggestion would be to use URLs as address identifiers, optionally suffixed with a bitcoin address for authentication. This means my "address" would be either "sipa.be/pw.btc" or "sipa.be/pw.btc$14TYdpodQQDKVgvUUcpaMzjJwhQ4KYsipa" (where "https://") is an implicit default. Initiating a payment to either of these would result in a GET of https://sipa.be/pw.btc. When a transaction is constructed, it is POSTed back to that URL.

If we can agree on reasonable hardcoded mapping, pw@sipa•be could just be a shorthand for either of these (though vulnerable to proofing...).

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.

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
>

On Fri, Dec 16, 2011 at 12:35 AM, Pieter Wuille <pieter.wuille@gmail•com> wrote:

> On Mon, Dec 12, 2011 at 02:21:09PM -0800, Amir Taaki wrote:
>> I wrote this pre-draft:

[snip]

>
> To conclude: my suggestion would be to use URLs as address identifiers,
> optionally suffixed with a bitcoin address for authentication.
> This means my "address" would be either "sipa.be/pw.btc" or
> "sipa.be/pw.btc$14TYdpodQQDKVgvUUcpaMzjJwhQ4KYsipa" (where "https://")
> is an implicit default. Initiating a payment to either of these would
> result in a GET of https://sipa.be/pw.btc. When a transaction is
> constructed, it is POSTed back to that URL.
>
> If we can agree on reasonable hardcoded mapping, pw@sipa•be could just
> be a shorthand for either of these (though vulnerable to proofing...).

I believe that any URI scheme will still leverage DNS and inherit any base issues you would have with TXT records. I suggest looking at DANE and reviewing their work on hardening certificate (x.509) infrastructure as your HTTPS scheme will inherit the issues we currently experience with CAs getting p0wned.

Hardening the protocols and usability are related. Please look at some of the work done in the IETF which has a long history in addressing many of the issues you are considering. Review some of the elegance in the bitcoin protocols. The proposals in this thread are neither clear nor elegant. If you can't reach nearly the same level of sophistication then I suggest you rethink your scheme.

-rick

On Fri, Dec 16, 2011 at 08:03:28AM -0800, Rick Wesson wrote:

> Hardening the protocols and usability are related. Please look at some
> of the work done in the IETF which has a long history in addressing
> many of the issues you are considering. Review some of the elegance in
> the bitcoin protocols. The proposals in this thread are neither clear
> nor elegant. If you can't reach nearly the same level of
> sophistication then I suggest you rethink your scheme.

That's why you use URI + bitcoin address pairs, and use SSL communication authenticated using the respective bitcoin pubkey. They may spoof your DNS server, they can't fake having the requested corresponding private key.

Obviously, this moves the problem to getting the URL + address securely to the client that wants to interact with it, but that is inevitable if you're not going to rely on a pre-trusted certificate authority and PKI.

Also, the client software can cache the address corresponding to a particular server or URL, making it similar to an ssh client that caches host keys and warns when they change.

On Fri, Dec 16, 2011 at 8:17 AM, Pieter Wuille <pieter.wuille@gmail•com> wrote:

> On Fri, Dec 16, 2011 at 08:03:28AM -0800, Rick Wesson wrote:
>> Hardening the protocols and usability are related. Please look at some
>> of the work done in the IETF which has a long history in addressing
>> many of the issues you are considering. Review some of the elegance in
>> the bitcoin protocols. The proposals in this thread are neither clear
>> nor elegant. If you can't reach nearly the same level of
>> sophistication then I suggest you rethink your scheme.
>
> That's why you use URI + bitcoin address pairs, and use SSL communication
> authenticated using the respective bitcoin pubkey. They may spoof your DNS
> server, they can't fake having the requested corresponding private key.

You are making my point (again) regarding usability and security. Aliases are not a https secured URI+bitcoin address.

-rick

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
>
>

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

On 2011 December 16 Friday, Rick Wesson wrote:

> I believe that any URI scheme will still leverage DNS and inherit any
> base issues you would have with TXT records. I suggest looking at DANE

HTTPS takes care of that.

> and reviewing their work on hardening certificate (x.509)
> infrastructure as your HTTPS scheme will inherit the issues we
> currently experience with CAs getting p0wned.

This is the only real problem with HTTPS: we would be centralising part of our otherwise decentralised system. CAs are certainly a risk.

However, trust is needed somewhere in the communication. There is no way to securely communicate between A and B without the use of some previously trusted secure channel -- in Joe Sixpack's case it's by assuming that the browser he downloaded came with an untainted CA list, and that the CAs are trustworthy. Neither of which is guaranteed. Until and unless we get PGP support in browsers, CAs are all that we have.

Worrying about CAs misses the point anyway; if we're being that paranoid -- how did A tell B the appropriate alias to use for a lookup? Was that channel secure too? I could set up a MITM server that simply looks for the alias "RICKWESSON@bitcoinaliases•org" and rewrites it to "ANDYPARKINS@bitcoinaliases•org". When the answer to that problem is HTTPS (or some other system that requires a previously authorised secure channel for transfer of trust), then we're back where we started, and HTTPS is acceptable.

Andy

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 15/12/2011 20:59, theymos a écrit :

> Bitcoin already has code and a protocol for transactions to IP
> addresses. Why not reuse that for dynamic address lookup? Just a few
> changes are necessary to enable complete user@server•com handling:
> - Extend the protocol so that "reply" messages can be signed by a fixed
>   public key
> - Extend "checkorder" messages so they can specify an account to
>   send BTC to. Or standardize on how to put the account into the
>   message field.
> - Enable DNS lookups for IP transactions. The DNS-only proposals could
>   also be used here to avoid having to use the IP transaction protocol
>   sometimes. The public key for signing "reply" messages can be gotten
>   from TXT records. This will be safe with DNSSEC and Namecoin. With
>   plain DNS Bitcoin could take a SSH-like approach and ask the user to
>   verify the public key the first time it is used, remembering it later.
>
> DoS attacks are already handled by the IP transactions code: the same IP
> address is always given the same bitcoin address until it pays to that
> bitcoin address.
>
> ------------------------------------------------------------------------------
> 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
>

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.
>

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

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).

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

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.

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

Khalahan, honestly, using namecoin for aliases is (for me) clean example of over-engineering. I mean - it will definitely work if implemented properly. I played with a namecoin a bit (as my pool was the first 'big' pool supporting merged mining), but I think there's really long way to provide such alias system in namecoin and *cleanly integrate it with bitcoin*. Don't forget that people who want to do lookup need to maintain also namecoin blockchain with their bitcoin client. It goes against my instinct of keeping stuff easy.

For example, yesterday I implemented HTTPS lookup for addresses into my fork of Electrum client. I did it in 15 minutes, it works as expected, it does the job and the implementation is really transparent, becuase implementation is 20 lines of code. There's no magic transformation, no forced "?handle=" parameters or whatever. And I don't care if somebody provide URL https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True

And everybody can do the same in their clients, in their merchant solutions, websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS, Namecoin, IIBAN, email aliases to other programmers...

Those IIBAN - well, why not. At least I see the potential in PR. So far I understand it as some teoretic concept which is not supported by anything else right now. Give it few years until it matures and then add IIBAN alias to Bitcoin client too.

Maybe I'm repeating myself already, but the way to go is to make aliases as easy as possible, so everybody can implement it in their own solution and thus practially remove the need of using standard bitcoin addresses for normal users. Using some superior technology, which is hard to implement or even understand won't solve the situation, because it will ends up with some reference implementation in standard client only and nobody else will use it.

slush

On Fri, Dec 16, 2011 at 6:23 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.
>
>

I think IBANs are not such a good idea. Note that as someone who has spent the last year of my life dealing with hundreds of bank transactions a day and interacting with the banking system (both on a technical, systematic and personnel level), the entire system is a gigantic mess.

The banks are in fact looking to us for answers. That's why we (Bitcoin Consultancy) were invited to the SWIFT conference to join their panel on bank 2.0.

I don't even mind the maxim "take everything the banks have done and do the complete opposite" :)

I invite anyone who is skeptical to read the ECB's specification on SEPA payments. It really is an example of a system made to work alongside legacy systems that rely on inefficient people. The interchange fees are dependent on a totally arbitrary test of merchant indifference and various antitrust regulations.

These systems are usually built not by engineers or hackers, but by finance people. IBAN has no place in bitcoin IMO.

I don't mean to sound too critical, but I'm skeptical of its usefulness. Especially when we already have bitcoin addresses with their own checksums- what value do IBANs add? Nothing except negatives.

________________________________ From: slush <slush@centrum•cz> To: Khalahan <khal@dot-bit•org> Cc: bitcoin-development@lists•sourceforge•net Sent: Friday, December 16, 2011 7:54 PM Subject: Re: [Bitcoin-development] [BIP 15] Aliases

Khalahan, honestly, using namecoin for aliases is (for me) clean example of over-engineering. I mean - it will definitely work if implemented properly. I played with a namecoin a bit (as my pool was the first 'big' pool supporting merged mining), but I think there's really long way to provide such alias system in namecoin and *cleanly integrate it with bitcoin*. Don't forget that people who want to do lookup need to maintain also namecoin blockchain with their bitcoin client. It goes against my instinct of keeping stuff easy.

For example, yesterday I implemented HTTPS lookup for addresses into my fork of Electrum client. I did it in 15 minutes, it works as expected, it does the job and the implementation is really transparent, becuase implementation is 20 lines of code. There's no magic transformation, no forced "?handle=" parameters or whatever. And I don't care if somebody provide URL https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True

And everybody can do the same in their clients, in their merchant solutions, websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS, Namecoin, IIBAN, email aliases to other programmers...

Those IIBAN - well, why not. At least I see the potential in PR. So far I understand it as some teoretic concept which is not supported by anything else right now. Give it few years until it matures and then add IIBAN alias to Bitcoin client too.

Maybe I'm repeating myself already, but the way to go is to make aliases as easy as possible, so everybody can implement it in their own solution and thus practially remove the need of using standard bitcoin addresses for normal users. Using some superior technology, which is hard to implement or even understand won't solve the situation, because it will ends up with some reference implementation in standard client only and nobody else will use it.

slush

On Fri, Dec 16, 2011 at 6:23 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.

>
>

On Fri, Dec 16, 2011 at 21:10, Amir Taaki <zgenjix@yahoo•com> wrote:

> Especially when we already have bitcoin addresses with their own checksums-
> what value do IBANs add?

Well, I'm not an expert like you, but one benefit would be to be compatible with existing software solutions that are based on using IBANs.

H

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

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

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

The number of proposals <https://en.bitcoin.it/wiki/BIP_0015> is not infinite, here are their problems :

- FirstBits : centralized - DNS TXT Records : DNSSEC is required to have a minimum of security, limits usage to engineers, limits usage to some domain names (i won't be able to use a gmail address for example, because i don't control the gmail.com domain) - Server Service (DNS + a daemon) : Same as DNS TXT records - HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be able to check the full certificate chain and access a list of up-to-date certificate authorities (installed on the OS or provided with bitcoin). And don't forget the CA model is not 100% reliable (several CA hacked this year + possible government control...). - IP Transactions : /This proposal seeks to enable DNS lookups for IP transactions/ => same as above

I know that providing a namecoin daemon with bitcoin is not the lighter solution, but, if a better one existed i guess it would have already been integrated into bitcoin... (see in what state is my first attempt with the HTTPS proposal : Send payments to emails, urls and domains in GUI <https://github.com/bitcoin/bitcoin/pull/174> - /khalahan opened this pull request April 20, 2011/)

So, what's next ?

Le 16/12/2011 20:54, slush a écrit :

> Khalahan, honestly, using namecoin for aliases is (for me) clean
> example of over-engineering. I mean - it will definitely work if
> implemented properly. I played with a namecoin a bit (as my pool was
> the first 'big' pool supporting merged mining), but I think there's
> really long way to provide such alias system in namecoin and *cleanly
> integrate it with bitcoin*. Don't forget that people who want to do
> lookup need to maintain also namecoin blockchain with their bitcoin
> client. It goes against my instinct of keeping stuff easy.
>
> For example, yesterday I implemented HTTPS lookup for addresses into
> my fork of Electrum client. I did it in 15 minutes, it works as
> expected, it does the job and the implementation is really
> transparent, becuase implementation is 20 lines of code. There's no
> magic transformation, no forced "?handle=" parameters or whatever. And
> I don't care if somebody provide URL
> https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True
> <https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True>
>
> And everybody can do the same in their clients, in their merchant
> solutions, websites or whatever. Everybody can do HTTPS lookup. But
> try to explain DNS, Namecoin, IIBAN, email aliases to other programmers...
>
> Those IIBAN - well, why not. At least I see the potential in PR. So
> far I understand it as some teoretic concept which is not supported by
> anything else right now. Give it few years until it matures and then
> add IIBAN alias to Bitcoin client too.
>
> Maybe I'm repeating myself already, but the way to go is to make
> aliases as easy as possible, so everybody can implement it in their
> own solution and thus practially remove the need of using standard
> bitcoin addresses for normal users. Using some superior technology,
> which is hard to implement or even understand won't solve the
> situation, because it will ends up with some reference implementation
> in standard client only and nobody else will use it.
>
> slush

On Fri, Dec 16, 2011 at 1:52 PM, Khalahan <khal@dot-bit•org> wrote:

> The number of proposals is not infinite, here are their problems :
>
> - FirstBits : centralized
> - DNS TXT Records : DNSSEC is required to have a minimum of security, limits
> usage to engineers, limits usage to some domain names (i won't be able to
> use a gmail address for example, because i don't control the gmail.com
> domain)

The same goes for http(s) one would not be able to use http://google.com/user unless google offers the services.

ALSO look at DANE for getting around the certificate requirement for https

> - Server Service (DNS + a daemon) : Same as DNS TXT records

DNS TXT are not the only way forward, also registry/registrars can facilitate.

> - HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be able to
> check the full certificate chain and access a list of up-to-date certificate
> authorities (installed on the OS or provided with bitcoin). And don't forget
> the CA model is not 100% reliable (several CA hacked this year + possible
> government control...).

This most likely relies on a paid, valid certificate (that expires), no self signed certs. I admit that running a secured https server with a valid CA signed cet is as simple/hard as running a DNSSEC authority zone.

using a x.509 certificate to secure a bitcoin transaction removes some of the anonymity of the transaction by allowing the lookup to identify the certification, ca, crl etc thus connecting a transaction/bitcoin address to the cert and to its issuing authority. No matter the frequency of the destination bitcoin address changing.

IMNSHO, leveraging CAs to secure http to provide a lookup translation to a bitcoin address will only erode anonymity. While DNS is connected to whois there are provision for hiding behind a proxy where to the best of my knowledge there are no such provisions offered by CA's issuing x.509 certificates.

Should self signed cers be "allowed" or encouraged only decreases security. Clearly DANE would be the only way to mitigate this situation but then you are back to relying on DNSSEC to bind the x.509 cert.

wash, rinse, ...

-rick

> - IP Transactions : This proposal seeks to enable DNS lookups for IP
> transactions => same as above
>
> I know that providing a namecoin daemon with bitcoin is not the lighter
> solution, but, if a better one existed i guess it would have already been
> integrated into bitcoin... (see in what state is my first attempt with the
> HTTPS proposal : Send payments to emails, urls and domains in GUI - khalahan
> opened this pull request April 20, 2011)
>
> So, what's next ?
>
> Le 16/12/2011 20:54, slush a écrit :
>
> Khalahan, honestly, using namecoin for aliases is (for me) clean example of
> over-engineering. I mean - it will definitely work if implemented properly.
> I played with a namecoin a bit (as my pool was the first 'big' pool
> supporting merged mining), but I think there's really long way to provide
> such alias system in namecoin and *cleanly integrate it with bitcoin*. Don't
> forget that people who want to do lookup need to maintain also namecoin
> blockchain with their bitcoin client. It goes against my instinct of keeping
> stuff easy.
>
> For example, yesterday I implemented HTTPS lookup for addresses into my fork
> of Electrum client. I did it in 15 minutes, it works as expected, it does
> the job and the implementation is really transparent, becuase implementation
> is 20 lines of code. There's no magic transformation, no forced "?handle="
> parameters or whatever. And I don't care if somebody provide URL
> https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True
>
> And everybody can do the same in their clients, in their merchant solutions,
> websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS,
> Namecoin, IIBAN, email aliases to other programmers...
>
> Those IIBAN - well, why not. At least I see the potential in PR. So far I
> understand it as some teoretic concept which is not supported by anything
> else right now. Give it few years until it matures and then add IIBAN alias
> to Bitcoin client too.
>
> Maybe I'm repeating myself already, but the way to go is to make aliases as
> easy as possible, so everybody can implement it in their own solution and
> thus practially remove the need of using standard bitcoin addresses for
> normal users. Using some superior technology, which is hard to implement or
> even understand won't solve the situation, because it will ends up with some
> reference implementation in standard client only and nobody else will use
> it.
>
> slush
>
>
> --
> Best Regards,
> Khalahan
> http://dot-bit.org/
>
>
> ------------------------------------------------------------------------------
> 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
>

If we chose the simple URI proposal namecoin can still be integrated to map the IP of the server by those who want to. Does it removes the necessity of the certificates? If so, we should let people decide between HTTP, HTTPS, namecoin or whatever they trust.

Shouldn't we be also discussing the valid format of the answered message? I mean fields like "amount", "concept" and such.

I can't speak for Namecoin. As for the HTTPS requirement, I'm on the fence. Without it, the resolution is open to a man in the middle attack. Perhaps HTTPS should be required, and if HTTP is used, a large warning message is displayed.

As for the answered message format, is JSON the assumed structure that would be used?

On 12/18/2011 1:05 PM, Jorge Timón wrote:

> If we chose the simple URI proposal namecoin can still be integrated
> to map the IP of the server by those who want to.
> Does it removes the necessity of the certificates?
> If so, we should let people decide between HTTP, HTTPS, namecoin or
> whatever they trust.
>
> Shouldn't we be also discussing the valid format of the answered
> message? I mean fields like "amount", "concept" and such.
>

On Sunday, December 18, 2011 4:05:11 PM Jorge Timón wrote:

> If we chose the simple URI proposal namecoin can still be integrated
> to map the IP of the server by those who want to.
> Does it removes the necessity of the certificates?
> If so, we should let people decide between HTTP, HTTPS, namecoin or
> whatever they trust.

How are you going to authenticate the host? Certificates from CAs are how HTTPS does it. HTTP is vulnerable. If the URI contains an address (eg, bitcoin://remotehost/base58key), the remote host could sign its (self-signed) SSL key with the ECDSA key to prove authenticity. DNSSEC/namecoin presumably has some way to do this as well.

> Shouldn't we be also discussing the valid format of the answered
> message? I mean fields like "amount", "concept" and such.

At some point, a proper protocol to negotiate payment is needed for anything like this.

Maybe I'm retarded, but where's the point in providing alliases containing yet another hash in URL?

slush

On Sun, Dec 18, 2011 at 10:44 PM, Luke-Jr <luke@dashjr•org> wrote:

> On Sunday, December 18, 2011 4:05:11 PM Jorge Timón wrote:
> > If we chose the simple URI proposal namecoin can still be integrated
> > to map the IP of the server by those who want to.
> > Does it removes the necessity of the certificates?
> > If so, we should let people decide between HTTP, HTTPS, namecoin or
> > whatever they trust.
>
> How are you going to authenticate the host? Certificates from CAs are how
> HTTPS does it. HTTP is vulnerable. If the URI contains an address (eg,
> bitcoin://remotehost/base58key), the remote host could sign its
> (self-signed)
> SSL key with the ECDSA key to prove authenticity. DNSSEC/namecoin
> presumably
> has some way to do this as well.
>
> > Shouldn't we be also discussing the valid format of the answered
> > message? I mean fields like "amount", "concept" and such.
>
> At some point, a proper protocol to negotiate payment is needed for
> anything
> like this.
>
>
> ------------------------------------------------------------------------------
> 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
>

On Sunday, December 18, 2011 6:58:37 PM slush wrote:

> Maybe I'm retarded, but where's the point in providing alliases containing
> yet another hash in URL?

The point of the extended URI is to allow the server to negotiate payment details (payment/order information, fees, new privacy address, etc) rather than merely sending a simple payment to a single fixed address.

I am not convinced *aliases* are practical, without CA trust. An organization that wants to trust a CA with all their funds can leave off the address portion, to provide more human-friendly URIs.

On Mon, Dec 19, 2011 at 12:58:37AM +0100, slush wrote:

> Maybe I'm retarded, but where's the point in providing alliases containing
> yet another hash in URL?

Any DNS-based alias system is vulnerable to spoofing. If I can make people's DNS server believe that mining.cz points to my IP, I'll receive payments to you...

If no trusted CA is used to authenticate the communication, there is no way to be sure the one you are asking how to pay, is the person you want to pay. Therefore, one solution is to put a bitcoin address in the identification string itself, and requiring SSL communication authenticated using the respective key.

This makes the identification strings obviously less useful as aliases, but pure aliases in the sense of human-typable strings have imho limited usefulness anyway - in most cases these identification strings will be communicated through other electronic means anyway.

Furthermore, the embedded bitcoin address could be hidden from the user: retrieved when first connecting, and stored together with the URI in an address book. Like ssh, it could warn the user if the key changes (which wil be ignored by most users anyway, but what do you do about that?)

On Sunday, December 18, 2011 8:14:20 PM Pieter Wuille wrote:

> Furthermore, the embedded bitcoin address could be hidden from the user:
> retrieved when first connecting, and stored together with the URI in
> an address book. Like ssh, it could warn the user if the key changes
> (which wil be ignored by most users anyway, but what do you do about
> that?)

Like SSH, don't make it easy to ignore. eg, to ignore it, you need to manually go in and remove it from the URI.

Pieter, it was more rhetorical question than asking for explanation, but thanks anyway. As an Internet application developer, I of course understand security issues while using HTTPS and CA.

I have a gut feeling that there simply does not exist any single solution which is both easy to use and secure enough. At least nobody mentioned it yet. And if I need to choose between easy solution or secure solution for aliases, I'll pick that easy one. I mean - we need some solution which will be easy enough for daily use; it is something what we currently don't have. But if I want to be really really sure I'm using correct destination for paying $1mil for a house, I can every time ask for real bitcoin addresses, this is that secure way which we currently have.

slush

On Mon, Dec 19, 2011 at 2:14 AM, Pieter Wuille <pieter.wuille@gmail•com>wrote:

> On Mon, Dec 19, 2011 at 12:58:37AM +0100, slush wrote:
> > Maybe I'm retarded, but where's the point in providing alliases
> containing
> > yet another hash in URL?
>
> Any DNS-based alias system is vulnerable to spoofing. If I can make
> people's
> DNS server believe that mining.cz points to my IP, I'll receive payments
> to
> you...
>
> If no trusted CA is used to authenticate the communication, there is no way
> to be sure the one you are asking how to pay, is the person you want to
> pay.
> Therefore, one solution is to put a bitcoin address in the identification
> string itself, and requiring SSL communication authenticated using the
> respective key.
>
> This makes the identification strings obviously less useful as aliases,
> but pure aliases in the sense of human-typable strings have imho
> limited usefulness anyway - in most cases these identification strings
> will be communicated through other electronic means anyway.
>
> Furthermore, the embedded bitcoin address could be hidden from the user:
> retrieved when first connecting, and stored together with the URI in
> an address book. Like ssh, it could warn the user if the key changes
> (which wil be ignored by most users anyway, but what do you do about
> that?)
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> 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
>

Ok, so HTTP is not an option unless it shows a huge warning. I don't know the HTTPS possible attack, but maybe it needs a warning message too, from what you people are saying. Although using namecoin to identify hosts may be the more secure option, it's integration with the client seems more difficult and probably most clients won't support it. Using namecoin to directly specify the payment address seems a bad idea for most cases for the reasons that have been said.

For the "answer format" JSON seems ok, but I mean a "negotiating protocol" like luke-jr says. I'd even include green addresses there but probably many of you don't like the idea.

2011/12/19, slush <slush@centrum•cz>:

> And if I need to choose between easy solution or secure solution for
> aliases, I'll pick that easy one. I mean - we need some solution which will
> be easy enough for daily use; it is something what we currently don't have.
> But if I want to be really really sure I'm using correct destination for
> paying $1mil for a house, I can every time ask for real bitcoin addresses,
> this is that secure way which we currently have.

I agree.

On 2011 December 19 Monday, Jorge Timón wrote:

> Ok, so HTTP is not an option unless it shows a huge warning. I don't
> know the HTTPS possible attack, but maybe it needs a warning message
> too, from what you people are saying. Although using namecoin to

The problems with HTTPS have been social rather than technical. Multiple CAs have been strong-armed by governments or tricked into issuing fake certificates by scammers. There is no technical measure around that. By using the CA certificate we are saying to the system "here is someone I trust to issue a certificate". So far, with a large number of CAs, that trust is misplaced.

I'm of the opinion though that this problem is outside the remit of bitcoin to solve.

Perhaps we should be more strict about which CA certificates are trusted by the bitcoin client: say restrict it to those who have demonstrably good practices for verifying identity; rather than the ridiculous amount of trust that comes pre-installed for me in my browser.

Andy

I think HTTPS, and more specifically x.509 PKI certs and CAs are generally a good idea and (historical implementation bugs aside) the concept is technically sound and secure. What is a bad idea (in my opinion) is to trust a software vendor to decide who you should trust.. thus it is a bad idea for bitcoin software to promise any trust.

The part where the concept becomes flawed is trusting 3rd parties who have no relationship with you, to serve your interests. Now I'm just generalizing here and this is not universally true.. but internet CAs just want to sell certificates - they generally don't care beyond that, and they abuse the certificate validity dates to charge more money. All this is done under the guise of wanting to provide a secure experience to users without a prior relationship to the entity being identified. I propose that trying to follow this paradigm in bitcoin alias resolution is a bad idea because it tries to solve 2 problems at once, one of which does not have any 'good' solution, and forces a specific policy.

First, we need to resolve an alias to a bitcoin address somehow.. but secondly we need to establish trust with the entity doing the alias resolution - to make sure that we can trust the response.

When resolving an alias you will have to query an untrusted server, possibly being proxied by an 'attacker'. Presumably, an x.509 certificate will be presented, possibly self signed or chained off a self generated CA or whatever else.. but if it's your first contact then there is no possible way to know if it's correct or not. You would have to retrieve the correct public key of the CA to compare to first, possibly out of band. Get it from my website, compare it to my business card, send me an email and I'll send it to you, or get it from some other source using some other pre existing trust (a centralized and possibly private directory perhaps). The point is, the reason there is so much disagreement is because there is no good way to trust the resolver if you don't create that trust relationship prior to resolving an alias from it.

I think that having to pre-trust the resolver would be an acceptable solution to all.. Those whose policy requires a simpler process can get a 3rd party CA list, much like the ones provided with web browsers and operating systems. Those with strict verification policies can choose to pre verify every public key.. and these processes are familiar to many organizations using PKI for other things already. In a client, presenting the usual certificate detail dialog, showing the public key, subject, issuer, and thumbprint would be sufficient to allow users to implement their own policies without forcing it one way or another.

Please consider that while some organizations or users might require strong anonymity and pre existing trust, there are others who may want to do the opposite and that is just as valid, even if you or 'everyone else' disagrees with that. In the case of bitcoin, it will be used as part of a larger system, and whatever concerns are created by 'insecure' alias resolution may well be addressed in another part of the system. The most successful standards and implementations are the ones which provide the most flexibility - primarily because that allows users to extend them in ways the original designers didn't necessarily plan for.

Thanks, Laszlo

On Dec 19, 2011, at 11:44 AM, Andy Parkins wrote:

> On 2011 December 19 Monday, Jorge Timón wrote:
>> Ok, so HTTP is not an option unless it shows a huge warning. I don't
>> know the HTTPS possible attack, but maybe it needs a warning message
>> too, from what you people are saying. Although using namecoin to
>
> The problems with HTTPS have been social rather than technical.  Multiple CAs
> have been strong-armed by governments or tricked into issuing fake
> certificates by scammers.  There is no technical measure around that.  By
> using the CA certificate we are saying to the system "here is someone I trust
> to issue a certificate".  So far, with a large number of CAs, that trust is
> misplaced.
>
> I'm of the opinion though that this problem is outside the remit of bitcoin to
> solve.
>
> Perhaps we should be more strict about which CA certificates are trusted by
> the bitcoin client: say restrict it to those who have demonstrably good
> practices for verifying identity; rather than the ridiculous amount of trust
> that comes pre-installed for me in my browser.
>
>
>
> 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

You are describing the problem DANE addresses, see http://tools.ietf.org/html/draft-ietf-dane-protocol-12

Using Secure DNS to Associate Certificates with Domain Names For TLS

Abstract

   TLS and DTLS use PKIX certificates for authenticating the server.
   Users want their applications to verify that the certificate provided
   by the TLS server is in fact associated with the domain name they
   expect.  TLSA provides bindings of keys to domains that are asserted
   not by external entities, but by the entities that operate the DNS.
   This document describes how to use secure DNS to associate the TLS
   server's certificate with the intended domain name.

For those of you against DNSSEC, DANE leverages it significantly.

The point I have been attempting to make is if one to rely on HTTPS, leveraging DANE will allow you to mitigate CAs and use self signed cers but you will need to leverage DNSSEC to bind the self signed cert using DANE and if you are going to rely on DNSSEC for DANE to support HTTPS, why not short-circut this madness and just publish your identifiers and secure the zone via DNSSEC and link in a stub resolver in the client.

Short story: transform user@authority•tld --> _btc.user.athority.tld TXT 1z....

A short i-d is probably a better way to explain, so I will task myself to do that.

-rick

On Mon, Dec 19, 2011 at 6:46 AM, solar <solar@heliacal•net> wrote:

> I think HTTPS, and more specifically x.509 PKI certs and CAs are generally a good idea and (historical implementation bugs aside) the concept is technically sound and secure.  What is a bad idea (in my opinion) is to trust a software vendor to decide who you should trust.. thus it is a bad idea for bitcoin software to promise any trust.
>
> The part where the concept becomes flawed is trusting 3rd parties who have no relationship with you, to serve your interests.  Now I'm just generalizing here and this is not universally true.. but internet CAs just want to sell certificates - they generally don't care beyond that, and they abuse the certificate validity dates to charge more money.  All this is done under the guise of wanting to provide a secure experience to users without a prior relationship to the entity being identified.  I propose that trying to follow this paradigm in bitcoin alias resolution is a bad idea because it tries to solve 2 problems at once, one of which does not have any 'good' solution, and forces a specific policy.
>
> First, we need to resolve an alias to a bitcoin address somehow.. but secondly we need to establish trust with the entity doing the alias resolution - to make sure that we can trust the response.
>
> When resolving an alias you will have to query an untrusted server, possibly being proxied by an 'attacker'.  Presumably, an x.509 certificate will be presented, possibly self signed or chained off a self generated CA or whatever else.. but if it's your first contact then there is no possible way to know if it's correct or not.  You would have to retrieve the correct public key of the CA to compare to first, possibly out of band.  Get it from my website, compare it to my business card, send me an email and I'll send it to you, or get it from some other source using some other pre existing trust (a centralized and possibly private directory perhaps).  The point is, the reason there is so much disagreement is because there is no good way to trust the resolver if you don't create that trust relationship prior to resolving an alias from it.
>
> I think that having to pre-trust the resolver would be an acceptable solution to all.. Those whose policy requires a simpler process can get a 3rd party CA list, much like the ones provided with web browsers and operating systems.  Those with strict verification policies can choose to pre verify every public key.. and these processes are familiar to many organizations using PKI for other things already.  In a client, presenting the usual certificate detail dialog, showing the public key, subject, issuer, and thumbprint would be sufficient to allow users to implement their own policies without forcing it one way or another.
>
> Please consider that while some organizations or users might require strong anonymity and pre existing trust, there are others who may want to do the opposite and that is just as valid, even if you or 'everyone else' disagrees with that.  In the case of bitcoin, it will be used as part of a larger system, and whatever concerns are created by 'insecure' alias resolution may well be addressed in another part of the system.  The most successful standards and implementations are the ones which provide the most flexibility - primarily because that allows users to extend them in ways the original designers didn't necessarily plan for.
>
> Thanks,
> Laszlo
>
>
>
> On Dec 19, 2011, at 11:44 AM, Andy Parkins wrote:
>
>> On 2011 December 19 Monday, Jorge Timón wrote:
>>> Ok, so HTTP is not an option unless it shows a huge warning. I don't
>>> know the HTTPS possible attack, but maybe it needs a warning message
>>> too, from what you people are saying. Although using namecoin to
>>
>> The problems with HTTPS have been social rather than technical.  Multiple CAs
>> have been strong-armed by governments or tricked into issuing fake
>> certificates by scammers.  There is no technical measure around that.  By
>> using the CA certificate we are saying to the system "here is someone I trust
>> to issue a certificate".  So far, with a large number of CAs, that trust is
>> misplaced.
>>
>> I'm of the opinion though that this problem is outside the remit of bitcoin to
>> solve.
>>
>> Perhaps we should be more strict about which CA certificates are trusted by
>> the bitcoin client: say restrict it to those who have demonstrably good
>> practices for verifying identity; rather than the ridiculous amount of trust
>> that comes pre-installed for me in my browser.
>>
>>
>>
>> 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
>
>
> ------------------------------------------------------------------------------
> 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

On Monday, December 19, 2011 2:56:09 AM Jorge Timón wrote:

> For the "answer format" JSON seems ok,

I'd prefer we stick to simple standards. HTTP alone should really be fine to build on...

JSON in particular has very poor language support, and cannot reasonably represent binary data (such as a custom output script). The HTTP specification, however, allows binary data in multipart content just fine.

On Monday, December 19, 2011 6:44:59 AM Andy Parkins wrote:

> Perhaps we should be more strict about which CA certificates are trusted by
> the bitcoin client: say restrict it to those who have demonstrably good
> practices for verifying identity; rather than the ridiculous amount of
> trust that comes pre-installed for me in my browser.

Accepted CAs is/should be a property of your *operating system*, not any particular software. Anyhow, restricting this further just makes it even more unusable. Already there is only 1 or 2 CAs that will provide a gratis certificate for personal/small users. If you only allow high-class CAs, I imagine that will restrict "no key in the URI" aliases to those who will fork over a lot of money.

I still think HTTPS should be used, at the minimum. Using HTTPS is standard to every website out there that deals with financials, even if it is not a perfect system. Why should Bitcoin adopt a more lax policy than everyone else?

I thought that JSON support was fairly common these days. I personally prefer XML in most cases, but since JSON is already used with the RPC, it seemed like a natural fit here. Binary data can be base64 encoded, although I'm not sure why you would need to send back binary in an alias response.

What exactly do you mean by "custom output script"?

On 12/19/2011 8:30 AM, Luke-Jr wrote:

> I'd prefer we stick to simple standards.
> HTTP alone should really be fine to build on...
>
> JSON in particular has very poor language support, and cannot reasonably
> represent binary data (such as a custom output script). The HTTP
> specification, however, allows binary data in multipart content just fine.

I agree with Luke that HTTP standard has everything necessary and bloating payload with json/xml is not necessary.

Btw that argument "we have json in client already" seems pretty wrong, because json in server rpc solves another problem (and solve it in wrong way, because of data type issues, but it's another story).

slush

On Mon, Dec 19, 2011 at 6:04 PM, Jordan Mack <jordanmack@parhelic•com>wrote:

> I thought that JSON support was fairly common these days. I personally
> prefer XML in most cases, but since JSON is already used with the RPC,
> it seemed like a natural fit here. Binary data can be base64 encoded,
> although I'm not sure why you would need to send back binary in an alias
> response.
>

Using commercial CAs to establish trust is a site local administrative policy..

Bitcoin and operating systems have no technical need to concern themselves with this. It is a shame that the system has been abused by CAs paying off operating system and web browser vendors but this is not the only way to use it.. my policy may be (as an example) to require each party I deal with to generate their own self signed cert or their own CA cert (same thing really) and then I can trust that and only that. Obviously, commercial CAs will sell a certificate to anyone which means you trust anyone that is their customer. This is a valid site policy but not for everyone.

Rick Wesson's suggestion about DNSSEC and such is interesting since it would provide a system for that 'first contact' exchange where you can more reliably retrieve the certificate, if the site supports it. Some policies may not require this however - you can always get the trust established another way like downloading a cert file from a website or whatever else you consider adequately secure for your organization.

I think 3rd party CA lists and the DNSSEC/DANE idea are both useful ways to automatically establish trust out of band, but this is independent of the actual implementation of alias resolution, which happens after a trusted connection is made. Automatically establishing trust with the alias resolver is perhaps a useful feature, but not a requirement for either side to support alias resolution.

In any case, it sounds like using HTTPS and x.509 certs would allow many of these automatic trust establishment systems to be implemented on top, allowing flexible policy configuration, which seems to be important to several people in this thread of discussion.

I think using JSON would be ok but like it's been said, you either have to serialize your binary data into some text format like base64/UUencode or represent it as an integer array, both of which are inefficient.. probably cancelling out any benefit of using JSON in the first place :)

Maybe there is no need for binary data for alias resolution though.. I imagine it would be as simple as submitting a name to resolve, and giving back a base58 address string, perhaps along with a textual comment or other extra, information data.

Being strict or lax or anything else is not really a concern for alias resolution - establishing trust is an administrative issue with a lot of different solutions and not every site or application requires trust. HTTPS and mutual authentication may be desirable for general cases, however HTTP should work just as well if trust is established another way and thus SSL/TLS is not a requirement for the HTTP exchange to work. As an example use case, I may be using IPsec or any number of other systems external to bitcoin and alias resolution itself.

Laszlo

On Dec 19, 2011, at 4:35 PM, Luke-Jr wrote:

> On Monday, December 19, 2011 6:44:59 AM Andy Parkins wrote:
>> Perhaps we should be more strict about which CA certificates are trusted by
>> the bitcoin client: say restrict it to those who have demonstrably good
>> practices for verifying identity; rather than the ridiculous amount of
>> trust that comes pre-installed for me in my browser.
>
> Accepted CAs is/should be a property of your *operating system*, not any
> particular software. Anyhow, restricting this further just makes it even more
> unusable. Already there is only 1 or 2 CAs that will provide a gratis
> certificate for personal/small users. If you only allow high-class CAs, I
> imagine that will restrict "no key in the URI" aliases to those who will fork
> over a lot of money.
>
> ------------------------------------------------------------------------------
> 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

With all due respect, I continue to disagree on the topic of using HTTP for data interchange.

Yes, an HTTP multipart response will accomplish the need for multiple named resources. The problem is that parsing of a multipart response isn't simple, and library support is weak across many languages. The widely adopted cURL library does not support multipart response parsing at all.

JSON is widely adopted, human readable, and has parsing libraries available for every major language. There is a bit of additional bloat, but I believe it is warranted in this case because of the convenience and ease it brings to developers.

If the idea is to "KISS", and provide a method that is both quick and easy to implement for the average developer, then JSON is a stand out option. Using HTTP for the data interchange will make things difficult for a lot of developers if multipart responses are used. JSON will be greeted with open arms.

On 12/19/2011 9:09 AM, slush wrote:

> I agree with Luke that HTTP standard has everything necessary and
> bloating payload with json/xml is not necessary.
>
> Btw that argument "we have json in client already" seems pretty wrong,
> because json in server rpc solves another problem (and solve it in wrong
> way, because of data type issues, but it's another story).

On Monday, December 19, 2011 12:04:34 PM Jordan Mack wrote:

> I still think HTTPS should be used, at the minimum. Using HTTPS is
> standard to every website out there that deals with financials, even if
> it is not a perfect system. Why should Bitcoin adopt a more lax policy
> than everyone else?

Sure, I meant HTTP as the underlying protocol. TLS/SSL should of course be required in some form.

> I thought that JSON support was fairly common these days. I personally
> prefer XML in most cases, but since JSON is already used with the RPC,
> it seemed like a natural fit here.

JSON-RPC won't go on forever. In any case, bitcoind's use of JSON-RPC is exactly why I (and many other developers) have come to the realization how poorly supported JSON really is. Most of the common languages do have a library, but almost all of them have one issue or another (particularly around the very undefined Number type).

XML shares the same binary-data problem as JSON, too. As slush mentioned, no additional serialization is necessary anyway.

> Binary data can be base64 encoded, although I'm not sure why you would need
> to send back binary in an alias response.

Because computers work with binary. I don't think anyone wants to implement a fully functional script assembler just to send funds.

> What exactly do you mean by "custom output script"?

This suggests you need to learn more about how Bitcoin works ;) https://en.bitcoin.it/wiki/Script

In my opinion, there's not necessary any payload format (json, xml, multipart). In keeping stuff KISS, everything we need is just an address in response + potentially some stuff like HTTP redirects (for providing additional compatibility for proposal of bitcoin URIs with "amount", "label" and other parts). I don't see reason why we need some extra payload yet.

slush

On Mon, Dec 19, 2011 at 7:13 PM, Jordan Mack <jordanmack@parhelic•com>wrote:

> If the idea is to "KISS", and provide a method that is both quick and
> easy to implement for the average developer, then JSON is a stand out
> option. Using HTTP for the data interchange will make things difficult
> for a lot of developers if multipart responses are used. JSON will be
> greeted with open arms.
>
>

I don't have a strong position for or against JSON but...What about protocol buffers? Would it be too much too? Would it be simple enough for developers?

I believe I'm missing something here. I was under the interpretation that alias resolution was going the KISS route, of basically a single HTTP request and response. How do you see binary data fitting into this?

I'm not going to pretend that I know all the details of the difficulties that were encountered with JSON-RPC. But in the argument of developer accessibility, it still serves a purpose. If JSON-RPC support is removed, you will immediately lose a large pool of high level language developers. I would hope that support would not be dropped, even if it only remains as a secondary protocol with limited capability. Most high level developers are only going to use it for basic functions anyhow.

On 12/19/2011 10:15 AM, Luke-Jr wrote:

> Because computers work with binary. I don't think anyone wants to implement a
> fully functional script assembler just to send funds.
>
> JSON-RPC won't go on forever. In any case, bitcoind's use of JSON-RPC is
> exactly why I (and many other developers) have come to the realization how
> poorly supported JSON really is. Most of the common languages do have a
> library, but almost all of them have one issue or another (particularly around
> the very undefined Number type).

On Monday, December 19, 2011 1:52:54 PM Jordan Mack wrote:

> I believe I'm missing something here. I was under the interpretation
> that alias resolution was going the KISS route, of basically a single
> HTTP request and response. How do you see binary data fitting into this?

Bitcoin is a binary system. Not all payment outputs are necessarily serializable into addresses, and assuming they are would be broken-by-design. In other words, why send the user's *software* "pay to address foo" just to have it turn that into a script (of limited subset), when you can send the script itself and avoid all the possible problems? Doing this right also means that if the user's client doesn't support version 255 addresses, it still works fine.

> I'm not going to pretend that I know all the details of the difficulties
> that were encountered with JSON-RPC. But in the argument of developer
> accessibility, it still serves a purpose. If JSON-RPC support is
> removed, you will immediately lose a large pool of high level language
> developers.

JSON isn't problem-free at high-level either. To summarize one of the issues, almost every implementation of JSON treats Numbers differently based on whether they have a '.' in them or not.

MIME has been around much longer, and should have sufficient support in every language by now. For some reason, Python calls the module 'email'.

If alias resolution was guaranteed to always be just the address, then yes, I would opt for no serialization at all. A simple plain text response of an address is about as simple as it can get.

There are already a lot of good ideas floating around about how the alias protocol could be extended. Is it really going to stay that simple for long? I would personally much just have a serialized response upfront, rather than having to worry about backward compatibility in the future.

On 12/19/2011 10:17 AM, slush wrote:

> In my opinion, there's not necessary any payload format (json, xml,
> multipart). In keeping stuff KISS, everything we need is just an address
> in response + potentially some stuff like HTTP redirects (for providing
> additional compatibility for proposal of bitcoin URIs with "amount",
> "label" and other parts). I don't see reason why we need some extra
> payload yet.

I wish that was the case. It would have made my life a lot easier in the past. A lot of the MIME libraries out there are extremely buggy. MIME is just difficult to work with, and support is still weak.

Undefined content length + text based boundaries = pain in the ass.

It is in the e-mail module because that's all MIME was originally intended for. It's now grown beyond that now, but you will find the MIME functions still live in the e-mail libraries. When dealing with raw MIME encoded data, e-mail is still the most common case.

On 12/19/2011 11:16 AM, Luke-Jr wrote:

> MIME has been around much longer, and should have sufficient support in every
> language by now. For some reason, Python calls the module 'email'.

I don't think protocol buffers are as simple to implement as some would like. I would still opt for it over MIME though.

On 12/19/2011 10:50 AM, Jorge Timón wrote:

> I don't have a strong position for or against JSON but...What about
> protocol buffers?
> Would it be too much too? Would it be simple enough for developers?