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 6E61F3EE for ; Sun, 1 Oct 2017 02:23:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com [209.85.192.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7779DE1 for ; Sun, 1 Oct 2017 02:23:49 +0000 (UTC) Received: by mail-pf0-f180.google.com with SMTP id x78so1436765pff.10 for ; Sat, 30 Sep 2017 19:23:49 -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=O1I0KVOwBun76c7Xyn1CZtfV3MV/haXbqrsiRUR0Jag=; b=PB81DyEHt5hwsAnPjKMPRvBTJhZ80kBqonUMydYFbNBmhKRUJKk5pw6b4sf26yzH00 22Wn5itVDnaeQJ0KzPNcRMt34QtSxsRLng0PB+Lgjqp5W6wjhfoyTvdi3uunpV0y4io7 42hXWEdi7cFZLdNPskqZxbZUW0LKuamZkZbuhy8sOMsSjDpmCPBnVXAulAyezzJQV1Ey qpC/gj5cevFW8iGADDTeUhhX5rxfCD1lkUvIzI1CHZDQMypN4e8D8Bldga1pfhW5R4QK 8CT2OomHI6kq5+SxyPV6kCYheEQMuIEOjcFXcDBzwxu8fkV8lSkR3UCF1yI/Hs8yOmyA f28A== 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=O1I0KVOwBun76c7Xyn1CZtfV3MV/haXbqrsiRUR0Jag=; b=L1Dt1wDgznvJQ9T1pMtuMnpl8LCCl8dHbIOk+4oFVry5pYrSCjefub6ng3fI2VxMoR QnDNWxRTIklouv/WsJ8YiMSnHqnkyyTNZ4/0WOlNSSMFUnxKkCQimDnBNzqK+ICuRJCo H6YccvdJEVlJNctyYahVY2rIamgU3upY0J9GZVgMV0okmnj6slkw80gjBTdqUMAzmCGT FF5yiWmFI6j2/t9KZksKYFOdCOds2mzR66D5x+8kBXmA+AC2hIgoKKihHNfgXCVBVPuT SPKx9ONB/8rohGbjRitTBo80j5d+OFwHJ8BgYWV6d7PLrybofCnqd/zl7ocNqw9PITHG fPhA== X-Gm-Message-State: AHPjjUgBA9nF1GjKTNp6nsO3QYRbdfQptsOXPCB6sSCPW2K9tXpY6kZX dRME3Jj2Rb8uBKNTYGdoHp/+wGlJyIw= X-Google-Smtp-Source: AOwi7QDb4itEy+HOgnNvr84iUFHC0iD8dXdbucpmnfYanefvOGprA7WhPzEGh9K4W5PSS3PDoE5Xbg== X-Received: by 10.98.32.92 with SMTP id g89mr11394817pfg.285.1506824628889; Sat, 30 Sep 2017 19:23:48 -0700 (PDT) Received: from ?IPv6:2601:646:8080:1291:99eb:536:2ab0:7fc6? ([2601:646:8080:1291:99eb:536:2ab0:7fc6]) by smtp.gmail.com with ESMTPSA id j83sm13739648pfe.133.2017.09.30.19.23.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Sep 2017 19:23:47 -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 10.3 \(3273\)) Date: Sat, 30 Sep 2017 19:23:47 -0700 References: <201710010113.30518.luke@dashjr.org> To: Luke Dashjr , Bitcoin Protocol Discussion In-Reply-To: <201710010113.30518.luke@dashjr.org> Message-Id: <5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 01 Oct 2017 02:28:03 +0000 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: Sun, 01 Oct 2017 02:23:50 -0000 The CLEANSTACK rule should be eliminated, and instead the number of = items on the stack should be incorporated into the signature hash. That = way any script with a CHECKSIG is protected from witness extension = malleability, and those rare ones that do not use signature operations = can have a =E2=80=9CDEPTH 1 EQUALVERIFY=E2=80=9D at the end. This allows = for much simpler tail-call evaluation as you don=E2=80=99t need to pass = arguments on the alt-stack. > 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