From: "Russell O'Connor" <roconnor@blockstream•io>
To: Mark Friedenbach <mark@friedenbach•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST
Date: Mon, 2 Oct 2017 13:15:38 -0400 [thread overview]
Message-ID: <CAMZUoK=SwR6=vWCo54_Yd11nbbwD0q60n42Uj38Yq_sWD2zS9g@mail.gmail.com> (raw)
In-Reply-To: <921EB5CF-B472-4BD6-9493-1A681586FB51@friedenbach.org>
[-- Attachment #1: Type: text/plain, Size: 5198 bytes --]
(Subject was: [bitcoin-dev] Version 1 witness programs (first draft)), but
I'm moving part of that conversation to this thread.
On Sun, Oct 1, 2017 at 5:32 PM, Johnson Lau <jl2012@xbt•hk> wrote:
> 3. Do we want to allow static analysis of sigop?
> BIP114 and the related proposals are specifically designed to allow static
> analysis of sigop. I think this was one of the main reason of OP_EVAL not
> being accepted. This was also the main reason of Ethereum failing to do a
> DAO hacker softfork, leading to the ETH/ETC split. I’m not sure if we
> really want to give up this property. Once we do it, we have to support it
> forever.
I would very much like to retain the ability to do static analysis. More
generally, the idea of interpreting arbitrary data as code, as done in
OP_EVAL and in TAILCALL, makes me quite anxious. This at the root of many
security problems throughout the software industry, and I don't relish
giving more fuel to the underhanded Bitcoin Script contestants.
On Sun, Oct 1, 2017 at 8:45 PM, Luke Dashjr <luke@dashjr•org> wrote:
> > 3. Do we want to allow static analysis of sigop?
> > BIP114 and the related proposals are specifically designed to allow
> static
> > analysis of sigop. I think this was one of the main reason of OP_EVAL not
> > being accepted. This was also the main reason of Ethereum failing to do a
> > DAO hacker softfork, leading to the ETH/ETC split. I’m not sure if we
> > really want to give up this property. Once we do it, we have to support
> it
> > forever.
>
> It seems inevitable at this point. Maybe we could add a separate
> "executable-
> witness" array (in the same manner as the current witness was softforked
> in),
> and require tail-call and condition scripts to merely reference these by
> hash,
> but I'm not sure it's worth the effort?
>
> Thinking further, we could avoid adding a separate executable-witness
> commitment by either:
> A) Define that all the witness elements in v1 are type-tagged (put the
> minor
> witness version on them all, and redefine minor 0 as a stack item?); or
> B) Use an empty element as a delimiter between stack and executable items.
>
> To avoid witness malleability, the executable items can be required to be
> sorted in some manner.
>
> The downside of these approaches is that we now need an addition 20 or 32
> bytes per script reference... which IMO may possibly be worse than losing
> static analysis. I wonder if there's a way to avoid that overhead?
>
Actually, I have a half-baked idea I've been thinking about along these
lines.
The idea is to add a flag to each stack item in the Script interpreter to
mark whether the item in the stack is "executable" or "non-executable", not
so different from how computers mark pages to implement executable space
protection. By default, all stack items are marked "non-executable". We
then redefine OP_PUSHDATA4 as OP_PUSHCODE within ScriptSigs. The
operational semantics of OP_PUSHCODE would remain the same as OP_PUSHDATA4
except it would set the pushed item's associated flag to "executable". All
data pushed by OP_PUSHCODE would be subject to the sigops limits and any
other similar static analysis limits.
Segwit v0 doesn't use OP_PUSHDATA codes to create the input stack, so we
would have to mark executable input stack items using a new witness v1
format. But, IIUC, TAILCALL isn't going to be compatible with Segwit v0
anyway.
During a TAILCALL, it is required that the top item on the stack have the
"executable" flag, otherwise TAILCALL is not used (and the script succeeds
or fails based on the top item's data value as usual).
All other operations can treat "executable" items as data, including the
merkle branch verification. None of the Script operations can create
"executable" items; in particular, OP_PUSHDATA4 within the ScriptPubKey
also would not create "executable" items. (We can talk about the behaviour
of OP_CAT when that time comes).
One last trick is that when "executable" values are duplicated, by OP_DUP,
OP_IFDUP, OP_PICK. then the newly created copy of the value on top of the
stack is marked "non-executable".
Because we make the "executable" flag non-copyable, we are now free to
allow unbounded uses of TAILCALL (i.e. TAILCALL can be used multiplie times
in a single input). Why is this safe? Because the number of "executable"
items decreases by at least one every time TAILCALL is invoked. the number
of OP_PUSHCODE occurrences in the witness puts an upper bound on the number
of invocations of TAILCALL allowed. Using static analysis of the script
pubkey and the data within the OP_PUSHCODE data, we compute an upper bound
on the number of operations (of any type) that can occur during execution.
Unbounded TAILCALL should let us (in the presence of OP_CHECKSIGFROMSTACK)
have unbounded delegation.
Overall, I believe that OP_PUSHCODE
1. is fully backwards compatible.
2. maintains our ability to perform static analysis with TAILCALL.
3. never lets us interpret computed values as executable code.
4. extends TAILCALL to safely allow multiple TAILCALLs per script.
[-- Attachment #2: Type: text/html, Size: 6667 bytes --]
next prev parent reply other threads:[~2017-10-02 17:16 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-07 0:38 Mark Friedenbach
2017-09-08 9:21 ` Johnson Lau
2017-09-12 2:03 ` Mark Friedenbach
2017-09-12 2:13 ` Bryan Bishop
2017-09-12 8:55 ` Johnson Lau
2017-09-12 19:57 ` Mark Friedenbach
2017-09-12 23:27 ` Karl Johan Alm
2017-09-13 9:41 ` Peter Todd
2017-09-11 20:37 ` Adán Sánchez de Pedro Crespo
2017-09-19 0:46 ` Mark Friedenbach
2017-09-19 3:09 ` [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Luke Dashjr
2017-09-19 7:33 ` Mark Friedenbach
2017-09-22 20:32 ` Sergio Demian Lerner
2017-09-22 21:11 ` Mark Friedenbach
2017-09-22 21:32 ` Sergio Demian Lerner
2017-09-22 21:39 ` Mark Friedenbach
2017-09-22 21:54 ` Sergio Demian Lerner
2017-09-22 22:07 ` Mark Friedenbach
2017-09-22 22:09 ` Pieter Wuille
2021-04-09 8:15 ` [bitcoin-dev] maximum block height on transaction Erik Aronesty
2021-04-09 11:39 ` Russell O'Connor
2021-04-09 15:54 ` Jeremy
2021-04-12 20:04 ` Billy Tetrud
2021-04-16 4:24 ` ZmnSCPxj
2021-05-03 2:30 ` ZmnSCPxj
2017-09-20 5:13 ` [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Johnson Lau
2017-09-20 19:29 ` Mark Friedenbach
2017-09-21 3:58 ` Johnson Lau
2017-09-21 4:11 ` Luke Dashjr
2017-09-21 8:02 ` Johnson Lau
2017-09-21 16:33 ` Luke Dashjr
2017-09-21 17:38 ` Johnson Lau
2017-09-30 23:23 ` [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Luke Dashjr
2017-09-30 23:51 ` Mark Friedenbach
2017-10-02 17:15 ` Russell O'Connor [this message]
2017-10-28 4:40 ` Mark Friedenbach
2017-11-01 8:43 ` Luke Dashjr
2017-11-01 15:08 ` Mark Friedenbach
2017-11-04 7:59 ` Luke Dashjr
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='CAMZUoK=SwR6=vWCo54_Yd11nbbwD0q60n42Uj38Yq_sWD2zS9g@mail.gmail.com' \
--to=roconnor@blockstream$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=mark@friedenbach$(echo .)org \
/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