š
Original date posted:2015-10-28
š Original message: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 for more details).
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151028/061c73f2/attachment.html>;
Gavin Andresen [ARCHIVE] /
npub1s4ā¦d44kw
2023-06-07 17:43:58
in reply to nevent1qā¦5f54
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwPublished at
2023-06-07 17:43:58Event JSON
{
"id": "ffc862119e91d899038a8b7bfffc76dcaf72a72a6be762aea3e1174255023414",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686159838,
"kind": 1,
"tags": [
[
"e",
"8c871c6b64d65f9f9d5a58566169feb2e979cd8aeb6f2efbd018f282b4443e6a",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "š
Original date posted:2015-10-28\nš Original message:I'm hoping this fits under the moderation rule of \"short-term changes to\nthe Bitcoin protcol\" (I'm not exactly clear on what is meant by\n\"short-term\"; it would be lovely if the moderators would start a thread on\nbitcoin-discuss to clarify that):\n\n\nShould it be a requirement that ANY one-megabyte transaction that is valid\nunder the existing rules also be valid under new rules?\n\nPro: There could be expensive-to-validate transactions created and given a\nlockTime in the future stored somewhere safe. Their owners may have no\nother way of spending the funds (they might have thrown away the private\nkeys), and changing validation rules to be more strict so that those\ntransactions are invalid would be an unacceptable confiscation of funds.\n\nCon: It is extremely unlikely there are any such large, timelocked\ntransactions, because the Core code has had a clear policy for years that\n100,000-byte transactions are \u0026quot;standard\u0026quot; and are relayed and\nmined, and\nlarger transactions are not. The requirement should be relaxed so that only\nvalid 100,000-byte transaction under old consensus rules must be valid\nunder new consensus rules (larger transactions may or may not be valid).\n\n\nI had to wrestle with that question when I implemented BIP101/Bitcoin XT\nwhen deciding on a limit for signature hashing (and decided the right\nanswer was to support any \"non-attack\"1MB transaction; see\nhttps://bitcoincore.org/~gavin/ValidationSanity.pdf for more details).\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151028/061c73f2/attachment.html\u003e",
"sig": "eecd67a36d3b61e1b49b35f2022faa6f82892d2752cef59e1ffe295f0f6370610285e4dc257f83bddb37443bf5f6955a37345a152ae85178bb6c0350f6cf0f21"
}