From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5C271B7B for ; Thu, 20 Apr 2017 20:29:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id F13301BF for ; Thu, 20 Apr 2017 20:29:02 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 92AAB38A1330 for ; Thu, 20 Apr 2017 20:28:54 +0000 (UTC) X-Hashcash: 1:25:170420:bitcoin-dev@lists.linuxfoundation.org::OkZ63KPUGlCSYNU3:agxSO From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org Date: Thu, 20 Apr 2017 20:28:52 +0000 User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; ) X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201704202028.53113.luke@dashjr.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Segwit v2 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 20:29:03 -0000 Since BIP 141's version bit assignment will timeout soon, and needing renewal, I was thinking it might make sense to make some minor tweaks to the spec for the next deployment. These aren't critical, so it's perfectly fine if BIP 141 activates as-is (potentially with BIP 148), but IMO would be an improvement if a new deployment (non-BIP148 UASF and/or new versionbit) is needed. 1. Change the dummy marker to 0xFF instead of 0. Using 0 creates ambiguity with incomplete zero-input transactions, which has been a source of confusion for raw transaction APIs. 0xFF would normally indicate a >32-bit input count, which is impossible right now (it'd require a >=158 GB transaction) and unlikely to ever be useful. 2. Relax the consensus rules on when witness data is allowed for an input. Currently, it is only allowed when the scriptSig is null, and the scriptPubKey being spent matches a very specific pattern. It is ignored by "upgrade-safe" policy when the scriptPubKey doesn't match an even-more-specific pattern. Instead, I suggest we allow it (in the consensus layer only) in combination with scriptSig and with any scriptPubKey, and consider these cases to be "upgrade-safe" policy ignoring. The purpose of the second change is to be more flexible to any future softforks. I consider it minor because we don't know of any possibilities where it would actually be useful. Thoughts? Luke