From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U4BUj-00089k-1D for bitcoin-development@lists.sourceforge.net; Sat, 09 Feb 2013 14:33:33 +0000 Received: from mout.web.de ([212.227.17.12]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1U4BUi-0001WS-2L for bitcoin-development@lists.sourceforge.net; Sat, 09 Feb 2013 14:33:32 +0000 Received: from crunch ([93.129.20.196]) by smtp.web.de (mrweb102) with ESMTPA (Nemesis) id 0Le4Po-1Uj1Xm0dH2-00pkyu; Sat, 09 Feb 2013 15:33:26 +0100 Date: Sat, 9 Feb 2013 15:33:25 +0100 From: Timo Hanke To: Peter Todd Message-ID: <20130209143325.GA3998@crunch> References: <20130208100354.GA26627@crunch> <20130208110108.GA6893@savin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130208110108.GA6893@savin> User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V02:K0:h/oVdBjwT6Htx5m9t4r6A6K9AK5t0dQ4e4TMECyh6sH FTNmgMGOGGKF7jLO5kM+7oho4mOyBfEi2cmZ9jTPtbcFWk4xcC 1Yn2Z1V3WvGM/PI1bRKHTLrTykP4HseJNI6FX94hPVj98QAOiM fKcc1J+xziV13WOJLCcbzQlxnUKbqvQoNWI+z9fHPZZdayQvLq rAA6qUp1/FPmIn0zrww/A== X-Spam-Score: 0.0 (/) 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 (timo.hanke[at]web.de) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.17.12 listed in list.dnswl.org] -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1U4BUi-0001WS-2L Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Blockchain as root CA for payment protocol X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: timo.hanke@web.de List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 14:33:33 -0000 On Fri, Feb 08, 2013 at 06:01:08AM -0500, Peter Todd wrote: > On Fri, Feb 08, 2013 at 11:03:54AM +0100, Timo Hanke wrote: > > First, we have drafted a quite general specification for bitcoin certificates (protobuf messages) that allow for a variety of payment protocols (e.g. static as well as customer-side-generated payment addresses). > > This part has surely been done elsewhere as well and is orthogonal to the goal of this project. > > What is new here is the signatures _under_ the certificates. > > > > We have patched the bitcoind to handle certificates, submit signatures to the blockchain, verify certificates against the blockchain, pay directly to certificates (with various payment methods), revoke certificates. > > Signatures in the blockchain are stored entirely in the UTXO set (i.e. the unspend, unprunable outputs). > > This seems to make signature lookup and verification reasonably fast: > > it took us 10s in the mainnet test we performed (lookup is instant on the testnet, of course). > > Why don't you use namecoin or another alt-chain for this? Because namcoin tries to solve a different problem, DNS, whereas I want to establish an identity for a payment protocol. Your incoming payments will land on addresses that are derived (regardless which way) from this idenity. This makes your identity as important (securitywise) as anything else involved in the bitcoin protocol. Therefore I would not want to have payment-ids rely on anything _less_ than bitcoin's own blockchain. In particular not on PKI with centralized root CAs. But also not on namecoin or any other (weaker) alt-chains. You can argue that alt-chains _can_ be as strong as bitcoin, but they don't _have to_ be. There is no guarantee how many people will cross-mine. The alt-chain could even disappear at some point. If at some point your alt-chain is no longer being worked on, then how do you prove that some old bitcoin transaction went to an address for which there was a valid id/certificate at the time of sending? If the certificate is based inside bitcoin's blockchain then you will have a proof for the correct destinations of all your old transactions as long as bitcoin exists. Besides all this, as you mentioned namecoin specifically, that is overkill if you just want to link two hashes together. A single 2-of-2 multisig output would suffice for that. > The UTXO set is the most expensive part of the blockchain because it > must be stored in memory with fast access times. It's good that you have > designed the system so that the addresses can be revoked, removing them > from the UTXO set, but it still will encourage the exact same type of > ugly squatting behavior we've already seen with first-bits, and again > it'll have a significant cost to the network going forward for purposes > that do not need to be done on the block chain. You are probably right that storing this in the _spent outputs_ would be better. There doesn't seem to be any type of client out there that would benefit from having to search UTXO only. Timo