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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U3lhs-0008PD-Io for bitcoin-development@lists.sourceforge.net; Fri, 08 Feb 2013 11:01:24 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.109 as permitted sender) client-ip=62.13.148.109; envelope-from=pete@petertodd.org; helo=outmail148109.authsmtp.co.uk; Received: from outmail148109.authsmtp.co.uk ([62.13.148.109]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1U3lhp-0004vZ-VD for bitcoin-development@lists.sourceforge.net; Fri, 08 Feb 2013 11:01:24 +0000 Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233]) by punt12.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r18B1F6T089615; Fri, 8 Feb 2013 11:01:15 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r18B1537031578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 11:01:08 GMT Date: Fri, 8 Feb 2013 06:01:08 -0500 From: Peter Todd To: Timo Hanke Message-ID: <20130208110108.GA6893@savin> References: <20130208100354.GA26627@crunch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <20130208100354.GA26627@crunch> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: d7816b0a-71de-11e2-a49c-0025907707a1 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgoUHlAWAgsB AmUbWlVeUFx7WWs7 bAxPbAVDY01GQQRq WVdMSlVNFUsqABRz BxsdVRlxdgBBcDBx ZkViVj4PW0x7cxR9 E1NTFDlTeGZhPWIC AURRJB5UcAFPdx9C bVB4BXJDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4hGjk3 RBsCFDQpVUQeDz80 KABuAXdUEkELel07 IF4sX05QKwUVFgpV GEUl X-Authentic-SMTP: 61633532353630.1021:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1U3lhp-0004vZ-VD 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 11:01:24 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2013 at 11:03:54AM +0100, Timo Hanke wrote: > First, we have drafted a quite general specification for bitcoin certific= ates (protobuf messages) that allow for a variety of payment protocols (e.g= =2E 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. >=20 > We have patched the bitcoind to handle certificates, submit signatures to= the blockchain, verify certificates against the blockchain, pay directly t= o certificates (with various payment methods), revoke certificates. > Signatures in the blockchain are stored entirely in the UTXO set (i.e. th= e unspend, unprunable outputs).=20 > This seems to make signature lookup and verification reasonably fast:=20 > 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? 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 =66rom 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. In https://github.com/bcpki/bitcoin/wiki/Technical you say that you have a minimum amount required for an outpoint to be valid, set at 0.05BTC. That's a nice touch, and sort of works because this is a consensus protocol, but if the exchange rate climbs significantly there will be a lot of pressure to reduce that value. (setting minimum value by chain height) What will happen then is there will be a mad rush to squat on previously unaffordable domains, further disrupting Bitcoin's purpose as a financial network. In addition you'll also have a second problem: squatting of subsequent transactions, particularly for valuable bcvalues. Basically if someone already has "microsoft" insert bcvalues after their tx in case they accidentally spend it. Of course, this will be done by people buying bcvalues as well. Again, all this further clogs up the UTXO set. I also can't figure out why you say signature lookup and verification takes 10s - this should be an O(1) operation if you maintain a mapping of candidate pubkeys to linked-lists of sorted applicable transactions. Finally, why is this implemented within the reference client? Use the raw transaction API and make up your own database. If you want, create a RPC command that allows you to query the UTXO set directly; this would be a useful feature to have. This patch will never be accepted to the reference client, so you'll just wind up having to maintain a fork. Even for a prototype this approach is ill-advised - prototypes have a bad way of turning into production code. In short, please don't do this. --=20 'peter'[:-1]@petertodd.org --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRFNr0AAoJEH+rEUJn5PoE2x4IAIllbK1xPRtnVz0im0I23A/d MJfT+df3PTUGvLq3gB9DFvYb+qowsxGJlkIf5+OTI2LW7TuTb0EqOcyJH8xlQNhO tKwncqMh3Ow+sglTHfE2qwhJD2T/WkG5h1Gg7NewPB1IhZMwNUxPtI/My/O8iLH0 cSb0HZ0SjS0yWb+LLeb5nP+e/eoJuJzkrqI7y1U8IFnc1vkp7xN1ZeSDq/9GpVoC ypO8troHNV/xTMQxEn0zvBf2ItaVE9GTR4k4fiETBJUPWncwdWRTeFIgqih6duMT eSBN5ok3GxLLinbF+dRPJA2XFVkKHUHeWt+qiBEzLL5z/y5LervQjaCNAeX3054= =B9I6 -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c--