From: Luke Dashjr <luke@dashjr•org>
To: Johnson Lau <jl2012@xbt•hk>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
Date: Mon, 2 Oct 2017 00:45:22 +0000 [thread overview]
Message-ID: <201710020045.30259.luke@dashjr.org> (raw)
In-Reply-To: <30B31B43-B603-4793-BDFB-B7E25FD96D1B@xbt.hk>
On Sunday 01 October 2017 9:32:56 PM Johnson Lau wrote:
> 1. How do we allow further upgrade within v1 witness? Here are some
> options: a. Minor version in witness. (Johnson / Luke) I prefer this way,
> but we may end up with many minor versions. b. OP_RETURNTRUE (Luke). I
> proposed this in an earlier version of BIP114 but now I think it doesn’t
> interact well with signature aggregation, and I worry that it would have
> some other unexpected effects. c. Generalised NOP method: user has to
> provide the returned value, so even VERIFY-type code could do anything
I like (A) and (B). Use B when practical, and (A) when more fundamental
changes are needed. SigAgg is a concern, but there are ways to adapt it.
(C) is harmless, but I think unnecessary with (A) and/or (B).
> 2. Do we want to allow signature-time commitment of extra scripts?
> I think all proposals allow this, just with different way
> a. Tail-call semantics with CHECKSIGFROMSTACK (Mark). I think this is too
> rigid as it works only with specially designed scriptPubKey b.
> scriptWitCode: extra scripts are put in some fixed location in witness
> (Johnson). This makes sure static analysability. c. Extra-data as script
> in OP_CHECKSIG (Luke)
Note that my BIP draft supports both (A) and (C).
> 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?
Luke
next prev parent reply other threads:[~2017-10-02 0:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-01 1:13 Luke Dashjr
2017-10-01 2:23 ` Mark Friedenbach
2017-10-01 2:47 ` Luke Dashjr
2017-10-01 5:04 ` Mark Friedenbach
2017-10-01 11:22 ` Felix Weis
2017-10-01 17:36 ` Luke Dashjr
2017-10-01 19:05 ` Russell O'Connor
2017-10-01 19:27 ` Mark Friedenbach
2017-10-01 19:41 ` Russell O'Connor
2017-10-01 20:39 ` Mark Friedenbach
2017-10-01 20:43 ` Luke Dashjr
2017-10-02 20:38 ` Russell O'Connor
2017-10-01 18:34 ` Mark Friedenbach
2017-10-01 21:32 ` Johnson Lau
2017-10-02 0:35 ` Mark Friedenbach
2017-10-02 2:56 ` Luke Dashjr
2017-10-02 9:09 ` Sjors Provoost
2017-10-02 0:45 ` Luke Dashjr [this message]
2017-10-05 20:33 ` Mark Friedenbach
2017-10-05 21:28 ` Russell O'Connor
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=201710020045.30259.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
/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