Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.161.47 as permitted sender)
	client-ip=209.85.161.47; envelope-from=gavinandresen@gmail.com;
	helo=mail-fx0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <D0D808D6-DBF2-47C0-A65A-22AE689C861F@ceptacle.com>
References: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
	<201108241215.36847.luke@dashjr.org>
	<CAAS2fgQspsXy1Vw=fNr1FvsDRkEbP6dEcFLgUpK9DrBKXyiWNg@mail.gmail.com>
	<CAJ1JLtsxPG9v-Hwdb-pfgY6GU0Z4it+frFzw_tObVbNC6Xgdjw@mail.gmail.com>
	<CAAS2fgTARAMqMu79Sp4XS4KxmUBWiXebpavHWr-EdLZbxS=sTw@mail.gmail.com>
	<CAJ1JLttqEnCjALadESmpntxSobD8Lj1zcXL4S7ghqdhyBrwVNw@mail.gmail.com>
	<CABsx9T12R2dd=Ak7k4N+ZVAyLvJnx9oS0vVjwRa5T+UoCjbEMQ@mail.gmail.com>
	<D0D808D6-DBF2-47C0-A65A-22AE689C861F@ceptacle.com>
Date: Thu, 25 Aug 2011 13:18:24 -0400
Message-ID: <CABsx9T0vqbFwTJL2gj0N3FWH7KkEN+0FjRWR9_XqbEuxNMM6Aw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: =?ISO-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] New standard transaction types: time to
 schedule a blockchain split?
Precedence: list

On Thu, Aug 25, 2011 at 3:39 AM, Michael Gr=F8nager <gronager@ceptacle.com>=
 wrote:
> Put in another way - do we *really* need to couple the securing of the wa=
llet to creating a new address type ?

Nope.

I should have been more clear in my initial email and in the
proposal-- I am not proposing anything more than just agreeing on the
very lowest-level infrastructure, so there is a solid foundation upon
which we can build a couple of key very-high-priority features.

I wanted to talk about it now so there is rough consensus on what to
put on the road map, and to get as many smart brains looking at the
proposal and making it as good as possible.  Current proposal is at:
  https://gist.github.com/39158239e36f6af69d6f

I have two issues with it:

1) groffer reports that there's a bug in CHECKMULTISIG (pops too many
arguments off the stack), so perhaps we should avoid using it at all.
Fixing the bug would change its behavior, and is not an option because
that would cause a blockchain split. We absolutely need unit tests and
better documentation for how CHECKMULTISIG behaves (perhaps it is
working as intended, and Satoshi just messed up the description of
what it does in the comment).

2) How often will the 1-of-3 and 3-of-3 cases be used? I included them
just for completeness, but perhaps they should be dropped for now so
there is less code to write and test.  I just don't imagine there are
many cases where you have exactly three parties and 1-of-3 or 3-of-3
are required to spend.


--=20
--
Gavin Andresen