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 7C9EF3EE for ; Sun, 1 Oct 2017 05:04:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com [209.85.192.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9E914D3 for ; Sun, 1 Oct 2017 05:04:34 +0000 (UTC) Received: by mail-pf0-f178.google.com with SMTP id u12so1523486pfl.4 for ; Sat, 30 Sep 2017 22:04:34 -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=/IJPuZiQ97RoWqlxY4SJlMVaEA1eto8fEuqMNO7Hn/g=; b=MEEn9i/sPQ1JkxyI0H7hw+uZXnRAUq4uHNzCYKcs0EPAEPGALj7BPzV38L9ZDLqB+0 qFKhZ+LjktH2uZ79nhishaxrQaTzNTNlvyfGx6Pl/KwD6e/cRH0I+BmFDpttGtaqXvMQ lcYAxX6jkLiOiJiUOFSpzgXq2VzRV6NtA+jUuV2bA52aEDlqCJt16TRvtk5O4NauFt8y oQKqmLYx6QMhDBUH32QTqSTVc9Yp1h2VExBjqSwJlskohydt6mquKfFeTy66ELdQtwnn +ydkT6llAhGpwLNybBUnWwIM36j1XaMlCgGpaFry/kHiosjIhD6qXQxeHjTAmZOWlJYj oqDA== 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=/IJPuZiQ97RoWqlxY4SJlMVaEA1eto8fEuqMNO7Hn/g=; b=AlEWaiA5pp0uiCK/Erx1Mjs8HcfkCL5vxCAXjyIvw94XMKdOO9re3rmjJUFmKVc257 6Dt5Nf9B365I+8XP1RIiKpaCUYyEASxQIPyka7TXkdGOfQ0GSZKhfQKvEKOj/gEJhHbH sIjLhFT11DlUAfyPojiNxpBSbxYH9NluISXe+YfMlC941e9jMS9qSPGi5YWOj1Dou/X7 WVU15hIKy/cCrYOH9H4GKByWrPkl+FoDlrUvH4DARO09RffcZarxHk5F8jBOBGS/5JgT RV0U4r1qGE0mSpuzEXVv9mm4mNwsNcXgSIN7N3z9p9uEtg8PLN8MTZCEjGKqIjRdLQw3 4LFw== X-Gm-Message-State: AHPjjUhKhFR1ceq9UIqbmjz2vhetao9CVLdUI+ozNuR4QGUMJp4ftoxu 4qzud8yEQU4Mrxw9r6GW97xLO8KkX4A= X-Google-Smtp-Source: AOwi7QBykGOm53PevLane81w4WbD/VXu21mr2mnkJeK2ZiLdg4mpTgE3O7nrSbQCKNzz8efJw/dcPw== X-Received: by 10.99.127.92 with SMTP id p28mr9786971pgn.316.1506834274100; Sat, 30 Sep 2017 22:04:34 -0700 (PDT) Received: from ?IPv6:2601:646:8080:1291:99eb:536:2ab0:7fc6? ([2601:646:8080:1291:99eb:536:2ab0:7fc6]) by smtp.gmail.com with ESMTPSA id q28sm12180758pfj.77.2017.09.30.22.04.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Sep 2017 22:04:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Friedenbach In-Reply-To: <201710010247.42180.luke@dashjr.org> Date: Sat, 30 Sep 2017 22:04:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201710010113.30518.luke@dashjr.org> <5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org> <201710010247.42180.luke@dashjr.org> To: Luke Dashjr X-Mailer: Apple Mail (2.3273) 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 05:04:37 -0000 Clean stack should be eliminated for other possible future uses, the = most obvious of which is recursive 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 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 = size in bytes at the time of signing, e.g. because the witness contains = a merkle 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: >=20 > Should it perhaps commit to the length of the serialised witness data = instead=20 > or additionally? Now that signatures are no longer variable-length, = that'd be=20 > possible... >=20 > As far as tail-call needs are concerned, CLEANSTACK wouldn't have been = checked=20 > until AFTER the tail-call in the first draft. But I suppose = eliminating it for=20 > other possible future purposes is still useful. >=20 > Luke