summaryrefslogtreecommitdiff
path: root/fa/4385d7a0fb3bbcb59a35ce0970c922c7c4d620
blob: 4138fe7eaadb1d5e94e7038d9465cb5ed96eb154 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7C9EF3EE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  1 Oct 2017 05:04:34 +0000 (UTC)
Received: by mail-pf0-f178.google.com with SMTP id u12so1523486pfl.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <mark@friedenbach.org>
In-Reply-To: <201710010247.42180.luke@dashjr.org>
Date: Sat, 30 Sep 2017 22:04:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org>
References: <201710010113.30518.luke@dashjr.org>
	<5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org>
	<201710010247.42180.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>
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 <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: 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 <luke@dashjr.org> 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