From: Felix Weis <mail@felixweis•com>
To: Mark Friedenbach <mark@friedenbach•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Luke Dashjr <luke@dashjr•org>
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
Date: Sun, 01 Oct 2017 11:22:30 +0000 [thread overview]
Message-ID: <CAMnWzuULmHsiC8CSHZRHS7nJAgHBVMCUfSR-0Si31YSQFeGfbQ@mail.gmail.com> (raw)
In-Reply-To: <D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org>
[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]
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 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2612 bytes --]
next prev parent reply other threads:[~2017-10-01 11:22 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
2017-10-01 11:22 ` Felix Weis [this message]
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=CAMnWzuULmHsiC8CSHZRHS7nJAgHBVMCUfSR-0Si31YSQFeGfbQ@mail.gmail.com \
--to=mail@felixweis$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
--cc=mark@friedenbach$(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