MIME-Version: 1.0
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>
In-Reply-To: <D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org>
From: Felix Weis <mail@felixweis.com>
Date: Sun, 01 Oct 2017 11:22:30 +0000
Message-ID: <CAMnWzuULmHsiC8CSHZRHS7nJAgHBVMCUfSR-0Si31YSQFeGfbQ@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary="001a113c3cdae44ad1055a7a791b"
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
Precedence: list

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

Just a simple suggestion since the signature format is changed. Can this be
designed so that possible future hard forks can simply change 1 constant in
the code and turn on cross chain replay protection?

On Sun, Oct 1, 2017 at 1:05 PM Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Clean stack should be eliminated for other possible future uses, the most
> obvious of which is recursive tail-call for general computation capabilit=
y.
> I=E2=80=99m not arguing for that at this time, just arguing that we shoul=
dn=E2=80=99t
> prematurely cut off an easy implementation of such should we want to. Cle=
an
> stack must still exist as policy for future soft-fork safety, but being a
> consensus requirement was only to avoid witness malleability, which
> committing to the size of the witness also accomplishes.
>
> Committing to the number of witness elements is fully sufficient, and
> using the number of elements avoids problems of not knowing the actual si=
ze
> in bytes at the time of signing, e.g. because the witness contains a merk=
le
> proof generated by another party from an unbalanced tree, and unbalanced
> trees are expected to be common (so that elements can be placed higher in
> the tree in accordance with their higher expected probability of usage).
> Other future extensions might also have variable-length proofs.
>
> > On Sep 30, 2017, at 7:47 PM, Luke Dashjr <luke@dashjr.org> wrote:
> >
> > Should it perhaps commit to the length of the serialised witness data
> instead
> > or additionally? Now that signatures are no longer variable-length,
> that'd be
> > possible...
> >
> > As far as tail-call needs are concerned, CLEANSTACK wouldn't have been
> checked
> > until AFTER the tail-call in the first draft. But I suppose eliminating
> it for
> > other possible future purposes is still useful.
> >
> > Luke
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Just a simple suggestion since the signature format is cha=
nged. Can this be designed so that possible future hard forks can simply ch=
ange 1 constant in the code and turn on=C2=A0cross chain=C2=A0replay protec=
tion?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, Oct 1, 2=
017 at 1:05 PM Mark Friedenbach via bitcoin-dev &lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Clean stack should be e=
liminated for other possible future uses, the most obvious of which is recu=
rsive tail-call for general computation capability. I=E2=80=99m not arguing=
 for that at this time, just arguing that we shouldn=E2=80=99t prematurely =
cut off an easy implementation of such should we want to. Clean stack must =
still exist as policy for future soft-fork safety, but being a consensus re=
quirement was only to avoid witness malleability, which committing to the s=
ize of the witness also accomplishes.<br>
<br>
Committing to the number of witness elements is fully sufficient, and using=
 the number of elements avoids problems of not knowing the actual size in b=
ytes at the time of signing, e.g. because the witness contains a merkle pro=
of generated by another party from an unbalanced tree, and unbalanced trees=
 are expected to be common (so that elements can be placed higher in the tr=
ee in accordance with their higher expected probability of usage). Other fu=
ture extensions might also have variable-length proofs.<br>
<br>
&gt; On Sep 30, 2017, at 7:47 PM, Luke Dashjr &lt;<a href=3D"mailto:luke@da=
shjr.org" target=3D"_blank">luke@dashjr.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Should it perhaps commit to the length of the serialised witness data =
instead<br>
&gt; or additionally? Now that signatures are no longer variable-length, th=
at&#39;d be<br>
&gt; possible...<br>
&gt;<br>
&gt; As far as tail-call needs are concerned, CLEANSTACK wouldn&#39;t have =
been checked<br>
&gt; until AFTER the tail-call in the first draft. But I suppose eliminatin=
g it for<br>
&gt; other possible future purposes is still useful.<br>
&gt;<br>
&gt; Luke<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--001a113c3cdae44ad1055a7a791b--