From: Mark Friedenbach <mark@friedenbach•org>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
Date: Sat, 30 Sep 2017 22:04:32 -0700 [thread overview]
Message-ID: <D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org> (raw)
In-Reply-To: <201710010247.42180.luke@dashjr.org>
Clean stack should be eliminated for other possible future uses, the most obvious of which is recursive tail-call for general computation capability. I’m not arguing for that at this time, just arguing that we shouldn’t 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:
>
> 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
next prev parent reply other threads:[~2017-10-01 5:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-01 1:13 Luke Dashjr
2017-10-01 2:23 ` Mark Friedenbach
2017-10-01 2:47 ` Luke Dashjr
2017-10-01 5:04 ` Mark Friedenbach [this message]
2017-10-01 11:22 ` Felix Weis
2017-10-01 17:36 ` Luke Dashjr
2017-10-01 19:05 ` Russell O'Connor
2017-10-01 19:27 ` Mark Friedenbach
2017-10-01 19:41 ` Russell O'Connor
2017-10-01 20:39 ` Mark Friedenbach
2017-10-01 20:43 ` Luke Dashjr
2017-10-02 20:38 ` Russell O'Connor
2017-10-01 18:34 ` Mark Friedenbach
2017-10-01 21:32 ` Johnson Lau
2017-10-02 0:35 ` Mark Friedenbach
2017-10-02 2:56 ` Luke Dashjr
2017-10-02 9:09 ` Sjors Provoost
2017-10-02 0:45 ` Luke Dashjr
2017-10-05 20:33 ` Mark Friedenbach
2017-10-05 21:28 ` Russell O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org \
--to=mark@friedenbach$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox