Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 33D0996F for ; Sun, 1 Oct 2017 11:22:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0C376CE for ; Sun, 1 Oct 2017 11:22:42 +0000 (UTC) Received: by mail-lf0-f49.google.com with SMTP id 23so3324975lfs.10 for ; Sun, 01 Oct 2017 04:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=felixweis.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=K1+QkwqR8yc3xgewVM7sYsZ7zdkY5kS/7nLiPyuimrw=; b=jR1hBorbK6lBhF/uKDD2f29eYKTGJgfMw2383Q7Xul86179JIYNOggvrMTrY8UgYnX 5up4bmM9tTbylPaWfc2DLmKeNme1RI8LIzfcq7BNzHa934LimhBZqsO4AFvAFNfwP/Ob GgaAZsXW8NNnvx3hRtvyZU8Y5y2ZzjwTwwOKoCpW1x38MvVJcyBETDPDvrqVt52ONkQD yavOATBYfVna+nHXfm5Ej/5h9nQarvd6biBvSWGdt16d6U3G3qyen3ETXnOvmZJw5inV 3oQ8/qyGNqvIxMIKNZ770Q2i3r1AKzntKSSSmfwxDItiDbrSrgOQTKK3gl8leh1Ua3HT jNtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=K1+QkwqR8yc3xgewVM7sYsZ7zdkY5kS/7nLiPyuimrw=; b=KmND+5yXZ4vbCvJi5HcXFWBDUyOk64Hr8yfiwfLM/r3HQ0PgGY02wkOD+ufvK2GHJA PSRTDoU7Pe5ZfY3VucpRyiLPimE8nigBGdbM4devYOJG0cMS9ZDK8Zqew2ub6Tki18ZD lX6Zh4gKFny1D9wlegRytofMYF9PIs6borZARd2Q50auy7z92qf3gzxtzr3CVNTqSu2r kYYobyf7MnGj6GdOQtXWm1TPg1Cdjxar3Fis0hIDYA4oQZ7sZB5IRH59u+bLuyqD1t7G WSDV1HILf2dew/EUB0DRlMgUT9sPH9p7PwbDhnh7o9eZGDlXkyUzTHbKc/kXcKAM5CEf cyQw== X-Gm-Message-State: AMCzsaVErxleYzCGMBDqsml0g+OEa0pv9VNAQvZ6vnAfK0cUTefzhUkN dk3hDlEknpsuo2UyEBdnlxho5eXFCBg42OjXavWNGA== X-Google-Smtp-Source: AOwi7QAPId0YG/AAjEaVkRiCf9g5Y9+DP0FQ6Jj4HJqLXkuQgO9NbQgAVHeLrg3xmistXmX8XzqUGmyKvzdU+eWjet4= X-Received: by 10.25.115.89 with SMTP id o86mr2865167lfc.164.1506856961058; Sun, 01 Oct 2017 04:22:41 -0700 (PDT) MIME-Version: 1.0 References: <201710010113.30518.luke@dashjr.org> <5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org> <201710010247.42180.luke@dashjr.org> In-Reply-To: From: Felix Weis Date: Sun, 01 Oct 2017 11:22:30 +0000 Message-ID: To: Mark Friedenbach , Bitcoin Protocol Discussion , Luke Dashjr Content-Type: multipart/alternative; boundary="001a113c3cdae44ad1055a7a791b" X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 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 11:22:44 -0000 --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 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
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?

On Sun, Oct 1, 2= 017 at 1:05 PM Mark Friedenbach via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:
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.

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.

> 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, th= at'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 eliminatin= g it for
> other possible future purposes is still useful.
>
> Luke

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--001a113c3cdae44ad1055a7a791b--