[Bitcoin-development] Pay to MultiScript hash:

Jeremy jlrubin at MIT.EDU
Thu Jul 17 05:59:25 UTC 2014

Additional costs would be in terms of A) chance of user error/application
error -- proposed method is much simpler, as well as extra bytes for
control flow ( 4 per script if I am counting right).

The costs on a normal script do seem slightly more friendly, except this
method allows for hidden-till-spent permission groups, as well as as
smaller blockchain bloat overall (if scriptSig script has to store the
logic for all the potential permission group, it will be a larger script
versus only needing one permission group's script). An added benefit could
also be in blockchain analysis -- you can actively monitor the utxo pool
for your known associated scripts, whereas you couldn't for specialty
scripts assembled per group. Enables repeated spends with groups as a "cost
object" w/o having to recall all participants. ie, pay to the same perm
groups as the other employee did last time, but include me as a root this

Do you have a transcript of that chat by any chance? An interesting way to
do that would be to push the sigs onto the stack & have implicit orders,
then do expressions with their aliases, and then be able to assign
"spending groups".
push script0
push script1
push script2
push script3
mkgroup_2, 0,1      ; the id will be 4
mkgroup_3, 0,2,3   ; the id will be 5
mkUnionGroup_2, 4,5 ; the id will be 6
2_of_3_group 0, 1, 2
mkIntersectionGroup_2 5, 6
complement_last  ; complements last group, mutation
del_group 1          ; deletes the group #1, groups then reindex after
deletion (maybe the group was useful base class).
multisig check perm groups (checks if any groups on stack are valid from

or even something like adding a little SAT scripting language with an eval.

push script0
push script1
push script2
push script3
push <a=(1 & 2 & 0), b=a-1, a | 3 | b >

On Thu, Jul 17, 2014 at 12:52 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:

> On Wed, Jul 16, 2014 at 1:56 PM, Jeremy <jlrubin at 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.

Jeremy Rubin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140717/6d590441/attachment.html>

More information about the bitcoin-dev mailing list