public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Johnson Lau <jl2012@xbt.hk>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP141 segwit consensus rule update: extension of witness program definition
Date: Wed, 8 Jun 2016 13:57:36 +0800	[thread overview]
Message-ID: <A7E9BC23-6860-4B31-9D4E-11F771A5E581@xbt.hk> (raw)

[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]

Please note that the segregated witness (BIP141) consensus rule is updated. Originally, a witness program is a scriptPubKey or redeemScript that consists of a 1-byte push opcode (OP_0 to OP_16) followed by a data push between 2 and 32 bytes. The definition is now extended to 2 to 40 bytes:
https://github.com/bitcoin/bips/commit/d1b52cb198066d4e515e8a50fc3928c5397c3d9b https://github.com/bitcoin/bitcoin/pull/7910/commits/14d4d1d23a3cbaa8a3051d0da10ff7a536517ed0


Why?
----------
BIP141 defines only version 0 witness program: 20 bytes program for P2WPKH and 32 bytes program for P2WSH. Versions 1 to 16 are not defined, and are considered as anyone-can-spend scripts, reserved for future extension (e.g. the proposed BIP114). BIP141 also requires that only a witness program input may have witness data. Therefore, before this update, an 1-byte push opcode followed by a 33 bytes data push was not considered to be a witness program, and no witness data is allowed for that.

This may be over-restrictive for a future witness program softfork. When 32-byte program is used, this leaves only 16 versions for upgrade, and any “sub-version” metadata must be recorded in the witness field. This may not be compatible with some novel hashing functions we are exploring.

By extending the maximum length by 8 bytes, it allows up to 16 * 2 ^ 64 versions for future upgrades, which is enough for any foreseeable use.


Why not make it even bigger, e.g. 75 bytes?
----------
A 40 bytes witness program allows a 32-byte hash with 8-byte metadata. For any scripts that are larger than 32 bytes, they should be recorded in the witness field, like P2WSH in BIP141, to reduce the transaction cost and impact on UTXO set. Since SHA256 is already used everywhere, it is very unlikely that we would require a larger witness program (e.g. SHA512) without also a major revamp of the bitcoin protocol.

In any case, since scripts with a 1-byte push followed by a push of >40 bytes remain anyone-can-spend, we always have the option to redefine them with a softfork.


What are affected?
----------
As defined in BIP141, a version 0 witness program is valid only with 20 bytes (P2WPKH) or 32 bytes (P2WSH). Before this update, an OP_0 followed by a data push of 33-40 bytes was not a witness program and considered as anyone-can-spend. Now, such a script will fail due to incorrect witness program length.

Before this update, no witness data was allowed for a script with a 1-byte push followed by a data push of 33-40 bytes. This is now allowed.



Actions to take:
----------
If you are running a segnet node, or a testnet node with segwit code, please upgrade to the latest version at https://github.com/bitcoin/bitcoin/pull/7910

If you have an alternative implementation, please make sure your consensus code is updated accordingly, or your node may fork off the network.

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 671 bytes --]

             reply	other threads:[~2016-06-08  6:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-08  5:57 Johnson Lau [this message]
2016-06-08  7:29 ` [bitcoin-dev] BIP141 segwit consensus rule update: extension of witness program definition Luke Dashjr
2016-06-08  8:23   ` Johnson Lau
2016-06-08 16:45     ` Luke Dashjr
2016-06-12 14:40       ` Pieter Wuille

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=A7E9BC23-6860-4B31-9D4E-11F771A5E581@xbt.hk \
    --to=jl2012@xbt.hk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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