From: Mark Friedenbach <mark@friedenbach•org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST
Date: Mon, 18 Sep 2017 17:46:30 -0700 [thread overview]
Message-ID: <C623794E-F061-4C7A-B05D-378798ED2BF7@friedenbach.org> (raw)
In-Reply-To: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org>
As some of you may know, the MAST proposal I sent to the mailing list
on September 6th was discussed that the in-person CoreDev meetup in
San Francisco. In this email I hope to summarize the outcome of that
discussion. As chatham house rules were in effect, I will refrain from
attributing names to this summary..
* An introductory overview of the BIPs was presented, for the purpose
of familiarizing the audience with what they are attempting to
accomplish and how they do so.
* There was a discussion of a single vs multi-element MBV opcode. It
was put forward that there should perhaps be different opcodes for
the sake of script analysis, since a multi-element MBV will
necessarily consume a variable number of inputs. However it was
countered that if the script encodes the number of elements as an
integer push to the top of the stack immediately before the opcode,
then static analyzability is maintained in such instances. I took
the action item to investigate what an ideal serialization format
would be for a multi-element proof, which is the only thing holding
back a multi-element MBV proposal.
* It was pointed out that the non-clean-stack tail-call semantics is
not compatible with segwit's consensus-enforcement of the clean
stack rule. Some alternatives were suggested, such as changing
deployment mechanisms. After the main discussion session it was
observed that tail-call semantics could still be maintained if the
alt stack is used for transferring arguments to the policy script. I
will be updating the BIP and example implementation accordingly.
* The observation was made that single-layer tail-call semantics can
be thought of as really being P2SH with user-specified hashing. If
the P2SH script template had been constructed slightly differently
such as to not consume the script, it would even have been fully
compatible with tail-call semantics.
* It was mentioned that using script versioning to deploy a MAST
template allows for saving 32 bytes of witness per input, as the
root hash is contained directly in the output being spent. The
downside however is losing the permissionless innovation that comes
with a programmable hashing mechanism.
* The discussion generally drifted into a wider discussion about
script version upgrades and related issues, such as whether script
versions should exist in the witness as well, and the difference in
meaning between the two. This is an important subject, but only of
relevance in far as using a script version upgrade to deploy MAST
would add significant delay from having to sort through these issues
first.
This feedback led to some minor tweaks to the proposal, which I will
be making, as well as the major feature request of a multi-element
MERKLE-BLOCK-VERIFY opcode which requires a little bit more effort to
accomplish. I will report back to this list again when that work is
done.
Sincerely,
Mark Friedenbach
next prev parent reply other threads:[~2017-09-19 0:46 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 [this message]
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
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=C623794E-F061-4C7A-B05D-378798ED2BF7@friedenbach.org \
--to=mark@friedenbach$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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