public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Version 1 witness programs (first draft)
@ 2017-10-01  1:13 Luke Dashjr
  2017-10-01  2:23 ` Mark Friedenbach
                   ` (3 more replies)
  0 siblings, 4 replies; 20+ messages in thread
From: Luke Dashjr @ 2017-10-01  1:13 UTC (permalink / raw)
  To: bitcoin-dev

I've put together a first draft for what I hope to be a good next step for 
Segwit and Bitcoin scripting:
    https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki

This introduces 5 key changes:

1. Minor versions for witnesses, inside the witness itself. Essentially the 
witness [major] version 1 simply indicates the witness commitment is SHA256d, 
and nothing more.

The remaining two are witness version 1.0 (major 1, minor 0):

2. As previously discussed, undefined opcodes immediately cause the script to 
exit with success, making future opcode softforks a lot more flexible.

3. If the final stack element is not exactly true or false, it is interpreted 
as a tail-call Script and executed. (Credit to Mark Friedenbach)

4. A new shorter fixed-length signature format, eliminating the need to guess 
the signature size in advance. All signatures are 65 bytes, unless a condition 
script is included (see #5).

5. The ability for signatures to commit to additional conditions, expressed in 
the form of a serialized Script in the signature itself. This would be useful 
in combination with OP_CHECKBLOCKATHEIGHT (BIP 115), hopefully ending the 
whole replay protection argument by introducing it early to Bitcoin before any 
further splits.

This last part is a big ugly right now: the signature must commit to the 
script interpreter flags and internal "sigversion", which basically serve the 
same purpose. The reason for this, is that otherwise someone could move the 
signature to a different context in an attempt to exploit differences in the 
various Script interpretation modes. I don't consider the BIP deployable 
without this getting resolved, but I'm not sure what the best approach would 
be. Maybe it should be replaced with a witness [major] version and witness 
stack?

There is also draft code implementing [the consensus side of] this:
    https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1

Thoughts? Anything I've overlooked / left missing that would be 
uncontroversial and desirable? (Is any of this unexpectedly controversial for 
some reason?)

Luke


^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2017-10-05 21:29 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-01  1:13 [bitcoin-dev] Version 1 witness programs (first draft) 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
2017-10-05 20:33 ` Mark Friedenbach
2017-10-05 21:28   ` Russell O'Connor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox