Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 74.125.82.43 as permitted sender)
	client-ip=74.125.82.43; envelope-from=jgarzik@bitpay.com;
	helo=mail-wg0-f43.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAD5xwhgyCOdJwnXw+YchptfXjtshDi_VVEGOjR-hG2qV=u6m2g@mail.gmail.com>
References: <CAD5xwhgyCOdJwnXw+YchptfXjtshDi_VVEGOjR-hG2qV=u6m2g@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Thu, 17 Jul 2014 00:52:14 -0400
Message-ID: <CAJHLa0OFEDQp5umz=6_LUx5oJJmiKJoF90W7nvJPv0CtML+ftA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Pay to MultiScript hash:
Precedence: list

On Wed, Jul 16, 2014 at 1:56 PM, Jeremy <jlrubin@mit.edu> wrote:
> Right now, this could be expressed multiple ways (ie, using an op_dup if
> then else chain) , but all would incur additional costs in terms of
> complicated control flows. Instead, I would propose:

Can you quantify "additional costs in terms of complicated control flows"?


> There is an implication in terms of increased utxo pool bloat, but also an
> implication in terms of increased txn complexity (each 20 byte hash allows
> for a 500 byte script, only one of the 500 byte scripts has to be
> permanently stored on blockchain).

When considering these costs, using a normal P2SH output + a script
with OP_IF and friends seems more straightforward?

Doing boolean logic with multisig groups is quite possible, e.g.
"group AND group", "group OR (group AND group)" etc.  Definitely a
valid use case.  I discussed how to do this on IRC with gmaxwell
several months ago.  I call it "multi-multisig" for lack of a better
name.