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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RcIsZ-0006Mz-6L for bitcoin-development@lists.sourceforge.net; Sun, 18 Dec 2011 15:42:23 +0000 X-ACL-Warn: Received: from rhcavuit01.kulnet.kuleuven.be ([134.58.240.129] helo=cavuit01.kulnet.kuleuven.be) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1RcIsU-00088W-QK for bitcoin-development@lists.sourceforge.net; Sun, 18 Dec 2011 15:42:23 +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: F41F5138044.A5779 X-KULeuven-Information: Katholieke Universiteit Leuven Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be [134.58.240.75]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id F41F5138044 for ; Sun, 18 Dec 2011 16:42:06 +0100 (CET) Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be [193.190.253.235]) by smtps02.kuleuven.be (Postfix) with ESMTP id D7C19F3862 for ; Sun, 18 Dec 2011 16:42:06 +0100 (CET) Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182]) by smtp.ulyssis.org (Postfix) with ESMTP id DB29A10052 for ; Sun, 18 Dec 2011 16:42:06 +0100 (CET) Received: by wop.ulyssis.org (Postfix, from userid 615) id 96BB287C1AA; Sun, 18 Dec 2011 16:42:06 +0100 (CET) Date: Sun, 18 Dec 2011 16:42:06 +0100 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Pieter Wuille To: bitcoin-development@lists.sourceforge.net Message-ID: <20111218154205.GA5304@ulyssis.org> References: <201112170132.26201.luke@dashjr.org> <1324138546.29801.3.camel@BMThinkPad.lan.bluematt.me> <4EECDD5F.8030402@parhelic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Content-Transfer-Encoding: quoted-printable 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: 1RcIsU-00088W-QK Subject: Re: [Bitcoin-development] Pubkey 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: Sun, 18 Dec 2011 15:42:23 -0000 On Sun, Dec 18, 2011 at 01:15:26PM +0100, Jorge Tim=F3n wrote: > But anyway, reading some comments I feel I'm missing something about > this proposal. How can you save space by putting the whole public key > instead of just the address (a hash of the public key) with each > output? > Is this what it's being proposed? Yes. The reason is that currently a send-to-address puts the address in t= he output script, while redeeming requires the full pubkey plus the signatur= e to be placed in the input script. Overall, this requires more space than = a send-to-pubkey, where the output contains the pubkey, and the input the signature. There are several possible improvements however, and they may not all hav= e been explained in this thread. To summarize: * compressed public keys (33 byte pubkeys instead of 65 bytes) * compact signatures (66 bytes instead of 72, including hash type byte) * pubkey recovery (allows the public key to be derived from a compact sig= nature) The first is very easy to implement (see pull #649). Compact signatures=20 and pubkey recovery require a change to the scripting language (though ar= e already implemented, as they are used for message signing). These result in several combinations that could be proposed: 1) send-to-pubkeys-hash - currently the default addres type 2) send-to-recovered-pubkeys-hash-with-compact-signature-inside-op_eval - extend the scripting language inside OP_EVAL, as described in https://gist.github.com/1262449 - use compact signatures - use key recovery, and never put a pubkey in the blockchain data 3) send-to-pubkey - traditional transaction type 4) send-to-compressed-pubkey - what Luke proposes as new address type 5) send-to-compressed-pubkeys-hash - what pull #649 would bring Gregory Maxwell made a small table to compare these options: http://people.xiph.org/~greg/addr.compare.html If you don't consider pruning, everything is better than send-to-pubkeys-= hash as we have now. Both using pubkeys instead of hashes, using compressed pu= bkeys instead of full ones improve the situation independently, and using key recovery is even better. If you do consider pruning, the advantages are smaller, but it is far fro= m clear to me how pruning will be implemented in the future (as a pruning node cannot function as a NODE_NETWORK service anymore). --=20 Pieter