From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qn7ob-0003QT-1K for bitcoin-development@lists.sourceforge.net; Sat, 30 Jul 2011 11:34:45 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.47 as permitted sender) client-ip=209.85.212.47; envelope-from=mh.in.england@gmail.com; helo=mail-vw0-f47.google.com; Received: from mail-vw0-f47.google.com ([209.85.212.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Qn7oa-0007Zt-72 for bitcoin-development@lists.sourceforge.net; Sat, 30 Jul 2011 11:34:45 +0000 Received: by vws2 with SMTP id 2so5078666vws.34 for ; Sat, 30 Jul 2011 04:34:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.110 with SMTP id db14mr2209450vdb.458.1312025678744; Sat, 30 Jul 2011 04:34:38 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.52.169.9 with HTTP; Sat, 30 Jul 2011 04:34:38 -0700 (PDT) In-Reply-To: References: Date: Sat, 30 Jul 2011 12:34:38 +0100 X-Google-Sender-Auth: JgUe20ZB2ODz0gsj0FqVomSdltg Message-ID: From: Mike Hearn To: Rick Wesson Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.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 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: 1Qn7oa-0007Zt-72 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] bitcoin DNS addresses 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: Sat, 30 Jul 2011 11:34:45 -0000 This was already discussed on the forums, but clear use cases would be helpful. I originally thought this feature seemed like a no-brainer, but randomly emailing money to people out of the blue is not a very common operation. You almost always have contact with them first, if only to say "hey, I'm going to send you some money", but more commonly to figure out how much you're going to pay and what for. Once you have communication, providing an address in-band isn't very hard, and it has the advantage of always working. Doing anything with DNS or magic HTTPS endpoints means that 90% of the time, your feature *will not work* (eg it won't work for any gmail/yahoo/hotmail account) and users will rapidly learn not to bother trying as they have no way of knowing if any given address will work or not. It's not smart UI design to provide users with a feature that will normally never work, and for which they can't even guess at whether it will. What would be better to see is a standardized (probably HTTPS based) protocol in which a Bitcoin URI could contain a domain name, and then your client would challenge the domain to sign a nonce with the key corresponding to the address (or raw pubkey). This means in your client the payment can be rendered and recorded as a payment to "foobar.com", which is much more helpful. That protocol could then be extended to support "user@foobar.com" type challenges so when a bitcoin: link is provided, the server is challenged to prove ownership by that user of that public key. It means the details are hidden and when the feature is present, the UI gets silently better, but there's never any demand on any users to do anything different. The "copy Bitcoin address" button in the UI can provide the clipboard with both text/plain and text/html content so the right one is picked depending on context.