From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RaQ1S-0006h9-Es for bitcoin-development@lists.sourceforge.net; Tue, 13 Dec 2011 10:55:46 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.41 as permitted sender) client-ip=74.125.82.41; envelope-from=mh.in.england@gmail.com; helo=mail-ww0-f41.google.com; Received: from mail-ww0-f41.google.com ([74.125.82.41]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RaQ1M-0005y3-QL for bitcoin-development@lists.sourceforge.net; Tue, 13 Dec 2011 10:55:46 +0000 Received: by wgbdt12 with SMTP id dt12so10362751wgb.4 for ; Tue, 13 Dec 2011 02:55:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.92.68 with SMTP id ck4mr11853005wib.27.1323773734674; Tue, 13 Dec 2011 02:55:34 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.216.8.7 with HTTP; Tue, 13 Dec 2011 02:55:34 -0800 (PST) In-Reply-To: <1323736946.58149.YahooMailNeo@web121001.mail.ne1.yahoo.com> References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com> <201112121841.39864.luke@dashjr.org> <1323736946.58149.YahooMailNeo@web121001.mail.ne1.yahoo.com> Date: Tue, 13 Dec 2011 11:55:34 +0100 X-Google-Sender-Auth: bv5Zjqw10ApOthe8WBetlYK2QIk Message-ID: From: Mike Hearn To: Amir Taaki Content-Type: multipart/alternative; boundary=f46d043c806c37dfc204b3f7170d X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1RaQ1M-0005y3-QL Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 10:55:46 -0000 --f46d043c806c37dfc204b3f7170d Content-Type: text/plain; charset=UTF-8 > > 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. --f46d043c806c37dfc204b3f7170d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was in brmlab a= nd wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of t= heir QR code and a bitcoin address. I don't own a mobile phone so the Q= R code is
useless.

Fixed addresses like that are a te= mporary thing during Bitcoins maturation period. They lead to merchants exp= osing 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 w= ould 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 ever= y Facebook user. In terms of ease of implementation it is ordered HTTPS/HTT= P then DNS trailing by a large margin. Big sites, even small sites, typical= ly 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 privac= y reasons as given above. No banking system worth its salt would let everyo= ne look up other peoples income.

The simplest appr= oach would be to request a full public key with an HTTPS request like

=C2=A0 =C2=A0foo@domain -> https://do= main/_bitcoin/getnewkey?user=3Dfoo&label=3DPayment%20from%20Bob

If you then want to turn the resulting public key into an address befo= re 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.
--f46d043c806c37dfc204b3f7170d--