Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6BC5997 for ; Sun, 1 Oct 2017 18:34:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f169.google.com (mail-pf0-f169.google.com [209.85.192.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DCC7E3D5 for ; Sun, 1 Oct 2017 18:34:09 +0000 (UTC) Received: by mail-pf0-f169.google.com with SMTP id p87so1918787pfj.9 for ; Sun, 01 Oct 2017 11:34:09 -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=UAv1FDDXjNcP+XEOq14057pu+fwfJgFDUq7kkOMFo0I=; b=JWapo2X6dFBsYpt4tZNdirqjp+/1sJ6Wt7Uao7lZgNY4ZDiY8xViaWYFrXKRXN+eQT AGv3EdqAdiOky65zAdjA/IAwD4Ku6KRzYC6IeQIvtH1Ma1jB8G/IWerdbQ7Uth9jcSKH lBNVY4zMZrIjcYFaObtjSKiKPT0CHZjESDHLxXjURQGSRfASoYGPoIKCQYrjycxqHEfI 1Wc8pNJJdosKVyNKJAABZlQAk2CRTAQ9T0TNiAzC69OXp8HvcpHffAtHzJ+a2BEYaKf0 EvnVSj2gG6qhfHwHCdVSJVgq2ecyktnS+mb99oELI9XHrZlAwgBIc9n2hQXzA0YFzKUl gbVA== 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=UAv1FDDXjNcP+XEOq14057pu+fwfJgFDUq7kkOMFo0I=; b=m0xuqn9iFYzBpjZ9Y3qgP2FRQTwf775qLa/TEm+5XDuoh4SuyScDrWCf1/VG73t8C8 Ms/kOihbsJasfaIDuZHR9aVCvqxn/Ap1Cf2GWy+jNZP6tjbm+FqOgQLRwb/b5Gk4sHri vyLXKnsIWAAOHawY0kkqo6h4MKqfJmZpYYSIH3f25SKJ5EYAXX4oGIJIdvBJp38fkfza tuDva5bf9EIEJFLpXOwZYny1A43sgqRUsWhKXT4yUKe+IDIlUlVL6i0RK3KGQFj4vqof 7k4iVWitJa41omGCFtAHB9Q0fyyynYukLSpjfEkPcszaBcN8A5lU3pgxFN3rm2kQZd8M Y0qg== X-Gm-Message-State: AMCzsaXgv4P/DMDMKzMYei88VbLxGzlLc8NdycVChaCV4AlwTlfSJqws 9Gf7tXCE9sevyxz1MJH0KqtN44fAb4k= X-Google-Smtp-Source: AOwi7QAqQzPttBHgmPFfL51Tf85JqjQVB5IYgiiB3ZACqFxfgvM/wbago6ecjC74m963+3kqIifFCA== X-Received: by 10.84.229.68 with SMTP id d4mr1595702pln.397.1506882849419; Sun, 01 Oct 2017 11:34:09 -0700 (PDT) Received: from ?IPv6:2601:646:8080:1291:39e7:3724:6f96:6f4b? ([2601:646:8080:1291:39e7:3724:6f96:6f4b]) by smtp.gmail.com with ESMTPSA id y1sm14523724pgp.15.2017.10.01.11.34.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Oct 2017 11:34:08 -0700 (PDT) From: Mark Friedenbach Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Date: Sun, 1 Oct 2017 11:34:07 -0700 References: <201710010113.30518.luke@dashjr.org> To: Luke Dashjr , Bitcoin Protocol Discussion In-Reply-To: <201710010113.30518.luke@dashjr.org> Message-Id: <089161B1-9AD6-45A2-BE0A-215FECC19510@friedenbach.org> X-Mailer: Apple Mail (2.3445.1.6) 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 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 18:34:12 -0000 I would also suggest that the 520 byte push limitation be removed for v1 = scripts as well. MERKLEBRANCHVERIFY in particular could benefit from = larger proof sizes. To do so safely would require reworking script = internals to use indirect pointers and reference counting for items on = stack, but this is worth doing generally, and introducing a per-input = hashing limit equal to a small multiple of the witness size (or = retaining the opcount limit). > 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