{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-11-01\n📝 Original message:On Sun, Nov 1, 2015 at 5:28 PM, jl2012 via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I think it is very important to make it clear that non-standard txs and\n\u003e non-standard scripts may become invalid in the future\n\u003e\n\nThere can be unavoidable situations which cause locked coins become\nunspendable.\n\nIn an ideal world, soft forks that make UTXOs unspendable should increase\nthe tx version number.  BIP-13 should have done that.  That would make the\nchange opt-in.\n\nThe disabled opcodes like OP_CAT were a DOS/network security change.\n\nInvalidating locked coins is another reason that they shouldn't have been\ndisabled permanently.\n\nIt would have been better to disable them for six months, so at least\npeople can get their coins back after that.  Inherently, protecting the\nnetwork required some limitations being added so that nodes couldn't be\ncrashed.\n\nFor guidelines\n\n* Transaction version numbers will be increased, if possible\n* Transactions with unknown/large version numbers are unsafe to use with\nlocktime\n* Reasonable notice is given that the change is being contemplated\n* Non-opt-in changes will only be to protect the integrity of the network\n\nLocked transaction that can be validated without excessive load on the\nnetwork should be safe to use, even if non-standard.\n\nAn OP_CAT script that requires TBs of RAM to validate crosses the threshold\nof reasonableness.\n\n\n\n\u003e\n\u003e Gavin Andresen via bitcoin-dev 於 2015-10-28 10:06 寫到:\n\u003e\n\u003e\u003e I'm hoping this fits under the moderation rule of \"short-term changes\n\u003e\u003e to the Bitcoin protcol\" (I'm not exactly clear on what is meant by\n\u003e\u003e \"short-term\"; it would be lovely if the moderators would start a\n\u003e\u003e thread on bitcoin-discuss to clarify that):\n\u003e\u003e\n\u003e\u003e Should it be a requirement that ANY one-megabyte transaction that is\n\u003e\u003e valid\n\u003e\u003e under the existing rules also be valid under new rules?\n\u003e\u003e\n\u003e\u003e Pro:  There could be expensive-to-validate transactions created and\n\u003e\u003e given a\n\u003e\u003e lockTime in the future stored somewhere safe. Their owners may have no\n\u003e\u003e other way of spending the funds (they might have thrown away the\n\u003e\u003e private\n\u003e\u003e keys), and changing validation rules to be more strict so that those\n\u003e\u003e transactions are invalid would be an unacceptable confiscation of\n\u003e\u003e funds.\n\u003e\u003e\n\u003e\u003e Con: It is extremely unlikely there are any such large, timelocked\n\u003e\u003e transactions, because the Core code has had a clear policy for years\n\u003e\u003e that\n\u003e\u003e 100,000-byte transactions are \u0026quot;standard\u0026quot; and are relayed and\n\u003e\u003e mined, and\n\u003e\u003e larger transactions are not. The requirement should be relaxed so that\n\u003e\u003e only\n\u003e\u003e valid 100,000-byte transaction under old consensus rules must be valid\n\u003e\u003e under new consensus rules (larger transactions may or may not be\n\u003e\u003e valid).\n\u003e\u003e\n\u003e\u003e I had to wrestle with that question when I implemented BIP101/Bitcoin\n\u003e\u003e XT\n\u003e\u003e when deciding on a limit for signature hashing (and decided the right\n\u003e\u003e answer was to support any \"non-attack\"1MB transaction; see\n\u003e\u003e https://bitcoincore.org/~gavin/ValidationSanity.pdf [1] for more\n\u003e\u003e details).\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e Gavin Andresen\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Links:\n\u003e\u003e ------\n\u003e\u003e [1] https://bitcoincore.org/~gavin/ValidationSanity.pdf\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\n\u003e\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151101/ba76df82/attachment.html\u003e"}