BIP 141: Segregated Witness (Consensus layer) #265
Conversation
CodeShark
force-pushed
the
segwit
branch
5 times, most recently
from
78eb898
to
7f19639
Compare
| <pre> | ||
| BIP: x | ||
| Title: Segregated Witness (Consensus layer) | ||
| Author: |
CodeShark
force-pushed
the
segwit
branch
4 times, most recently
from
faf8ab2
to
ec059d1
Compare
| #* Sum trees for transaction inputs and outputs can be committed making it possible to construct short proofs that no new coins are created in any noncoinbase transaction and that the miner does not add excessive fees to the coinbase transaction. | ||
|
|
||
| ==Specification== | ||
| Maybe a seperate BIP |
There was a problem hiding this comment.
the comment refers to the p2p serialization and relay stuff - what follows is the consensus specification, which WILL be in this document.
| == Backward compatibility == | ||
| As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features. | ||
|
|
||
| === Version 0 witness programs === |
There was a problem hiding this comment.
This was confusing to me. You're not talking about Version 0 and Version 1 witness programs here are you? Aren't you just talking about whether or not the witness program is also embedded in a P2SH regardless of what version witness it is?
There was a problem hiding this comment.
yeah, the description is somewhat inaccurate. I'll edit it
|
|
||
| === Witness program === | ||
|
|
||
| * A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a single push of 2 to 41 bytes gets a new special meaning. The byte vector pushed by it is called the "witness program". |
Clarify Backward compatibility and separating version byte and witness program
Fixed typos.
|
related BIPs, for easy reference;
and WIP code: |
|
|
||
| The script is executed with the remaining data from witness: | ||
|
|
||
| 0 <signature1> 1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG |
There was a problem hiding this comment.
The segwit update seems like the perfect moment to get rid of that CHECKMULTISIG bug where one item too many is popped off the stack. Although probably should be done in #270.
There was a problem hiding this comment.
No bikeshedding about what changes to make, please :(
We have script versions now, so we do not need to fix all inconveniences at
once.
There are two exceptions to this self-imposed rule:
- Changing the sighashing to not be O(n^2), as it wouldn't be a bugfix to a
worst-case scenario if it's optional for an attacker. - Amount signing, as I didn't expect that people would accept any sighash
change proposal that did not include this...
|
is there a reason why the transaction version is not bumped for the new structure? |
|
Yes. There is no need:
|
|
|
||
| witness: <signature> <pubkey> | ||
| scriptSig: (empty) | ||
| scriptPubKey: OP_0 <0x76A914{20-byte-hash-value}88AC> |
There was a problem hiding this comment.
nit: use OP_0 <DUP HASH160 {20-byte-hash-value} EQUALVERIFY CHECKSIG>?
There was a problem hiding this comment.
@jonasschnelli Isn't the deserialized format below?
There was a problem hiding this comment.
It's shown in the deserialized script
…n#265) Fixes: bitcoin#261 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
BIP number requested,