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 <sipa@ulyssis.org>) 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 <bitcoin-development@lists.sourceforge.net>;
	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 <bitcoin-development@lists.sourceforge.net>;
	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 <bitcoin-development@lists.sourceforge.net>;
	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 <pieter.wuille@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20111218154205.GA5304@ulyssis.org>
References: <201112170132.26201.luke@dashjr.org>
	<CAGQP0AFg7dMK4Rzm9M1Ur-jeQmAp85nKbE_Ry5sXr+Pw=e3EQg@mail.gmail.com>
	<1324138546.29801.3.camel@BMThinkPad.lan.bluematt.me>
	<4EECDD5F.8030402@parhelic.com>
	<CAGQP0AE-OkJroyAN5jga_a-s8i_SSub9uSgTQBZDrQQfzC=bSg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <CAGQP0AE-OkJroyAN5jga_a-s8i_SSub9uSgTQBZDrQQfzC=bSg@mail.gmail.com>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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