Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D9A05B65 for ; Thu, 5 Oct 2017 20:33:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f48.google.com (mail-pg0-f48.google.com [74.125.83.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2353FA8 for ; Thu, 5 Oct 2017 20:33:58 +0000 (UTC) Received: by mail-pg0-f48.google.com with SMTP id p5so8840319pgn.7 for ; Thu, 05 Oct 2017 13:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=36txL3dRC/HZ/jS7rJvWHUoAWMfyDuMutmeascNUzqI=; b=PFSxpozCbCEWfFmf4oP9ozw8WogxBHw0rIqMFMwvKbcTqR2qsSJ8DjUyYXZEmELpuc WlBBP8md2zvDt5sovBsGkzPy2DgZCM2zEM9kt87MrxWz4VMFHgSyHpiBGbR6AuMwiwyu Aygerw5rb/SFaj2deaDDKa1Rw5Cak8JnwwYLcuiVNvyRLw4tTqayh7TeTT9pqIZ6arXM bi/YmFsxdqmop0DzD48e12xVj0oVEoWzHgIX0vXVahRbgTVs21qoSFAdntkWwU9lAswe R7ygLf9lftgmy56H1wA0fE1P5MmijiUjQBB70c92LEDL6F0NYPyM+hq0I13YQBQXO6Ys 9A7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=36txL3dRC/HZ/jS7rJvWHUoAWMfyDuMutmeascNUzqI=; b=W24RM9yJoyj26z563wdkrOr8CmtQiMeXjwJoHHtek3yo5FI1rwLZW4TTWid8cNHsE2 VnLMSA2bheXFx709Az0zcFAfqEQIWNjreFVqz3zxHk6WvqNlR0YOM3joKtl8mJdGoxlr 4Z/bHvbOBP+anNY0lzhJ4weDtgxxbtpUSjoO6X7tvEO707ECqgLw7LPHYT77Lj/VVfd/ XuxbldHJYhc1NEO7JKbHu1pZMIphT2G7tctXsVzbSC/M7iPdiQZ9fm+0hwRhmOATf/vY 0r3ZIjXozlLruRejnnqmtp02pB1Q1+gpiq/aBPBA8nXm+l19kUpFi2xL1WIb4/2BHfD9 Fxow== X-Gm-Message-State: AMCzsaWu8w4p2Xw3l8i7b3DEbIk2HWkur64ix2hx+D5uAoRNS9U5ghKt AQ+kPlkJU6wI+QQ+toqKwzL1AnttYVE= X-Google-Smtp-Source: AOwi7QDQLBEdiE1p3feJ1QM8xtmiEiB5hgWyxIEVKXem6NkiAh8MTPKDOeUoznBjdjMqmqJJ8acP+Q== X-Received: by 10.99.123.88 with SMTP id k24mr11138081pgn.213.1507235638483; Thu, 05 Oct 2017 13:33:58 -0700 (PDT) Received: from [10.1.10.181] (c-73-189-35-88.hsd1.ca.comcast.net. [73.189.35.88]) by smtp.gmail.com with ESMTPSA id j186sm32493587pfg.164.2017.10.05.13.33.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 13:33:57 -0700 (PDT) From: Mark Friedenbach Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Date: Thu, 5 Oct 2017 13:33:56 -0700 References: <201710010113.30518.luke@dashjr.org> To: Luke Dashjr , Bitcoin Protocol Discussion In-Reply-To: <201710010113.30518.luke@dashjr.org> Message-Id: X-Mailer: Apple Mail (2.3445.1.6) X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft) 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, 05 Oct 2017 20:34:00 -0000 Here=E2=80=99s an additional (uncontroversial?) idea due to Russell = O=E2=80=99Connor: Instead of requiring that the last item popped off the stack in a = CHECKMULTISIG be zero, have it instead be required that it is a bitfield = specifying which pubkeys are used, or more likely the complement = thereof. This allows signatures to be matched to pubkeys in the order = given, and batch validated, with no risk of 3rd party malleability. Mark > On Sep 30, 2017, at 6:13 PM, Luke Dashjr via bitcoin-dev = wrote: >=20 > I've put together a first draft for what I hope to be a good next step = for=20 > Segwit and Bitcoin scripting: > = https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki >=20 > This introduces 5 key changes: >=20 > 1. Minor versions for witnesses, inside the witness itself. = Essentially the=20 > witness [major] version 1 simply indicates the witness commitment is = SHA256d,=20 > and nothing more. >=20 > The remaining two are witness version 1.0 (major 1, minor 0): >=20 > 2. As previously discussed, undefined opcodes immediately cause the = script to=20 > exit with success, making future opcode softforks a lot more flexible. >=20 > 3. If the final stack element is not exactly true or false, it is = interpreted=20 > as a tail-call Script and executed. (Credit to Mark Friedenbach) >=20 > 4. A new shorter fixed-length signature format, eliminating the need = to guess=20 > the signature size in advance. All signatures are 65 bytes, unless a = condition=20 > script is included (see #5). >=20 > 5. The ability for signatures to commit to additional conditions, = expressed in=20 > the form of a serialized Script in the signature itself. This would be = useful=20 > in combination with OP_CHECKBLOCKATHEIGHT (BIP 115), hopefully ending = the=20 > whole replay protection argument by introducing it early to Bitcoin = before any=20 > further splits. >=20 > This last part is a big ugly right now: the signature must commit to = the=20 > script interpreter flags and internal "sigversion", which basically = serve the=20 > same purpose. The reason for this, is that otherwise someone could = move the=20 > signature to a different context in an attempt to exploit differences = in the=20 > various Script interpretation modes. I don't consider the BIP = deployable=20 > without this getting resolved, but I'm not sure what the best approach = would=20 > be. Maybe it should be replaced with a witness [major] version and = witness=20 > stack? >=20 > There is also draft code implementing [the consensus side of] this: > = https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1 >=20 > Thoughts? Anything I've overlooked / left missing that would be=20 > uncontroversial and desirable? (Is any of this unexpectedly = controversial for=20 > some reason?) >=20 > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev