{"type":"rich","version":"1.0","author_name":"npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","author_url":"https://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-10-01\n📝 Original message:BIP 115 provides fork-independent opt-in replay protection, which can be used \nin combination with the new signature condition scripts in this proposal.\n\nPerhaps the code can have a flag for new altcoins to easily make it mandatory \n(and we can use it on testnet?).\n\nLuke\n\n\nOn Sunday 01 October 2017 11:22:30 AM Felix Weis wrote:\n\u003e Just a simple suggestion since the signature format is changed. Can this be\n\u003e designed so that possible future hard forks can simply change 1 constant in\n\u003e the code and turn on cross chain replay protection?\n\u003e \n\u003e On Sun, Oct 1, 2017 at 1:05 PM Mark Friedenbach via bitcoin-dev \u003c\n\u003e \n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e Clean stack should be eliminated for other possible future uses, the most\n\u003e \u003e obvious of which is recursive tail-call for general computation\n\u003e \u003e capability. I’m not arguing for that at this time, just arguing that we\n\u003e \u003e shouldn’t prematurely cut off an easy implementation of such should we\n\u003e \u003e want to. Clean stack must still exist as policy for future soft-fork\n\u003e \u003e safety, but being a consensus requirement was only to avoid witness\n\u003e \u003e malleability, which committing to the size of the witness also\n\u003e \u003e accomplishes.\n\u003e \u003e \n\u003e \u003e Committing to the number of witness elements is fully sufficient, and\n\u003e \u003e using the number of elements avoids problems of not knowing the actual\n\u003e \u003e size in bytes at the time of signing, e.g. because the witness contains\n\u003e \u003e a merkle proof generated by another party from an unbalanced tree, and\n\u003e \u003e unbalanced trees are expected to be common (so that elements can be\n\u003e \u003e placed higher in the tree in accordance with their higher expected\n\u003e \u003e probability of usage). Other future extensions might also have\n\u003e \u003e variable-length proofs.\n\u003e \u003e \n\u003e \u003e \u003e On Sep 30, 2017, at 7:47 PM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e \u003e \n\u003e \u003e \u003e Should it perhaps commit to the length of the serialised witness data\n\u003e \u003e \n\u003e \u003e instead\n\u003e \u003e \n\u003e \u003e \u003e or additionally? Now that signatures are no longer variable-length,\n\u003e \u003e \n\u003e \u003e that'd be\n\u003e \u003e \n\u003e \u003e \u003e possible...\n\u003e \u003e \u003e \n\u003e \u003e \u003e As far as tail-call needs are concerned, CLEANSTACK wouldn't have been\n\u003e \u003e \n\u003e \u003e checked\n\u003e \u003e \n\u003e \u003e \u003e until AFTER the tail-call in the first draft. But I suppose eliminating\n\u003e \u003e \n\u003e \u003e it for\n\u003e \u003e \n\u003e \u003e \u003e other possible future purposes is still useful.\n\u003e \u003e \u003e \n\u003e \u003e \u003e Luke\n\u003e \u003e \n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}