path: root/e8/63a09cec383daa9d9c60af7f0d078ed607456a

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <rick.wesson@iidf.org>) id 1RbfuV-0006G3-Na
	for bitcoin-development@lists.sourceforge.net;
	Fri, 16 Dec 2011 22:05:47 +0000
X-ACL-Warn: 
Received: from mail-vx0-f175.google.com ([209.85.220.175])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1RbfuU-0008T6-T7
	for bitcoin-development@lists.sourceforge.net;
	Fri, 16 Dec 2011 22:05:47 +0000
Received: by vcbf1 with SMTP id f1so2620663vcb.34
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 16 Dec 2011 14:05:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.153.134 with SMTP id k6mr5065532vcw.23.1324073141188; Fri,
	16 Dec 2011 14:05:41 -0800 (PST)
Received: by 10.52.37.80 with HTTP; Fri, 16 Dec 2011 14:05:41 -0800 (PST)
In-Reply-To: <4EEBBD84.6020907@dot-bit.org>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
	<1323979147.27319.140661012141129@webmail.messagingengine.com>
	<4EEB7E98.8030006@dot-bit.org>
	<CAJna-HjXp4XEHnbmX0HKsMDmnxoWQQMmqujN+D9nLV0Zz_omcg@mail.gmail.com>
	<4EEBBD84.6020907@dot-bit.org>
Date: Fri, 16 Dec 2011 14:05:41 -0800
Message-ID: <CAJ1JLtuhwdBC8jJsmS3pTUixdLwh0haB-Gq_CdEmEWYN0-z+QA@mail.gmail.com>
From: Rick Wesson <rick@support-intelligence.com>
To: Khalahan <khal@dot-bit.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RbfuU-0008T6-T7
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2011 22:05:47 -0000

On Fri, Dec 16, 2011 at 1:52 PM, Khalahan <khal@dot-bit.org> wrote:
> The number of proposals is not infinite, here are their problems :
>
> - FirstBits : centralized
> - DNS TXT Records : DNSSEC is required to have a minimum of security, lim=
its
> usage to engineers, limits usage to some domain names (i won't be able to
> use a gmail address for example, because i don't control the gmail.com
> domain)

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

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

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

DNS TXT are not the only way forward, also registry/registrars can facilita=
te.

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

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

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

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

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

wash, rinse,  ...

-rick

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