From: Rick Wesson <rick@support-intelligence•com>
To: Khalahan <khal@dot-bit•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Date: Fri, 16 Dec 2011 14:05:41 -0800 [thread overview]
Message-ID: <CAJ1JLtuhwdBC8jJsmS3pTUixdLwh0haB-Gq_CdEmEWYN0-z+QA@mail.gmail.com> (raw)
In-Reply-To: <4EEBBD84.6020907@dot-bit.org>
On Fri, Dec 16, 2011 at 1:52 PM, Khalahan <khal@dot-bit•org> wrote:
> The number of proposals is not infinite, here are their problems :
>
> - FirstBits : centralized
> - DNS TXT Records : DNSSEC is required to have a minimum of security, limits
> usage to engineers, limits usage to some domain names (i won't be able to
> use a gmail address for example, because i don't control the gmail.com
> domain)
The same goes for http(s) one would not be able to use
http://google.com/user unless google offers the services.
ALSO look at DANE for getting around the certificate requirement for https
> - Server Service (DNS + a daemon) : Same as DNS TXT records
DNS TXT are not the only way forward, also registry/registrars can facilitate.
> - HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be able to
> check the full certificate chain and access a list of up-to-date certificate
> authorities (installed on the OS or provided with bitcoin). And don't forget
> the CA model is not 100% reliable (several CA hacked this year + possible
> government control...).
This most likely relies on a paid, valid certificate (that expires),
no self signed certs. I admit that running a secured https server with
a valid CA signed cet is as simple/hard as running a DNSSEC authority
zone.
using a x.509 certificate to secure a bitcoin transaction removes some
of the anonymity of the transaction by allowing the lookup to identify
the certification, ca, crl etc thus connecting a transaction/bitcoin
address to the cert and to its issuing authority. No matter the
frequency of the destination bitcoin address changing.
IMNSHO, leveraging CAs to secure http to provide a lookup translation
to a bitcoin address will only erode anonymity. While DNS is connected
to whois there are provision for hiding behind a proxy where to the
best of my knowledge there are no such provisions offered by CA's
issuing x.509 certificates.
Should self signed cers be "allowed" or encouraged only decreases
security. Clearly DANE would be the only way to mitigate this
situation but then you are back to relying on DNSSEC to bind the x.509
cert.
wash, rinse, ...
-rick
> - IP Transactions : This proposal seeks to enable DNS lookups for IP
> transactions => same as above
>
> I know that providing a namecoin daemon with bitcoin is not the lighter
> solution, but, if a better one existed i guess it would have already been
> integrated into bitcoin... (see in what state is my first attempt with the
> HTTPS proposal : Send payments to emails, urls and domains in GUI - khalahan
> opened this pull request April 20, 2011)
>
> So, what's next ?
>
> Le 16/12/2011 20:54, slush a écrit :
>
> Khalahan, honestly, using namecoin for aliases is (for me) clean example of
> over-engineering. I mean - it will definitely work if implemented properly.
> I played with a namecoin a bit (as my pool was the first 'big' pool
> supporting merged mining), but I think there's really long way to provide
> such alias system in namecoin and *cleanly integrate it with bitcoin*. Don't
> forget that people who want to do lookup need to maintain also namecoin
> blockchain with their bitcoin client. It goes against my instinct of keeping
> stuff easy.
>
> For example, yesterday I implemented HTTPS lookup for addresses into my fork
> of Electrum client. I did it in 15 minutes, it works as expected, it does
> the job and the implementation is really transparent, becuase implementation
> is 20 lines of code. There's no magic transformation, no forced "?handle="
> parameters or whatever. And I don't care if somebody provide URL
> https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True
>
> And everybody can do the same in their clients, in their merchant solutions,
> websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS,
> Namecoin, IIBAN, email aliases to other programmers...
>
> Those IIBAN - well, why not. At least I see the potential in PR. So far I
> understand it as some teoretic concept which is not supported by anything
> else right now. Give it few years until it matures and then add IIBAN alias
> to Bitcoin client too.
>
> Maybe I'm repeating myself already, but the way to go is to make aliases as
> easy as possible, so everybody can implement it in their own solution and
> thus practially remove the need of using standard bitcoin addresses for
> normal users. Using some superior technology, which is hard to implement or
> even understand won't solve the situation, because it will ends up with some
> reference implementation in standard client only and nobody else will use
> it.
>
> slush
>
>
> --
> Best Regards,
> Khalahan
> http://dot-bit.org/
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
next prev parent reply other threads:[~2011-12-16 22:05 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-12 22:21 Amir Taaki
2011-12-12 22:25 ` Amir Taaki
2011-12-12 22:32 ` Luke-Jr
2011-12-13 4:38 ` theymos
2011-12-13 7:41 ` Jorge Timón
2011-12-15 19:59 ` theymos
2011-12-15 23:56 ` Amir Taaki
2011-12-16 2:37 ` Kyle Henderson
2011-12-16 4:32 ` Walter Stanish
2011-12-16 2:48 ` Matt Corallo
2011-12-16 17:23 ` Khalahan
2011-12-16 19:54 ` slush
2011-12-16 20:10 ` Amir Taaki
2011-12-16 20:14 ` Harald Schilly
2011-12-16 21:52 ` Khalahan
2011-12-16 22:05 ` Rick Wesson [this message]
2011-12-18 21:05 ` Jorge Timón
2011-12-18 21:18 ` Jordan Mack
2011-12-18 21:44 ` Luke-Jr
2011-12-18 23:58 ` slush
2011-12-19 1:13 ` Luke-Jr
2011-12-19 1:14 ` Pieter Wuille
2011-12-19 1:43 ` Luke-Jr
2011-12-19 1:44 ` slush
2011-12-19 7:56 ` Jorge Timón
2011-12-19 11:44 ` Andy Parkins
2011-12-19 14:46 ` solar
2011-12-19 15:35 ` Rick Wesson
2011-12-19 16:35 ` Luke-Jr
2011-12-19 17:13 ` solar
2011-12-19 16:30 ` Luke-Jr
2011-12-19 17:04 ` Jordan Mack
2011-12-19 17:09 ` slush
2011-12-19 18:13 ` Jordan Mack
2011-12-19 18:17 ` slush
2011-12-19 18:50 ` Jorge Timón
2011-12-19 20:03 ` Jordan Mack
2011-12-19 19:22 ` Jordan Mack
2011-12-19 18:15 ` Luke-Jr
2011-12-19 18:52 ` Jordan Mack
2011-12-19 19:16 ` Luke-Jr
2011-12-19 20:03 ` Jordan Mack
2011-12-16 8:35 ` Pieter Wuille
2011-12-16 16:03 ` Rick Wesson
2011-12-16 16:17 ` Pieter Wuille
2011-12-16 16:21 ` Rick Wesson
2011-12-16 17:21 ` Andy Parkins
2011-12-12 23:16 Zell Faze
2011-12-12 23:37 ` Jorge Timón
2011-12-12 23:41 ` Luke-Jr
2011-12-13 2:39 ` Stefan Thomas
2011-12-12 23:52 ` Matt Corallo
2011-12-12 23:37 ` Will
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJ1JLtuhwdBC8jJsmS3pTUixdLwh0haB-Gq_CdEmEWYN0-z+QA@mail.gmail.com \
--to=rick@support-intelligence$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=khal@dot-bit$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox