From: "Luke-Jr" <luke@dashjr.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Date: Sat, 17 Dec 2011 19:28:12 -0500
User-Agent: KMail/1.13.7 (Linux/3.1.4-gentoo; KDE/4.7.3; x86_64; ; )
References: <201112170132.26201.luke@dashjr.org>
	<201112171652.22148.luke@dashjr.org>
	<CAAS2fgSjbkS03x+e21pRvA9jswy7OdKP4Qe3uBLe_kTbBdv77g@mail.gmail.com>
In-Reply-To: <CAAS2fgSjbkS03x+e21pRvA9jswy7OdKP4Qe3uBLe_kTbBdv77g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201112171928.13504.luke@dashjr.org>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Pubkey addresses
Precedence: list

On Saturday, December 17, 2011 6:46:34 PM Gregory Maxwell wrote:
> Sorry to be curt=E2=80=94 I'm a little irritated that discussion on recov=
ery
> in OP_EVAL was dropped because "input script size doesn't matter
> because of pruning" and now people are talking about adding another
> address type which creates seriously bloated transactions where there
> is pruning, because its slightly smaller in the no-pruning case (and
> again, still not as small for key recovery).

I missed that bit. I'm willing to defer full OP_EVAL support on Eligius in=
=20
order to enable key recovery...