Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of lavabit.com
	designates 72.249.41.33 as permitted sender)
	client-ip=72.249.41.33; envelope-from=bgroff@lavabit.com;
	helo=karen.lavabit.com; 
Message-ID: <43351.137.56.163.46.1312351847.squirrel@lavabit.com>
In-Reply-To: <CAAS2fgQ-L-1K2Oi40tqnhxpnnWQHqgbd4BmqedhA3WcevYiCzg@mail.gmail.com>
References: <CAAS2fgQ-L-1K2Oi40tqnhxpnnWQHqgbd4BmqedhA3WcevYiCzg@mail.gmail.com>
Date: Wed, 3 Aug 2011 02:10:47 -0400 (EDT)
From: bgroff@lavabit.com
To: "Gregory Maxwell" <gmaxwell@gmail.com>
User-Agent: SquirrelMail/1.4.13
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
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

Gregory Maxwell wrote:

> Pull 349 (https://github.com/bitcoin/bitcoin/pull/349)
> implements a pretty nice implementation of multiple signature escrowed
> transactions. Especially with clearcoin gone I think that this is
> something we ought to have sooner rather than later.
>
> I've tested it on a private network and it appears to work pretty well.

Thank you!  (I think you mean 319 here)

> It probably needs more testing and discussion before it is actually
> added to the client, but one challenge is that because it requires a
> new transaction type it won't be deployable until _after_ an updated
> isStandard is widely used in the network.

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).

...

> Unfortunately, the patch exposes an issue with multisig validation: If
> I understand it correctly, the problem is that due to redundancy in
>  the script length coding opcodes it's possible to code a script
> multiple ways. The signature validation code creates new template
> scripts in order to evaluate signatures for one output, and the code
> in bitcoin is not careful to code the new script the same way the
> original one was coded, causing the signature validation to fail when
> something used OP_PUSHDATA when a direct length could have been used.
>

I'm not sure I see the problem here.  CScript.operator<< currently insert=
s
values into scripts using the shortest possible sequence.  As long as cod=
e
continues to conform to this convention, scripts generated by it will
verify correctly.

If new code is written that generates one of the longer sequences, it wil=
l
generate transactions that will not pass block validation since the
signature won't verify.  So such code will be useless and we can refrain
from writing it?

--
Bobby Groff