Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.47 as permitted sender)
	client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com;
	helo=mail-qw0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <43351.137.56.163.46.1312351847.squirrel@lavabit.com>
References: <CAAS2fgQ-L-1K2Oi40tqnhxpnnWQHqgbd4BmqedhA3WcevYiCzg@mail.gmail.com>
	<43351.137.56.163.46.1312351847.squirrel@lavabit.com>
Date: Thu, 4 Aug 2011 16:35:53 -0400
Message-ID: <CAAS2fgQ6GXfebUV8_PLVpLJ9jvPF8FXiBqwquhGFNZ+Vt3uCtg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: bgroff@lavabit.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discussion related to pull 349 and pull
 319 (escrow transactions)
Precedence: list

On Wed, Aug 3, 2011 at 2:10 AM,  <bgroff@lavabit.com> wrote:
> Thank you! =C2=A0(I think you mean 319 here)

Correct.

> With Eligius mining !IsStandard transactions and probably other pools ope=
n
> to the idea, I am hopeful that we can quickly get 30%+ of mining power to
> upgrade, which means that we could still mine these in a reasonable time
> frame (under 1 hour).

It's not just a matter of mining power, it's also a question of
propagation.  Matt and I tried to perform a non-standard transaction
weeks ago and weren't able to get in mined after many hours. (we
eventually double spent the input with a normal transaction in order
to make it go away, interestingly one point about non-propagating txn
is that they're extra vulnerable to double spending by a standard txn,
as the non-standard one won't preclude the propagation of the standard
one)

From discussion on IRC it seemed clear enough that the current focus
on maturity/bugfixes is probably going to delay your full patch, but
the IsStandard part is uncontroversial and could go in quickly.

Based on that I think it would be very useful to split 319 into two
pull requests: one which does the IsStandard change, and one which
adds the full escrow feature set.  This way when the escrow patch does
enter the mainline client it will be meet up with a network which is
happy to handle its transactions.

(and people who are eager to use escrow can use modified clients on
the main network before that point in time)

> I'm not sure I see the problem here.  CScript.operator<< currently insert=
s
> values into scripts using the shortest possible sequence.

Ah for some reason I thought your current code did not always produce
the shortest sequence.

If so, I see no reason to block on the other pull.