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 2EDF8499 for ; Sun, 1 Oct 2017 19:27:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9BCF8204 for ; Sun, 1 Oct 2017 19:27:23 +0000 (UTC) Received: by mail-pf0-f177.google.com with SMTP id l188so1951172pfc.6 for ; Sun, 01 Oct 2017 12:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=x/R1OyVGX9++bvVhAXTAbbjznB19Qk2r82Kihd8rEW8=; b=wjAf0Vu2ZdvM0tg6prFs+/rAi0qNyxWC7wASiDnuQUhWUjS7cCd5TpC9njDR7a1h/Q jU7XMG7djjxzddG7ZksygTfGiGLomQRuitXm4LnzDqhLYW7vfQq+sImY8izyOGsR6CNz KItydwx592KJPX1LdefySG79tENSTSU6YMoM7oOXXsET93h91akaDfdWA7l+1Y+ozsQu MHsWxtn006m4OLHmNwdmM4OR/zh5R1tuV/SlYC0WR7Axd1YN0RHQ6IKOZs7TYNj24IYP RWltIksxdBQRnUOHdMQ/7k5oGRFvREvJ1ETIlsVx8vH+2Uw7Zlp2MgKLZndT38zpkIEe fy5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=x/R1OyVGX9++bvVhAXTAbbjznB19Qk2r82Kihd8rEW8=; b=gHAZpvtOUK97Pyau5Rw/fxZ0Nu4NRVe7jCitDwrlpC6JdNvxOrltCokOPZUE51d+WV V1fi8AlqxzeFJa/EXwjo+pQIvkyrdheBOubMsxn6Xt7OwniHvVM3Uh3f316dcGVQiuNq p4IrWht9rW5g/0xTO6u2D4L4NdcC1Xys2jwe2fddtHmrhEN4w5jfxKUjWysSXVXZVcy9 iBlJ5t60g8d/ef3gYxLdE1M4NszcrMnmD521LStLqsHUea2saQ/O4VsfsofzaKMAJ7LD Ml0A08bhpaoCNA+N9YugCryiGvHrCmpGb1w/HxDodW0mKFIl/Jfm2ZgoXdqJzB1TgdxZ D5Uw== X-Gm-Message-State: AHPjjUglm/gIREqf3ybWn5RX5CS8nV2+UV5miTwhibdvYXYjSSBHTPhQ 6weDcPNcm+TILgon73Y8kWl50EmshFE= X-Google-Smtp-Source: AOwi7QBcNZmZxUUi1G4gW2kysfopfdqmDb34OMDfcOrn49s+akTA/jSnuUeT/A8Ztk61TrwBLS5FpA== X-Received: by 10.99.121.77 with SMTP id u74mr10482062pgc.180.1506886043141; Sun, 01 Oct 2017 12:27:23 -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 77sm14623980pfi.103.2017.10.01.12.27.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Oct 2017 12:27:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Mark Friedenbach In-Reply-To: Date: Sun, 1 Oct 2017 12:27:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <460EDF1F-2BFD-4DBE-A921-73469C2EA9B9@friedenbach.org> References: <201710010113.30518.luke@dashjr.org> <5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org> <201710010247.42180.luke@dashjr.org> To: Russell O'Connor 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 Cc: Bitcoin Protocol Discussion 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 19:27:24 -0000 > On Oct 1, 2017, at 12:05 PM, Russell O'Connor = wrote: >=20 > Given the proposed fixed signature size, It seems better to me that we = create a SIGHASH_WITNESS_WEIGHT flag as opposed to = SIGHASH_WITNESS_DEPTH. For what benefit? If your script actually uses all the items on the = stack, and if your script is not written in such a way as to allow = malleability (which cannot be prevented in general), then they=E2=80=99re = equivalent. Using weight instead of depth only needlessly restricts = other parties to select a witness size up-front. And to be clear, signing witness weight doesn=E2=80=99t mean the witness = is not malleable. The signer could sign again with a different ECDSA = nonce. Or if the signer is signing from a 2-of-3 wallet, a common = scenario I hope, there are 3 possible key combinations that could be = used. If using MBV, a 3-element tree is inherently unbalanced and the = common use case can have a smaller proof size. Witnesses are not 3rd party malleable and we will maintain that property = going forward with future opcodes. > Mark, you seem to be arguing that in general we still want weight = malleability even with witness depth fixed, but I don't understand in = what scenario we would want that. Any time all parties are not online at the same time in an interactive = signing protocol, or for which individual parties have to reconfigure = their signing choices due to failures. We should not restrict our script = signature system to such a degree that it becomes difficult to create = realistic signing setups for people using best practices (multi-key, = 2FA, etc.) to sign. If I am a participant in a signing protocol, it = would be layer violating to treat me as anything other than a black box, = such that internal errors and timeouts in my signing setup don=E2=80=99t = propagate upwards to the multi-party protocol. For example, I should be able to try to 2FA sign, and if that fails go = fetch my backup key and sign with that. But because it=E2=80=99s my = infrequently used backup key, it might be placed deeper in the key tree = and therefore signatures using it are larger. All the other signers need = care is that slot #3 in the witness is where my Merkle proof goes. They = shouldn=E2=80=99t have to restart and resign because my proof was a = little larger than anticipated =E2=80=94 and maybe they can=E2=80=99t = resign because double-spend protections!