From: Jeremy <jlrubin@MIT•EDU>
To: Jeff Garzik <jgarzik@bitpay•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Pay to MultiScript hash:
Date: Thu, 17 Jul 2014 01:59:25 -0400 [thread overview]
Message-ID: <CAD5xwhhwMyL20nAUXz-Vv6m5ucH7UQcGQLyrFadAvqy4QXkbZw@mail.gmail.com> (raw)
In-Reply-To: <CAJHLa0OFEDQp5umz=6_LUx5oJJmiKJoF90W7nvJPv0CtML+ftA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]
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
time.
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".
ex:
code_sep
push script0
push script1
push script2
push script3
group_sep
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).
etc...
multisig check perm groups (checks if any groups on stack are valid from
script)
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 >
eval
On Thu, Jul 17, 2014 at 12:52 AM, Jeff Garzik <jgarzik@bitpay•com> wrote:
> 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.
>
--
Jeremy Rubin
[-- Attachment #2: Type: text/html, Size: 7287 bytes --]
next prev parent reply other threads:[~2014-07-17 5:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 17:56 Jeremy
2014-07-17 4:52 ` Jeff Garzik
2014-07-17 5:59 ` Jeremy [this message]
2014-07-17 6:21 ` Jeff Garzik
2014-07-17 19:55 ` Jeremy
2014-07-17 20:08 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD5xwhhwMyL20nAUXz-Vv6m5ucH7UQcGQLyrFadAvqy4QXkbZw@mail.gmail.com \
--to=jlrubin@mit$(echo .)edu \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@bitpay$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox