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

On Saturday, December 17, 2011 7:28:12 PM Luke-Jr wrote:
> 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 rec=
overy
> > 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).
>=20
> I missed that bit. I'm willing to defer full OP_EVAL support on Eligius in
> order to enable key recovery...

In fact, as long as we have this opportunity to enable new opcodes, maybe w=
e=20
should spend some time revisiting what doors that opens...