Re: [Bitcoin-development] [BIP 15] Aliases

Re: [Bitcoin-development] [BIP 15] Aliases

[Zell Faze]

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.

Re: [Bitcoin-development] [BIP 15] Aliases

[Jorge Timón]

I don't think Amir wants to put it into the protocol, but I still
don't like much the proposal if it has to rely on servers.
As an aside, even if firstbits it's not useful enough for the human
memory, it is still useful for QR-codes like in the case of green
addresses's POS instant payments.

Would it be too strange to use namecoin?
Some devices may need to rely on block exploring servers, but it is
the easiest decentralized solution that comes to mind.


2011/12/13, Zell Faze <zellfaze@yahoo.com>:
> I agree with Luke-Jr.  We need to try to find a decentralized solution if we
> are going to implement BIP 15.  Bitcoin needs to remain decentralized in
> every aspect of the protocol or we lose its greatest strength.
>
> I feel like the HTTPS idea would be a great idea for a client feature, but
> not really something that should be added to the protocol.
>
> --- On Mon, 12/12/11, Luke-Jr <luke@dashjr.org> wrote:
>
>> From: Luke-Jr <luke@dashjr.org>
>> Subject: Re: [Bitcoin-development] [BIP 15] Aliases
>> To: bitcoin-development@lists.sourceforge.net, "Amir Taaki"
>> <zgenjix@yahoo.com>
>> Date: Monday, December 12, 2011, 5:32 PM
>> FirstBits looks nice at glance, but
>> is bound to create a gold-rush to grab
>> every nice-looking FirstBits address.
>>
>> HTTPS is only as secure as the (centralized) CAs, thus not
>> really any better
>> than TXT records.
>>
>> I don't think an address of some form is avoidable.
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>


-- 
Jorge Timón

Re: [Bitcoin-development] [BIP 15] Aliases

[Luke-Jr]

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

[Bitcoin-development] Fwd: [BIP 15] Aliases

[Jorge Timón]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Amir Taaki]

> 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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Daniel F]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Amir Taaki]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Luke-Jr]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Daniel F]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

>
> I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the
> wall a picture of their QR code and a bitcoin address. I don't own a mobile
> phone so the QR code is
> useless.


Fixed addresses like that are a temporary thing during Bitcoins maturation
period. They lead to merchants exposing data they probably don't realize
they're exposing, like their income, which is basically unacceptable for
any payment system.

There's no point trying to optimize a case where:

1) You are in the minority (no phone?)
2) The "perfect experience" leaks private data in such a way that would be
deemed a gross security breach by any serious payment processor.

OK, some thoughts on the general proposal, from the POV of what it'd take
for a large deployment, like for every Gmail or every Facebook user. In
terms of ease of implementation it is ordered HTTPS/HTTP then DNS trailing
by a large margin. Big sites, even small sites, typically have high-speed
load balancing and demuxing already implemented for HTTP[S] and it's
usually easy to add new endpoints. The same is *not* true of DNS, and
whilst coding up a custom DNS server is possible it's definitely a worse
fit.

FirstBits seems out of the question for the same privacy reasons as given
above. No banking system worth its salt would let everyone look up other
peoples income.

The simplest approach would be to request a full public key with an HTTPS
request like

   foo@domain ->
https://domain/_bitcoin/getnewkey?user=foo&label=Payment%20from%20Bob

If you then want to turn the resulting public key into an address before
creating a transaction you can obviously do that.

BTW the BIP is pretty hard to read. Your spec for the HTTPS proposal is a
big pile of source code. I think it's the same as above, but it's hard to
tell without more effort.

[-- Attachment #2: Type: text/html, Size: 2347 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Christian Decker]

[-- Attachment #1: Type: text/plain, Size: 3822 bytes --]

I think the scope of this BIP is not so well defined right now. We need a
way for merchants to translate a human readable, and more importantly
human-writeable, address into a bitcoin address. I agree with Mike that a
fixed address is not the way to go, because addresses should be used once
for a single transaction to be able to track payments.

While firstbits sounds attractive at first, I think we can all agree that
it just isn't feasible and would not allow per-transaction addresses. DNS
sounds interesting for fixed addresses, but caching and propagation make it
difficult to use for per-transaction addresses that are to be generated
ad-hoc.

HTTP(S) is the best option I think, merchants are probably using HTTP
anyway for their shops. So something like
http://merchant.com/btc/transaction/1234 sounds reasonable. But I think it
should not be over-engineered, it should be a simple HTTP(S) request to a
merchant specified URL that returns an ASCII document containing either a
bitcoin: URI or simply the bitcoin address or even a 301 redirect. It's no
use to start defining URL schemes, it should be left to the merchants to
define how to structure them.

This would allow a merchant to decide if he prefers per-transaction
addresses, per-user transactions, fixed addresses or any combination.

Regards,
cdecker


On Tue, Dec 13, 2011 at 11:55 AM, Mike Hearn <mike@plan99.net> wrote:

> I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the
>> wall a picture of their QR code and a bitcoin address. I don't own a mobile
>> phone so the QR code is
>> useless.
>
>
> Fixed addresses like that are a temporary thing during Bitcoins maturation
> period. They lead to merchants exposing data they probably don't realize
> they're exposing, like their income, which is basically unacceptable for
> any payment system.
>
> There's no point trying to optimize a case where:
>
> 1) You are in the minority (no phone?)
> 2) The "perfect experience" leaks private data in such a way that would be
> deemed a gross security breach by any serious payment processor.
>
> OK, some thoughts on the general proposal, from the POV of what it'd take
> for a large deployment, like for every Gmail or every Facebook user. In
> terms of ease of implementation it is ordered HTTPS/HTTP then DNS trailing
> by a large margin. Big sites, even small sites, typically have high-speed
> load balancing and demuxing already implemented for HTTP[S] and it's
> usually easy to add new endpoints. The same is *not* true of DNS, and
> whilst coding up a custom DNS server is possible it's definitely a worse
> fit.
>
> FirstBits seems out of the question for the same privacy reasons as given
> above. No banking system worth its salt would let everyone look up other
> peoples income.
>
> The simplest approach would be to request a full public key with an HTTPS
> request like
>
>    foo@domain ->
> https://domain/_bitcoin/getnewkey?user=foo&label=Payment%20from%20Bob
>
> If you then want to turn the resulting public key into an address before
> creating a transaction you can obviously do that.
>
> BTW the BIP is pretty hard to read. Your spec for the HTTPS proposal is a
> big pile of source code. I think it's the same as above, but it's hard to
> tell without more effort.
>
>
> ------------------------------------------------------------------------------
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4946 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Jorge Timón]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Gavin Andresen]

I agree with Mike Hearn and Christian Decker-- paying to
'somebody@foo.com' should become, behind the scenes, a HTTPS query to
https://foo.com/something. If you just want to (say) donate to
eff.org, then paying to '@eff.org' aught to work nicely.

And if namecoin ever takes off you'll pay to 'somebody@foo.bit'.

It seems to me that if it was DNS-based, the address should be
something like 'somebody.bitcoin.foo.com'. But I think it is unlikely
people will setup and run a custom DNS server just to support bitcoin
payments.

-- 
--
Gavin Andresen

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Amir Taaki]

Maybe I wasn't clear enough in the document, but this is the intent with the HTTPS proposal.

genjix@foo.org

Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system responds with a bitcoin address. Whether the system gives you a new address from a pool of addresses, or contacts the merchant behind the scenes is implementation defined.

I'll clarify it later. This is the relevant line:

string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" + pszEncodedNick;

Between HTTPS service and server service, I lean slightly towards HTTPS (automatic encrypted connection, CAs + all benefits of DNS). But still interested in arguments in favour of a server service (daemon answering queries).


----- Original Message -----
From: Gavin Andresen <gavinandresen@gmail.com>
To: Jorge Timón <timon.elviejo@gmail.com>
Cc: "bitcoin-development@lists.sourceforge.net" <bitcoin-development@lists.sourceforge.net>
Sent: Tuesday, December 13, 2011 1:06 PM
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

I agree with Mike Hearn and Christian Decker-- paying to
'somebody@foo.com' should become, behind the scenes, a HTTPS query to
https://foo.com/something. If you just want to (say) donate to
eff.org, then paying to '@eff.org' aught to work nicely.

And if namecoin ever takes off you'll pay to 'somebody@foo.bit'.

It seems to me that if it was DNS-based, the address should be
something like 'somebody.bitcoin.foo.com'. But I think it is unlikely
people will setup and run a custom DNS server just to support bitcoin
payments.

-- 
--
Gavin Andresen

------------------------------------------------------------------------------
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and 
improve service delivery. Take 5 minutes to use this Systems Optimization 
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 2925 bytes --]

On 2011 December 13 Tuesday, Amir Taaki wrote:

> Maybe I wasn't clear enough in the document, but this is the intent with
> the HTTPS proposal.

I don't like the idea of a hard-coded mapping at all.  We shouldn't be making 
choices on behalf of server operators.  It's up to them how they arrange their 
domain names and paths.

I also agree that DNS is not the technology to use.  DNS is a nightmare.

> genjix@foo.org
> 
> Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system
> responds with a bitcoin address. Whether the system gives you a new
> address from a pool of addresses, or contacts the merchant behind the
> scenes is implementation defined.
> 
> I'll clarify it later. This is the relevant line:
> 
> string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" +
> pszEncodedNick;
> 
> Between HTTPS service and server service, I lean slightly towards HTTPS
> (automatic encrypted connection, CAs + all benefits of DNS). But still
> interested in arguments in favour of a server service (daemon answering
> queries).

Why bother with an encoding scheme at all?  If the address

  genjix@foo.org

always maps to

  https://foo.org/bitcoin-alias/?handle=genjix

Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" and 
"?handle=" and the original email-looking "genjix@foo.org".  Just use the URL.  
Then the author of the service can use whatever they want.

 "Can I pay you 10 BTC?"
 "Sure, send it to 'https://bitcoinalias.foo.org/genjix/'"

While I might implement my alias server like this:

 "Sure, send it to 'https://google.com/bitcoin/?andyparkins'"
 "Sure, send it to 'https://parkins.co.uk/"

... or any other URL they want -- any of which suit might suit me and my 
webserver better than whatever mapping would otherwise be hard-coded.  The 
world is already very familiar with URLs so this is no more scary than the 
email address.  What's more, the email address form looks _too much_ like an 
email address, and will only lead to confusion ... "send it to genjix@foo.org"  
"so I use outlook express for that, right?"  "erm, no, you put it in your 
bitcoin client".

The URL form could easily be made to detect a browser connecting rather than a 
bitcoin client (and this is an area that would benefit from a standards 
document -- define the headers and user agent triggers that an alias server 
expects) and give them better instructions.

https can be specified as the default, so  "https://" can be optional when 
they're typing.  If, in the future, bitcoin gets a distributed peer-to-peer 
alias system, then a new URL type can be added easily "bcalias://andyparkins" 
might automatically find my node in the network and query it for an address 
(or whatever).

All of the above is exactly why OpenID chose to use URLs for ID.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[D.H.]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Luke-Jr]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[D.H.]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Joel Joonatan Kaartinen]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Jorge Timón]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Rick Wesson]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Luke-Jr]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Rick Wesson]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Zell Faze]

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
>

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Kyle Henderson]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

Just so we're clear, what is the need for HTTP at all?

A query for a string and an answer can all be handled via DNS.

On Thu, Dec 15, 2011 at 4:57 PM, Zell Faze <zellfaze@yahoo.com> wrote:

> Could we combine this proposal and the HTTPS proposal?
>
> The DNSSEC TXT record could give instructions on how to query an HTTPS
> server to get the address.  Then we get the dynamism of HTTPS without
> having a rigid URL scheme for querying the server along with the advantages
> of DNSSEC.
>
>

[-- Attachment #2: Type: text/html, Size: 739 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Zell Faze]

[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

It is a lot easier to set up an HTTP server to dynamically respond with addresses than a DNS record.  It is considered a good practice to use a different address for every payment.

------------------------
"It stopped being just a website a long time ago. For many of us, most of us, Wikipedia has become an indispensable part of our daily lives."
— Jimmy Wales, Founder of Wikipedia 
Help protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate


--- On Wed, 12/14/11, Kyle Henderson <k@old.school.nz> wrote:

From: Kyle Henderson <k@old.school.nz>
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
To: "Zell Faze" <zellfaze@yahoo.com>
Cc: "Luke-Jr" <luke@dashjr.org>, "Rick Wesson" <rick@support-intelligence.com>, bitcoin-development@lists.sourceforge.net
Date: Wednesday, December 14, 2011, 11:56 PM

Just so we're clear, what is the need for HTTP at all?

A query for a string and an answer can all be handled via DNS.

On Thu, Dec 15, 2011 at 4:57 PM, Zell Faze <zellfaze@yahoo.com> wrote:

Could we combine this proposal and the HTTPS proposal?



The DNSSEC TXT record could give instructions on how to query an HTTPS server to get the address.  Then we get the dynamism of HTTPS without having a rigid URL scheme for querying the server along with the advantages of DNSSEC.






[-- Attachment #2: Type: text/html, Size: 2342 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Walter Stanish]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Jordan Mack]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Jorge Timón]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Jorge Timón]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Walter Stanish]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 2680 bytes --]

On 2011 December 15 Thursday, Walter Stanish wrote:

> > Andy sounded very convincing when talking in favor of URLs. What's
> > wrong with his proposal?
> 
> A URI identifies a resource and is in effect an alias itself.
> Identifying a resource is different from interacting with it. So,
> while <resource-type>://<resource-type-specific-alias> will work
> sufficiently for the identification, it does not explain the
> interaction.

Quite so; the BIP15 standard shouldn't be setting the format of the URI; it 
should be setting what the format of the client-server conversation is.  
Effectively, what headers will a requesting client send?  What headers should 
a server require?  What will a server respond?

> Interaction is a requirement, since there seems to be a widely felt
> need to preserve anonymity through the use of temporary addresses.

I think that's missing the point; any aliasing scheme is definitely reducing 
your anonymity, neccessarily so -- the alias has to be looked up somewhere, 
that somewhere reduces anonymity.  If anonymity is what you want, stick with 
just a bitcoin address.  The point of an aliasing server is surely to be able 
to give a single, unchanging, well known label to a transacting party, but 
still enable that party to generate a new address per transaction.

I want my webshop to be able to say "please pay 3.20 BTC to 
https://mywebshop.com/payments/orderid=27282" to enable the automatic 
connection from orderid to bitcoin address (which my payment system can then 
monitor for payment receipt).  (This is just one example).

> Generating a temporary address requires some actual processing to
> achieve, since the issuing of the new address cannot be done without
> interacting with the entity hosting the wallet (unless I'm missing
> something?).

Well yes; but then the client has no idea what address to send to unless it 
connects to that URI... interaction/address generation is done when that 
connection is made.

In short: I don't really think that this aliasing system should be concerning 
itself with preserving anonymity of the receiving party.  That is almost 
certainly already gone (I'm hardly likely to send money to someone I don't 
know unless I like gifting random cash).  The sending party loses a little 
anonymity because their IP is revealed when they connect to the aliasing 
system.  But there is very little anonymity in a supplier-client relationship 
anyway (you have to say what goods you want, and where you want them, and you 
had to interact with a website when you were ordering already).



Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Jorge Timón]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Christian Decker]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

> But we don't have to
> define how the server will get that address.
> Some possibilities:
>
> -A static address: less anonymity, but some people may not care. Say a
> donation address.
> -The servers stores the recipient private keys and generates a new one
> for each payment.
> -The server stores a set of addresses provided by the recipient and it
> manages what address it gives in each request (like in the web service
> I told you I can't find).
>

Exactly, I think we should starting separating the minimal protocol that is
to be supported by everybody, and the rest can be summed up in a few best
practices, no need to standardize the part that to the user is transparent.
I was on the same lines as Andy, which is that in order to have require a
payment I probably have an order/transaction pending with my vendor or have
an account to be filled, so there's a 1-to-1 mapping between the details
page and the bitcoin address I have to send to.

As a further possibility we could use <meta> tags like the OpenID server
delegation mechanism. It would allow customers to open the transaction
details page, see that everything is ok, then paste the same URL into the
bitcoin client, the bitcoin client retrieves the URL, parses the meta tag
and knows what to send where. Alternatively the Bitcoin Client sends an
Accept header which tells the server to return just the address.

As for the format I'd say either a Bitcoin address or a Bitcoin URI [1]
which ought to be flexible enough as it includes amount and messages, for
the customer to be able to track transactions.

Regards,
Chris

[1] https://en.bitcoin.it/wiki/URI_Scheme

[-- Attachment #2: Type: text/html, Size: 1952 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Walter Stanish]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Pieter Wuille]

On Thu, Dec 15, 2011 at 04:26:38PM +0800, Walter Stanish wrote:
> Interaction is a requirement, since there seems to be a widely felt
> need to preserve anonymity through the use of temporary addresses.
> Generating a temporary address requires some actual processing to
> achieve, since the issuing of the new address cannot be done without
> interacting with the entity hosting the wallet (unless I'm missing
> something?).

Just replying to this one comment: yes, some interaction is always
necessary, but not necessarily directly with the entity hosting the wallet.
There are some EC crypto tricks to do this (often mentioned under
"deterministic wallets" before):

The wallet-hosting entity has a private key x, with public key X.
The address-generating entity knows X, and generates a fresh private
key y for each transaction. For each, it calculates Z=y*X, and asks
the client to pay to hash160(Z). Afterwards, it can send a bunch of
y's to the wallet hosting service, which can reconstruct z=y*x for
each. Alternatively, the y's can be generated according to a predefined
scheme instead.

-- 
Pieter

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Rick Wesson]

> 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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Rick Wesson]

[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]

Are we designing protocols or applications, its easier and better for all
involved if we design a protocol and then let the applications implement
it.

Lets stick to understanding how labels (dns) or URIs can be leveraged to
securly obtain a bitcoin address, rather than reviewing capabilities of
current applications.

-rick

On Wed, Dec 14, 2011 at 10:04 PM, Zell Faze <zellfaze@yahoo.com> wrote:

> It is a lot easier to set up an HTTP server to dynamically respond with
> addresses than a DNS record.  It is considered a good practice to use a
> different address for every payment.
>
> ------------------------
> "It stopped being just a website a long time ago. For many of us, most of
> us, Wikipedia has become an indispensable part of our daily lives."
> — Jimmy Wales, *Founder of Wikipedia*
> <http://2e740a1a.qvvo.com/>
>
> Help protect it now. Please make a donation today:
> http://www.wikimediafoundation.org/wiki/Donate
>
>
> --- On *Wed, 12/14/11, Kyle Henderson <k@old.school.nz>* wrote:
>
>
> From: Kyle Henderson <k@old.school.nz>
>
> Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
> To: "Zell Faze" <zellfaze@yahoo.com>
> Cc: "Luke-Jr" <luke@dashjr.org>, "Rick Wesson" <
> rick@support-intelligence.com>, bitcoin-development@lists.sourceforge.net
> Date: Wednesday, December 14, 2011, 11:56 PM
>
>
> Just so we're clear, what is the need for HTTP at all?
>
> A query for a string and an answer can all be handled via DNS.
>
> On Thu, Dec 15, 2011 at 4:57 PM, Zell Faze <zellfaze@yahoo.com<http://mc/compose?to=zellfaze@yahoo.com>
> > wrote:
>
> Could we combine this proposal and the HTTPS proposal?
>
> The DNSSEC TXT record could give instructions on how to query an HTTPS
> server to get the address.  Then we get the dynamism of HTTPS without
> having a rigid URL scheme for querying the server along with the advantages
> of DNSSEC.
>
>
>

[-- Attachment #2: Type: text/html, Size: 3358 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[slush]

[-- Attachment #1: Type: text/plain, Size: 4219 bytes --]

I really like this proposal with standard URLs. All other proposals like
DNS mapping or email aliases converted to URLs with some weird logic looks
strange to me.

Plain URLs (returning address in response body, redirecting to URI
"bitcoin:<address>" or anything else) are very clear solution, easy to
implement in clients and very easy to understand by people. It's also
extremely flexible - almost everybody can somewhere setup static file
containing his "personal" addresses or it's very easy to integrate such
solution with eshops (providing custom address for given order) etc. I'm
definitely for this solution.

Best,
slush

On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins <andyparkins@gmail.com> wrote:

> On 2011 December 13 Tuesday, Amir Taaki wrote:
>
> > Maybe I wasn't clear enough in the document, but this is the intent with
> > the HTTPS proposal.
>
> I don't like the idea of a hard-coded mapping at all.  We shouldn't be
> making
> choices on behalf of server operators.  It's up to them how they arrange
> their
> domain names and paths.
>
> I also agree that DNS is not the technology to use.  DNS is a nightmare.
>
> > genjix@foo.org
> >
> > Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system
> > responds with a bitcoin address. Whether the system gives you a new
> > address from a pool of addresses, or contacts the merchant behind the
> > scenes is implementation defined.
> >
> > I'll clarify it later. This is the relevant line:
> >
> > string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" +
> > pszEncodedNick;
> >
> > Between HTTPS service and server service, I lean slightly towards HTTPS
> > (automatic encrypted connection, CAs + all benefits of DNS). But still
> > interested in arguments in favour of a server service (daemon answering
> > queries).
>
> Why bother with an encoding scheme at all?  If the address
>
>  genjix@foo.org
>
> always maps to
>
>  https://foo.org/bitcoin-alias/?handle=genjix
>
> Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" and
> "?handle=" and the original email-looking "genjix@foo.org".  Just use the
> URL.
> Then the author of the service can use whatever they want.
>
>  "Can I pay you 10 BTC?"
>  "Sure, send it to 'https://bitcoinalias.foo.org/genjix/'"
>
> While I might implement my alias server like this:
>
>  "Sure, send it to 'https://google.com/bitcoin/?andyparkins'"
>  "Sure, send it to 'https://parkins.co.uk/"
>
> ... or any other URL they want -- any of which suit might suit me and my
> webserver better than whatever mapping would otherwise be hard-coded.  The
> world is already very familiar with URLs so this is no more scary than the
> email address.  What's more, the email address form looks _too much_ like
> an
> email address, and will only lead to confusion ... "send it to
> genjix@foo.org"
> "so I use outlook express for that, right?"  "erm, no, you put it in your
> bitcoin client".
>
> The URL form could easily be made to detect a browser connecting rather
> than a
> bitcoin client (and this is an area that would benefit from a standards
> document -- define the headers and user agent triggers that an alias server
> expects) and give them better instructions.
>
> https can be specified as the default, so  "https://" can be optional when
> they're typing.  If, in the future, bitcoin gets a distributed peer-to-peer
> alias system, then a new URL type can be added easily
> "bcalias://andyparkins"
> might automatically find my node in the network and query it for an address
> (or whatever).
>
> All of the above is exactly why OpenID chose to use URLs for ID.
>
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins@gmail.com
>
>
> ------------------------------------------------------------------------------
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 5930 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Rick Wesson]

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
>

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[slush]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

OK, I'm ignoring your sarcastic style, I just wanted to support the URL
idea, which is KISS attitude, in the oposite of everything else proposed
here. I'm really affraid of over-engineering the aliases, which will make
it hard to implement in clients. Somebody noticed account implementation in
standard client - yes, it's good example of fail.

I still don't see any serious issue with the URL proposals. And sipa's idea
of posting back the transaction ID is also interesting, prividing yet
another flexibility in implementation and possible usage.

Btw, Rick, feel free to provide me some relevant RFCs which are solving
similar problems like BIP 15. And no, it's not sarcasm, I really want to
learn something new. Until now I just feel we're reinventing wheel or
raping some stuff which we should not touch at all (DNS).

slush

On Fri, Dec 16, 2011 at 4:52 PM, Rick Wesson
<rick@support-intelligence.com>wrote:

> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@centrum.cz> wrote:
> > I really like this proposal with standard URLs. All other proposals like
> DNS
> > mapping or email aliases converted to URLs with some weird logic looks
> > strange to me.
>
> wow, really. Maybe you could review some RFCs, there are thousands of
> examples where some really smart engineers chose the exact opposite
> path which you propose below.
>
> -rick
>
>

[-- Attachment #2: Type: text/html, Size: 1950 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 569 bytes --]

On 2011 December 16 Friday, Rick Wesson wrote:
> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@centrum.cz> wrote:
> > I really like this proposal with standard URLs. All other proposals like
> > DNS mapping or email aliases converted to URLs with some weird logic
> > looks strange to me.
> 
> wow, really. Maybe you could review some RFCs, there are thousands of
> examples where some really smart engineers chose the exact opposite
> path which you propose below.

Could you point me at an example?


Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Rick Wesson]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Amir Taaki]

[-- Attachment #1: Type: text/plain, Size: 3424 bytes --]

You have to be seriously joking to call the bitcoin protocol elegant. A message based system over TCP with constantly changing endians that needs to lookup its own IP address on several websites is not elegant. It is functioning, not elegant.

Also it is kind of dick to come guns blaring and start insulting slush who runs one of the biggest mining pools and is working on electrum, and sipa who develops the satoshi bitcoin.

Khalahan said:

> Namecoin is a peer-to-peer generic name/value datastore system

Namecoin has the same problem as DNS. From the document:

"The disadvantage of DNS TXT records is that updating a record takes 
time. This encourages people to not use new addresses per transaction 
which has certain security issues."


________________________________
 From: Rick Wesson <rick@support-intelligence.com>
To: Andy Parkins <andyparkins@gmail.com> 
Cc: bitcoin-development@lists.sourceforge.net 
Sent: Friday, December 16, 2011 5:41 PM
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
 
Its a negative example -- in that the IETF does not specify anything
in the PATH part of the URI. The scheme, sure, but not in the path,
there are many types of URI schemes ( start with RFC 2396 )

There is significant upside to having your own scheme and having apps
understand how to integrate with it. Frankly, having just one client
(I understand there are more) is an artifact that hinders acceptance
and participation. If you want to go the route of https then
specifying a scheme is your path forward

I still believe that it is experience that is leading this thread down
the rat-hole of CGI and HTTP requests. The stuff isn't magic, it is
just what you are used to. Review the bitcoin protocol, there is an
elegance there -- not found  in the https schemes proposed thus far.
CGI isn't a protocol, nor does it address usability/identity issues.

Providing a mapping from user@authority.tld addresses usability and
identity. I'd like to see an elegant transformation, specifically I
take to task anyone that advocates
https://authority/foo/user?tx=1zhd789632uilos as elegant.

-rick


On Fri, Dec 16, 2011 at 9:10 AM, Andy Parkins <andyparkins@gmail.com> wrote:
> On 2011 December 16 Friday, Rick Wesson wrote:
>> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@centrum.cz> wrote:
>> > I really like this proposal with standard URLs. All other proposals like
>> > DNS mapping or email aliases converted to URLs with some weird logic
>> > looks strange to me.
>>
>> wow, really. Maybe you could review some RFCs, there are thousands of
>> examples where some really smart engineers chose the exact opposite
>> path which you propose below.
>
> Could you point me at an example?
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins@gmail.com

------------------------------------------------------------------------------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 5069 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Gavin Andresen]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Rick Wesson]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Andy Parkins]

On Friday 16 Dec 2011 19:06:52 Gavin Andresen wrote:

> I think there is also a huge public relations benefit to using a
> standard like IIBAN instead of inventing our own. Having a Bitcoin
> Payment Routing Address (or whatever it ends up being called) that
> looks like the number issues by big financial institutions will give
> people the warm fuzzies.

I can see the PR advantages, but isn't mapping from one massively long, 
multi-character, human-opaque number (IBAN) to another (bitcoin address) a 
bit of a waste of time?

Surely the point of all this is to provide at least the possibility of a 
human-readable name for a bitcoin-address?

Isn't there a possibility that one day we might want to be able to say "send 
me those bitcoins you owe me to bitcoin.yahoo.co.uk/andyparkins"?  Or 
similar?



Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Andy Parkins]

On Friday 16 Dec 2011 17:41:25 Rick Wesson wrote:
> Its a negative example -- in that the IETF does not specify anything
> in the PATH part of the URI. The scheme, sure, but not in the path,
> there are many types of URI schemes ( start with RFC 2396 )

You seem to have jumped off the topic; you mentioned that there were 
thousands of RFCs that we should review over why we shouldn't use a URI; and 
you've pointed at an RFC that shows how a URI can be used.

While you're right that CGI and HTTP aren't magic; they are commonplace; and 
it's important when we want an infinitely expandable mapping system that 
people can use technology they are already familiar with. People already 
have web servers, people already understand URIs.  It's not "just what we 
are used to"; people who can cope with development of the bitcoin protocol 
aren't going to be worried about protocol complexity.  It is a concern about 
what the rest of the world will have to do to get a bitcoin alias.

> Providing a mapping from user@authority.tld addresses usability and

No it doesn't address usability at all, because it falls down on the first 
attempt: what if I want to supply a URI that allows my web service to link 
an invoice number to an issued bitcoin address?  You've forced every mapping 
service to be identical, and limited.

> identity. I'd like to see an elegant transformation, specifically I
> take to task anyone that advocates
> https://authority/foo/user?tx=1zhd789632uilos as elegant.

You've been unfair, the equivalent of your "user@authority.tld" is 
"https://authority.tld/user" or "https://user.authority.tld/" or 
"https://google.com/bitcoin/user" or any of an infinite number of other 
variations that _I_ as the mapper get to choose rather than whoever wrote 
the BIP; all of which are arguably no less "elegant" than that simple email.

There is no equivalent in the other direction though.  For someone who 
want's to supply the TX to their mapping server... where does it go in 
"user@authority.tld"?



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Rick Wesson]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Luke-Jr]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Khalahan]

Namecoin is a peer-to-peer generic name/value datastore system.
Don't forget it's not limited to .bit usage ! So, directly mapping
things to .bit url would not be the optimal way of using namecoin.

Namecoin is specificaly designed to map things to names in a fully
decentralized way. So, it's the perfect starting point to map names to
other things (a public bitcoin address, an url, etc)
You won't have all the advantages of namecoin when using other systems
like DNS and HTTP(S) as the first entry point.

What is namecoin ?

* proven technology :
- do not mix the namecoin technology and the dot-bit namespace with .bit
domains (dot-bit domains needs dot-bit compatible dns servers or proxies
+ namecoin and have a small visibility due to the nature of
top-to-bottom domain name system controlled by ICANN, namecoin needs
only namecoin to store data !)
- as proven and secure as bitcoin
- merged mining provides a secure network

* decentralized :
- a lot of nodes, and you can have your own node
- everybody can register his own name, by itself with the namecoin
software (bitcoin could even allow registration directly from it,
easily) or by using a name provider
- everybody can become a name provider (register for your friends and
resell names).

* no single point of failure :
- DNS and HTTPS have several limitations (Man in the Middle attacks, no
reliable authority of certifications, domain seizure, ...)

* designed for that :
- namecoin uses a system of namespaces to separate each usages :
http://dot-bit.org/Main_Page#Namespaces.
For example, the "personal namespace" draft
(http://dot-bit.org/Personal_Namespace) could be extended to support
mapping to a bitcoin address, or a dedicated namespace can be used if
prefered (the "bitcoin/" or "alias/" or "map/" prefixes for example).

* easily connectable to bitcoin
- they both use RPC and json to exchange informations, so connecting one
to the other is really easy
- bitcoin could even allow registration of names by sending an RPC
request to namecoin

* extensible and not limited :
- you are not forced to store a bitcoin address directly in namecoin,
you can also store an url or a domain name
- allows additional security : add a certificate fingerprint combined
with an https url (so, using DNS or HTTP(S) is not a major problem
anymore if the first point of entry is really secure and configurable
[and you use and self-signed certificate])
- really easy to update
- simple for simple cases
- possibility to use a nick, an email address or a domain as name
- other methods to get bitcoins addresses can be added later, protocol
is extensible


Examples of possible registered names in namecoin with the "personal
namespace" (with the "p/" prefix) :

* An individual person with well known public addresses :
"p/khal":
{
    "email": "khal@dot-bit.org",
    "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}

* Another individual person with well known public addresses :
"p/khal@dot-bit.org":
{
    "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}

* A merchant accepting payments in bitcoin, namecoin, paypal or
othercoin (to show you how the whole namespace could be used) :
"p/mymerchant.com":
{
    "bitcoin": {
        "url": "https://payto.mymerchant.com/bitcoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"
        "cert": "https://payto.mymerchant.com/certificate.pem",
    },
    "namecoin": {
        "url": "https://payto.mymerchant.com/namecoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"
    },
    "paypal": "xxxxxx@yyyyyyyyy.zzz",
    "othercoin": "oxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

* A merchant with a public address, an url to generate custom addresses
and a domain name (not sure if this case is really usefull, maybe as
fallback)
"p/mymerchant2":
{
    "bitcoin": {
        "url": "https://payto.mymerchant.com/bitcoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926",
        "dns": "_bitcoin.payto.mymerchant.com",
        "address": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    }
}


* How to use it in bitcoin ?

Several possibilities of address syntax :
- khal, khal@dot-bit.org, mymerchant.com, mymerchant2 : no syntax limit
- mymerchant2@bitcoin : will conflict with names already containing a @
- mymerchant2@namecoin : same
- namecoin:mymerchant2 : strange syntax, confusing with the "uri scheme"
- namecoin://mymerchant2 : same
- other ?


Here is how things would be processed when people put an address to pay
to in the bitcoin client :

* address : khal
-> RPC to namecoin for "p/khal"
-> json processing for "p/khal->bitcoin"
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T

* address : khal@dot-bit.org
-> RPC to namecoin for "p/khal@dot-bit.org"
-> json processing for "p/khal@dot-bit.org->bitcoin"
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T

* address : mymerchant.com
-> RPC to namecoin for "p/mymerchant.com"
-> json processing for "p/mymerchant.com->bitcoin"
-> json processing for "p/mymerchant.com->bitcoin->url" and
"p/mymerchant.com->bitcoin->fpr"
-> https request to "https://payto.mymerchant.com/bitcoin/"
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy

* address : mymerchant2
-> RPC to namecoin for "p/mymerchant2"
-> json processing for "p/mymerchant2->bitcoin"
-> json processing for "p/mymerchant2->bitcoin->url" and
"p/mymerchant2->bitcoin->fpr"
-> https request to "https://payto.mymerchant.com/bitcoin/"
-> result : error (website unavailable, page not found, timeout, etc)
-> json processing for "p/mymerchant2->bitcoin->dns"
-> dns request for "_bitcoin.payto.mymerchant.com"
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy

Le 13/12/2011 14:06, Gavin Andresen a écrit :
> I agree with Mike Hearn and Christian Decker-- paying to
> 'somebody@foo.com' should become, behind the scenes, a HTTPS query to
> https://foo.com/something. If you just want to (say) donate to
> eff.org, then paying to '@eff.org' aught to work nicely.
>
> And if namecoin ever takes off you'll pay to 'somebody@foo.bit'.
>
> It seems to me that if it was DNS-based, the address should be
> something like 'somebody.bitcoin.foo.com'. But I think it is unlikely
> people will setup and run a custom DNS server just to support bitcoin
> payments.
>


-- 
Best Regards,
Khalahan
http://dot-bit.org/

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Gregory Maxwell]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Walter Stanish]

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.

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Jorge Timón]

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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Gavin Andresen]

RE: IIBAN numbers:

Nifty!  Thanks for the pointers, I think we should avoid reinventing
wheels whenever possible.

When composing my last response in this thread I wrote, and then erased:

"There doesn't have to be one solution: I'd like to see some
experimentation, with clients supporting different schemes for bitcoin
address aliases, and maybe supporting plugins to extend the schemes
supported (a plugin would take a string, do some
behind-the-scenes-magic, and return a bitcoin address or public key)."

Defining Bitcoin as an IIBAN "institution", with 36^6 "accounts",
seems like a forward-thinking idea, although I'm not clear on exactly
how those 2.2billion "accounts" would get allocated and mapped into
bitcoin addresses.

I imagine some central organization that maps IIBAN account numbers to
domain names... and then clients (or plugins in the clients) query
that trusted central organization and then the account holder's domain
to get a (possibly unique) public key or bitcoin address.

As long as IIBANs are not the ONLY way of aliasing bitcoin addresses
to more-human-friendly strings I think that would be a fine way to do
it.

-- 
--
Gavin Andresen

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Walter Stanish]

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

Re: [Bitcoin-development] [BIP 15] Aliases

[Stefan Thomas]

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

Re: [Bitcoin-development] [BIP 15] Aliases

[Matt Corallo]

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

Re: [Bitcoin-development] [BIP 15] Aliases

[Will]

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2760 bytes --]

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Cameron Garnham]

[-- Attachment #1: Type: text/plain, Size: 2153 bytes --]

Namecoin makes sense; as we can use the same private keys to spend the
namecoin as spending the bitcoins.

Namecoin happens to be the only secure guaranteed global unique human
rememberable string system that exists.

I suggest that sending bitcoins to a namecoin name is the way to go...
It makes even more sense since namecoin started merged mining.

On 13 December 2011 08:03, Cameron Garnham <da2ce7@gmail.com> wrote:

>
> Sent from my Windows Phone
> De: Amir Taaki
> Enviado: 13/12/2011 0:43
> Para: bitcoin-development@lists.sourceforge.net
> Asunto: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
> > I'm confused about the problem we're trying to solve.
>
> I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on
> the wall a picture of their QR code and a bitcoin address. I don't own
> a mobile phone so the QR code is
> useless. Then I remembered FirstBits, went to my terminal and typed
> 1brmlab. I got their bitcoin address from the website and copied that,
> then opened my terminal and pasted that in to send 1 BTC.
>
> And
> these proposals for Namecoin, would make bitcoin implementations
> dependent on unproven technology. HTTPS/DNSSEC have been around a long
> time and are responsible for many mission critical systems. There's a
> lot of momentum behind those projects. Namecoin by contrast, could die
> tomorrow. And it isn't a big deal that they're centralised. This is a
> convenience for end users and does not affect the core system much.
>
> tl;dr: usability
>
>
>
> ------------------------------------------------------------------------------
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Cameron Garnham:
email: da2ce7@gmail.com
website: http://da2ce7.blogspot.com
telephone: +61405227831

[-- Attachment #2: Type: text/html, Size: 3227 bytes --]