rich1.0npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nhttps://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nnjumphttps://nostr.ae📅 Original date posted:2017-10-01 📝 Original message:BIP 115 provides fork-independent opt-in replay protection, which can be used in combination with the new signature condition scripts in this proposal. Perhaps the code can have a flag for new altcoins to easily make it mandatory (and we can use it on testnet?). Luke On Sunday 01 October 2017 11:22:30 AM Felix Weis wrote: > 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 at 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 at 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 at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev