path: root/78/c1d3148b2a74a7e41ea9b863734d63e0b90938

Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DDAD9B4B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  2 Oct 2017 20:39:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com
	[209.85.213.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ABAF44BD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  2 Oct 2017 20:39:10 +0000 (UTC)
Received: by mail-vk0-f45.google.com with SMTP id h63so3546659vka.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 02 Oct 2017 13:39:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=blockstream-io.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=UU5armcHYmqoT50MVJpR4asKpmy7ho7UNoub0RjdyXg=;
	b=kBUfTAx/ezPCWiHp2NURJ8Hdu21lUyeame0nj+ooRzMkz6cqmRX3Jvd3KxEfD/7I7+
	VpBjKHbAy64n1i45AJesaGMv+D7aKELfuVUux8pg8f+cGiNhVdZ7/rzJyqkLmE6LqIXO
	rLazOsyh8jilpjCd0ZH3W0E9s8MvVxa14V9zDvDoURGOS8HitoMevWzKgH4JfaA2P1IJ
	v7tY7hrNwWO3YzNMfeC3tGzor8R6XOhfIcZFXFeIOyoLeNlYBD07fDZhjp8zZjhXQb+f
	O2xtoDk+tyyyzvQf8X6+u9o+QSpWU6zTBf0/I8PIHBSfM9LcquYaEdCjZbJzYKb2bOX6
	5eeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=UU5armcHYmqoT50MVJpR4asKpmy7ho7UNoub0RjdyXg=;
	b=Wd4Kv04xxmXHWNzDDFaNAFa8LIHuYVoSLKE9gNo6CxBaAC2MW5EhLdKhvFg23tROMH
	5GtDbDqUbiimO00toG+JDvfbnF5oUX2B5V9QiXBeVN1moYWRDYUylys5UO4BC9gfYW/y
	/gX/92/40EBNx8wed/YtXWhTf4eo4nCSrVizbYZjfKisMHqDQid24KD/S7jwZ5xgVDmy
	MM0Ih7PsTczTa4VgB2iotnyvl+E2Q4gzLHJ+6Gbfz3NpzVPh84rk0BAVw9lsM/7ZcNzu
	NfWUGy7D9ZXQpPO0BtkdHJFhDZiysGKf9x1tBuJs1zaoK9UMFboH4+KCcf+TmVM4wmQq
	ADZA==
X-Gm-Message-State: AMCzsaX4YBpH0I8bnd9FSrF+AlxTQdAD/dSCoik1mM9ZIlA69wO+P85B
	4/NGp9b7vuOeIBM2Wc77U7dqf/2q/3wGSeBl4KSQiQ==
X-Google-Smtp-Source: AOwi7QAhBqgeuHNyXXTz0mo+jcyqlhHQHHsBRa6l/TTXnaDBb2nf21xt5gbl84nkNtZOmiY9nbaejN9taY8NAMkZIaA=
X-Received: by 10.31.26.3 with SMTP id a3mr3356754vka.43.1506976749675; Mon,
	02 Oct 2017 13:39:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.41.161 with HTTP; Mon, 2 Oct 2017 13:38:49 -0700 (PDT)
In-Reply-To: <BC800737-7B93-41BD-BA87-F25B25F95426@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>
	<460EDF1F-2BFD-4DBE-A921-73469C2EA9B9@friedenbach.org>
	<CAMZUoK=heF1FALyGbi7cpzLiQuhLnsq-5Z2-sTgq5b28sjjeUw@mail.gmail.com>
	<BC800737-7B93-41BD-BA87-F25B25F95426@friedenbach.org>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Mon, 2 Oct 2017 16:38:49 -0400
Message-ID: <CAMZUoKnf5VYYKgKjcq-_vAjbStXnqr3SVZweLHak+XB975JrrQ@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary="001a11425b16d981d9055a965d83"
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HTML_MESSAGE,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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Oct 2017 20:39:12 -0000

--001a11425b16d981d9055a965d83
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 1, 2017 at 4:39 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:

>
> > On Oct 1, 2017, at 12:41 PM, Russell O'Connor <roconnor@blockstream.io>
> wrote:
> >
> > Creating a Bitcoin script that does not allow malleability is difficult
> and requires wasting a lot of bytes to do so, typically when handling
> issues around non-0-or-1 witness values being used with OP_IF, and dealin=
g
> with non-standard-zero values, etc.
>
> Script validation flags of the correct place to do this. We already have
> policy validation flags that check for these things. They were not made
> consensus rules with Segwit v0 mainly due to concern over scope creep in =
an
> already large overhaul, of my memory is correct. Script versions and
> quadratic hashing fixes where the minimum necessary to allow segwit to
> activate safely while still enabling future upgrades that would otherwise
> have been hard forks. We knew that we would be later changing the EC
> signature scheme to be something that supported signature aggregation, an=
d
> that would be more appropriate time to discuss such changes. As we are
> considering to do now (although witness versions means we don=E2=80=99t n=
eed to
> omnibus the script upgrade here either, so a v1 before signature
> aggregation is ready is fine IMHO).
>

Script validation isn't the correct place to do this.  The reason is that
script operations are not aware of whether the stack items they are
processing are witness malleable items or Script computed values.  Let me
take OP_IF as one example.  When OP_IF operates directly on witness data,
it is subject to witness malleability, and therefore one needs to add extra
code around that to prevent witness malleability.  On the other hand, when
OP_IF operates on computed data, it isn't subject to malleability and can
safely process non-zero-or-one values. If OP_IF were restricted to
requiring canonical inputs, then for the cases that OP_IF operates on
computed data, they will need to add extra code to canonicalize their
inputs.  I don't think there is a correct answer here.  That is because I
believe this isn't the correct place to aim to restrict witness
malleability.

OTOH, signatures are a fine place to aim to restrict witness malleability.
In fact, if signatures could securely cover all witness data, I think
everyone here would jump at the opportunity to implement that.  However,
since that isn't known to be possible, we are left with doing the best we
can, which is to have signatures cover weight (or bytes).  This prevents
the worst effects of witness malleability and does so without burdening
Script development.  (This also requires signatures have a fixed size, so
it is understandable that signature-covers-weight wasn't included in Segwit
v0 scripts).


> In any case if there is any general witness malleability due to opcode
> semantics that it=E2=80=99s not fixed by one of our existing policy flags=
, that is
> a bug and I would encourage you to report it.
> > I'll argue that I don't want my counter-party going off and using a ver=
y
> deeply nested key in order to subvert the fee rate we've agreed upon afte=
r
> I've signed my part of the input.  If we are doing multi-party signing of
> inputs we need to communicate anyways to construct the transaction.  I se=
e
> no problem with requiring my counter-party to choose their keys before I
> sign so that I know up front what our fee rate is going to be.  If they
> lose their keys and need a backup, they should have to come back to me to
> resign in order that we can negotiate a new fee rate for the transaction
> and who is going to be covering how much of the fee and on which inputs.
>
> Arguing that every single user should be forced to restart an interactive
> signing session. That=E2=80=99s a very strong statement based on somethin=
g that I
> would say is a preference that depends on circumstances.
>
> What about an optional commitment to witness size in bytes? The value zer=
o
> meaning =E2=80=9CI don=E2=80=99t care.=E2=80=9D I would argue that it sho=
uld be a maximum however,
> and therefor serialized as part of the witness. The serialization of this
> would be very compact (1 plus the difference between actual and maximum,
> with zero meaning not used.)


I would be fine your suggestion above, though I think Luke's suggestion of
having both SIGHASH_WITNESS_SIZE and SIGHASH_WITNESS_DEPTH flag is better
because it is simpler.

Those people worried about restarting interactive signing session in the
unlikely event of parties not knowing what keys they are planning to use
can use just the SIGHASH_WITNESS_DEPTH flag.  Those people worried about
counterparties fiddling with fee rates can use both flags.  The choice
doesn't even need to be made at script commitment time.

--001a11425b16d981d9055a965d83
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Oct 1, 2017 at 4:39 PM, Mark Friedenbach <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
&gt; On Oct 1, 2017, at 12:41 PM, Russell O&#39;Connor &lt;<a href=3D"mailt=
o:roconnor@blockstream.io">roconnor@blockstream.io</a>&gt; wrote:<br>
&gt;<br>
&gt; Creating a Bitcoin script that does not allow malleability is difficul=
t and requires wasting a lot of bytes to do so, typically when handling iss=
ues around non-0-or-1 witness values being used with OP_IF, and dealing wit=
h non-standard-zero values, etc.<br>
<br>
</span>Script validation flags of the correct place to do this. We already =
have policy validation flags that check for these things. They were not mad=
e consensus rules with Segwit v0 mainly due to concern over scope creep in =
an already large overhaul, of my memory is correct. Script versions and qua=
dratic hashing fixes where the minimum necessary to allow segwit to activat=
e safely while still enabling future upgrades that would otherwise have bee=
n hard forks. We knew that we would be later changing the EC signature sche=
me to be something that supported signature aggregation, and that would be =
more appropriate time to discuss such changes. As we are considering to do =
now (although witness versions means we don=E2=80=99t need to omnibus the s=
cript upgrade here either, so a v1 before signature aggregation is ready is=
 fine IMHO).<br></blockquote><div><br></div><div>Script validation isn&#39;=
t the correct place to do this.=C2=A0 The reason is that script operations =
are not aware of whether the stack items they are processing are witness ma=
lleable items or Script computed values.=C2=A0 Let me take OP_IF as one exa=
mple.=C2=A0 When OP_IF operates directly on witness data, it is subject to =
witness malleability, and therefore one needs to add extra code around that=
 to prevent witness malleability.=C2=A0 On the other hand, when OP_IF opera=
tes on computed data, it isn&#39;t subject to malleability and can safely p=
rocess non-zero-or-one values. If OP_IF were restricted to requiring canoni=
cal inputs, then for the cases that OP_IF operates on computed data, they w=
ill need to add extra code to canonicalize their inputs.=C2=A0 I don&#39;t =
think there is a correct answer here.=C2=A0 That is because I believe this =
isn&#39;t the correct place to aim to restrict witness malleability.</div><=
div><br></div><div>OTOH, signatures are a fine place to aim to restrict wit=
ness malleability.=C2=A0 In fact, if signatures could securely cover all wi=
tness data, I think everyone here would jump at the opportunity to implemen=
t that.=C2=A0 However, since that isn&#39;t known to be possible, we are le=
ft with doing the best we can, which is to have signatures cover weight (or=
 bytes).=C2=A0 This prevents the worst effects of witness malleability and =
does so without burdening Script development.=C2=A0 (This also requires sig=
natures have a fixed size, so it is understandable that signature-covers-we=
ight wasn&#39;t included in Segwit v0 scripts).<br></div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
In any case if there is any general witness malleability due to opcode sema=
ntics that it=E2=80=99s not fixed by one of our existing policy flags, that=
 is a bug and I would encourage you to report it.<br>
<span class=3D"">&gt; I&#39;ll argue that I don&#39;t want my counter-party=
 going off and using a very deeply nested key in order to subvert the fee r=
ate we&#39;ve agreed upon after I&#39;ve signed my part of the input.=C2=A0=
 If we are doing multi-party signing of inputs we need to communicate anywa=
ys to construct the transaction.=C2=A0 I see no problem with requiring my c=
ounter-party to choose their keys before I sign so that I know up front wha=
t our fee rate is going to be.=C2=A0 If they lose their keys and need a bac=
kup, they should have to come back to me to resign in order that we can neg=
otiate a new fee rate for the transaction and who is going to be covering h=
ow much of the fee and on which inputs.<br>
<br>
</span>Arguing that every single user should be forced to restart an intera=
ctive signing session. That=E2=80=99s a very strong statement based on some=
thing that I would say is a preference that depends on circumstances.<br>
<br>
What about an optional commitment to witness size in bytes? The value zero =
meaning =E2=80=9CI don=E2=80=99t care.=E2=80=9D I would argue that it shoul=
d be a maximum however, and therefor serialized as part of the witness. The=
 serialization of this would be very compact (1 plus the difference between=
 actual and maximum, with zero meaning not used.)</blockquote><div><br></di=
v><div>I would be fine your suggestion above, though I think Luke&#39;s sug=
gestion of having both SIGHASH_WITNESS_SIZE and SIGHASH_WITNESS_DEPTH flag =
is better because it is simpler.</div><div><br></div><div>Those people worr=
ied about restarting interactive signing session in the unlikely event of p=
arties not knowing what keys they are planning to use can use just the SIGH=
ASH_WITNESS_DEPTH flag.=C2=A0 Those people worried about counterparties fid=
dling with fee rates can use both flags.=C2=A0 The choice doesn&#39;t even =
need to be made at script commitment time.<br></div></div><br></div></div>

--001a11425b16d981d9055a965d83--