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
>