📅 Original date posted:2015-11-01
📝 Original message:My answer is simply "No", you don't have to maintain backward
compatibility for non-standard tx.
The same question applies to P2SH. Before the deployment of BIP16, one
could have created a time-locked tx with one of the output was in the
form of HASH160 <hash> EQUAL. The <hash>, however, is not a hash of a
valid serialized script, so the output is now permanently frozen.
It also applies to all the OP codes disabled by Satoshi: one could have
created a time-locked tx with those now disabled OP codes.
Same for BIP65 with the use of OP_NOP2. Following your logic, we can't
make any softfork related to the script system.
I think it is very important to make it clear that non-standard txs and
non-standard scripts may become invalid in the future
Gavin Andresen via bitcoin-dev 於 2015-10-28 10:06 寫到:
> I'm hoping this fits under the moderation rule of "short-term changes
> to the Bitcoin protcol" (I'm not exactly clear on what is meant by
> "short-term"; it would be lovely if the moderators would start a
> thread on bitcoin-discuss to clarify that):
>
> Should it be a requirement that ANY one-megabyte transaction that is
> valid
> under the existing rules also be valid under new rules?
>
> Pro: There could be expensive-to-validate transactions created and
> given a
> lockTime in the future stored somewhere safe. Their owners may have no
> other way of spending the funds (they might have thrown away the
> private
> keys), and changing validation rules to be more strict so that those
> transactions are invalid would be an unacceptable confiscation of
> funds.
>
> Con: It is extremely unlikely there are any such large, timelocked
> transactions, because the Core code has had a clear policy for years
> that
> 100,000-byte transactions are "standard" and are relayed and
> mined, and
> larger transactions are not. The requirement should be relaxed so that
> only
> valid 100,000-byte transaction under old consensus rules must be valid
> under new consensus rules (larger transactions may or may not be
> valid).
>
> I had to wrestle with that question when I implemented BIP101/Bitcoin
> XT
> when deciding on a limit for signature hashing (and decided the right
> answer was to support any "non-attack"1MB transaction; see
> https://bitcoincore.org/~gavin/ValidationSanity.pdf [1] for more
> details).
>
> --
>
> --
> Gavin Andresen
>
>
> Links:
> ------
> [1] https://bitcoincore.org/~gavin/ValidationSanity.pdf
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 17:44:00
in reply to nevent1q…gfwg
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 17:44:00Event JSON
{
"id": "04b369e34d2d8c35706130148f6c7be863c5be65f6ccc3114527a057bbd2877a",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686159840,
"kind": 1,
"tags": [
[
"e",
"6fa3af2048f82399a81c9ef5aa9a6d88ff6b14b545801828e83f0dab2f1294d8",
"",
"root"
],
[
"e",
"66b729958fa8752f4050e11d682c340d25e0eef4436830ec1f0a04340cb0ce57",
"",
"reply"
],
[
"p",
"b2b39b6f2c86908d3da9f500193abd5757b21cac328f838800a48c4d557c10dd"
]
],
"content": "📅 Original date posted:2015-11-01\n📝 Original message:My answer is simply \"No\", you don't have to maintain backward \ncompatibility for non-standard tx.\n\nThe same question applies to P2SH. Before the deployment of BIP16, one \ncould have created a time-locked tx with one of the output was in the \nform of HASH160 \u003chash\u003e EQUAL. The \u003chash\u003e, however, is not a hash of a \nvalid serialized script, so the output is now permanently frozen.\n\nIt also applies to all the OP codes disabled by Satoshi: one could have \ncreated a time-locked tx with those now disabled OP codes.\n\nSame for BIP65 with the use of OP_NOP2. Following your logic, we can't \nmake any softfork related to the script system.\n\nI think it is very important to make it clear that non-standard txs and \nnon-standard scripts may become invalid in the future\n\nGavin Andresen via bitcoin-dev 於 2015-10-28 10:06 寫到:\n\u003e I'm hoping this fits under the moderation rule of \"short-term changes\n\u003e to the Bitcoin protcol\" (I'm not exactly clear on what is meant by\n\u003e \"short-term\"; it would be lovely if the moderators would start a\n\u003e thread on bitcoin-discuss to clarify that):\n\u003e \n\u003e Should it be a requirement that ANY one-megabyte transaction that is\n\u003e valid\n\u003e under the existing rules also be valid under new rules?\n\u003e \n\u003e Pro: There could be expensive-to-validate transactions created and\n\u003e given a\n\u003e lockTime in the future stored somewhere safe. Their owners may have no\n\u003e other way of spending the funds (they might have thrown away the\n\u003e private\n\u003e keys), and changing validation rules to be more strict so that those\n\u003e transactions are invalid would be an unacceptable confiscation of\n\u003e funds.\n\u003e \n\u003e Con: It is extremely unlikely there are any such large, timelocked\n\u003e transactions, because the Core code has had a clear policy for years\n\u003e that\n\u003e 100,000-byte transactions are \u0026quot;standard\u0026quot; and are relayed and\n\u003e mined, and\n\u003e larger transactions are not. The requirement should be relaxed so that\n\u003e only\n\u003e valid 100,000-byte transaction under old consensus rules must be valid\n\u003e under new consensus rules (larger transactions may or may not be\n\u003e valid).\n\u003e \n\u003e I had to wrestle with that question when I implemented BIP101/Bitcoin\n\u003e XT\n\u003e when deciding on a limit for signature hashing (and decided the right\n\u003e answer was to support any \"non-attack\"1MB transaction; see\n\u003e https://bitcoincore.org/~gavin/ValidationSanity.pdf [1] for more\n\u003e details).\n\u003e \n\u003e --\n\u003e \n\u003e --\n\u003e Gavin Andresen\n\u003e \n\u003e \n\u003e Links:\n\u003e ------\n\u003e [1] https://bitcoincore.org/~gavin/ValidationSanity.pdf\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",
"sig": "89ce102079fbf4a2d5aa6b6f98cc4bb4e13df954cf3ed0fb5b7b6fd6154f2d0929286a522f695615166adb074350e4023e2eaf117bce33d734962eefd4eae375"
}