From: Johnson Lau <jl2012@xbt•hk>
To: Luke Dashjr <luke@dashjr•org>,
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
Date: Mon, 2 Oct 2017 05:32:56 +0800 [thread overview]
Message-ID: <30B31B43-B603-4793-BDFB-B7E25FD96D1B@xbt.hk> (raw)
In-Reply-To: <201710010113.30518.luke@dashjr.org>
So there are 3 proposals with similar goal but different designs. I try to summarise some questions below:
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
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)
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.
——
Johnson
next prev parent reply other threads:[~2017-10-01 21:33 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 [this message]
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
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=30B31B43-B603-4793-BDFB-B7E25FD96D1B@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(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