From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RbTGf-0007qa-PR for bitcoin-development@lists.sourceforge.net; Fri, 16 Dec 2011 08:35:49 +0000 X-ACL-Warn: Received: from rhcavuit02.kulnet.kuleuven.be ([134.58.240.130] helo=cavuit02.kulnet.kuleuven.be) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1RbTGd-0005Z4-Du for bitcoin-development@lists.sourceforge.net; Fri, 16 Dec 2011 08:35:49 +0000 X-KULeuven-Envelope-From: sipa@ulyssis.org X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5, autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00, FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20) X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 138A2128029.A87CF X-KULeuven-Information: Katholieke Universiteit Leuven Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be [134.58.240.74]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 138A2128029 for ; Fri, 16 Dec 2011 09:35:40 +0100 (CET) Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be [193.190.253.235]) by smtps01.kuleuven.be (Postfix) with ESMTP id BE25531E703 for ; Fri, 16 Dec 2011 09:35:39 +0100 (CET) Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182]) by smtp.ulyssis.org (Postfix) with ESMTP id D6BF610052 for ; Fri, 16 Dec 2011 10:36:03 +0100 (CET) Received: by wop.ulyssis.org (Postfix, from userid 615) id DB71B87C1AB; Fri, 16 Dec 2011 09:35:38 +0100 (CET) Date: Fri, 16 Dec 2011 09:35:38 +0100 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Pieter Wuille To: bitcoin-development@lists.sourceforge.net Message-ID: <20111216083536.GA20470@ulyssis.org> References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com> X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1RbTGd-0005Z4-Du Subject: Re: [Bitcoin-development] [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: Fri, 16 Dec 2011 08:35:49 -0000 On Mon, Dec 12, 2011 at 02:21:09PM -0800, Amir Taaki wrote: > I wrote this pre-draft: > > > https://en.bitcoin.it/wiki/BIP_0015 > > It's merely a starter for discussions. Interesting discussion so far, with many nice ideas. I'll try to give my opinion and comment on some in batch here. First of all, I'm a big proponent of moving away from using base58 strings as addresses. They are not flexible and not human-friendly. I did an own proposal to improve the situation some time ago, see https://gist.github.com/1237788 There was little reaction, and maybe the reason is we shouldn't try to solve/fix everything at once. a) IP transactions-like system with DNS resolution Not only does this give you nice identifiers, but it also moves the responsibility of getting the transaction accepted by the network from the sender to the receiver - the one who actually cares about getting his money. The authentication problem that was present in the original IP transactions system can either be mitigated by trusting the existing SSL public-key intrastructure (which not everyone may like) or (as Satoshi suggested) adding bitcoin address-based authentication on top (separate from the address used in the transaction itself). So you get an identifier like $, and the communication to would be authenticated using . This is obviously not useful as human-typable alias, but is no problem for clickable URLs on websites that want to provide the additional security. I'm not sure about using the bitcoin p2p protocol here - i think there are easier (or at least more widely deployed) protocols like HTTP. So maybe ... b) HTTPS Web Service we can just use an HTTPS web service, that provides the bitcoin address to be used in the transaction to a client that queries a URL. This immediately makes the identifier double as a clickable URL, and a merchant could add metadata to the URL to make the transaction easily trackable. As for the possibility for spoofing: relying on DNSSEC is currently difficult i believe (though i'm not entirely up-to-date about its deployment). Again, alternatives are the SSL PKI, or bitcoin address-based authentication (basically doing SSL but using bitcoin pubkeys to authenticate) c) user@hostname-like identifiers These look very good, and conveniently match the e-mail system's identifiers. However, I believe they are only useful for one purpose: user-to-user payments. For anything somewhat more business-y you probably want to use a clickable URL, and hide all address information entirely from the user. Still, for user-to-user payments they are nice. I'm not convinced about the hardcoding of the "https://" and "/bitcoin-alias/?handle=" parts, though. These seem very arbitrarily chosen to me, but if you consider an HTTPS-based variant of a bitcoin ip-transactions-like system, the proposed "account" parameter to checkorder would probably become a CGI parameter anyway... d) DNS TXT lookups I'm not entirely against this, but only allowing a fixed bitcoin address to be returned would far too strongly encourage the use of fixed addresses in transactions. If anything, it should be an identifier for one of the other proposals (which do allow interaction, or at least creation of a fresh bitcoin address) that is returned. To conclude: my suggestion would be to use URLs as address identifiers, optionally suffixed with a bitcoin address for authentication. This means my "address" would be either "sipa.be/pw.btc" or "sipa.be/pw.btc$14TYdpodQQDKVgvUUcpaMzjJwhQ4KYsipa" (where "https://") is an implicit default. Initiating a payment to either of these would result in a GET of https://sipa.be/pw.btc. When a transaction is constructed, it is POSTed back to that URL. If we can agree on reasonable hardcoded mapping, pw@sipa.be could just be a shorthand for either of these (though vulnerable to proofing...). -- Pieter