Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\))
From: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <CAMZUoK=1fZUeKkA6V2pFwqj-Fd-YnZD4sffP9yc0Y7vv8-XvhQ@mail.gmail.com>
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>
	<D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org>
	<CAMZUoK=1fZUeKkA6V2pFwqj-Fd-YnZD4sffP9yc0Y7vv8-XvhQ@mail.gmail.com>
To: Russell O'Connor <roconnor@blockstream.io>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
Precedence: list

> On Oct 1, 2017, at 12:05 PM, Russell O'Connor =
<roconnor@blockstream.io> 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!