[bitcoin-dev] Version 1 witness programs (first draft)

Johnson Lau jl2012 at xbt.hk
Sun Oct 1 21:32:56 UTC 2017


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


More information about the bitcoin-dev mailing list