š
Original date posted:2015-07-21
š Original message:On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Mitigate a potential CPU exhaustion denial-of-service attack by limiting
> > the maximum size of a transaction included in a block.
>
> This seems like a fairly indirect approach. The resource being watched
> for is not the size (otherwise two transactions for 200k would be
> strictly worse than one 200k transactions) but the potential of N^2
> costs related to repeated hashing in checksig; which this ignores.
>
Yes. The tradeoff is implementation complexity: it is trivial to check
transaction size,
not as trivial to count signature operations, because
number-of-bytes-in-transaction
doesn't require any context.
But I would REALLY hate myself if in ten years a future version of me was
struggling to
get consensus to move away from some stupid 100,000 byte transaction size
limit
I imposed to mitigate a potential DoS attack.
So I agree, a limit on sigops is the right way to go. And if that is being
changed,
might as well accurately count exactly how many sigops a transaction
actually
requires to be validated...
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150721/258a0bc6/attachment.html>;
Gavin Andresen [ARCHIVE] /
npub1s4ā¦d44kw
2023-06-07 15:42:40
in reply to nevent1qā¦cf89
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwPublished at
2023-06-07 15:42:40Event JSON
{
"id": "b206192859072981742a29764f085cdfb5ccd0cbc9346197d174e4c2095c08dd",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686152560,
"kind": 1,
"tags": [
[
"e",
"4db225e616a06087530c4b30cfa43f47ac26331621975d63e97abbdb75e7e0fa",
"",
"root"
],
[
"e",
"7f3ad04463a7a48c843d9adea5c2843103d7c25fce0758a2a4f78083138234e3",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "š
Original date posted:2015-07-21\nš Original message:On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\n\u003e On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e Mitigate a potential CPU exhaustion denial-of-service attack by limiting\n\u003e \u003e the maximum size of a transaction included in a block.\n\u003e\n\u003e This seems like a fairly indirect approach. The resource being watched\n\u003e for is not the size (otherwise two transactions for 200k would be\n\u003e strictly worse than one 200k transactions) but the potential of N^2\n\u003e costs related to repeated hashing in checksig; which this ignores.\n\u003e\n\nYes. The tradeoff is implementation complexity: it is trivial to check\ntransaction size,\nnot as trivial to count signature operations, because\nnumber-of-bytes-in-transaction\ndoesn't require any context.\n\nBut I would REALLY hate myself if in ten years a future version of me was\nstruggling to\nget consensus to move away from some stupid 100,000 byte transaction size\nlimit\nI imposed to mitigate a potential DoS attack.\n\nSo I agree, a limit on sigops is the right way to go. And if that is being\nchanged,\nmight as well accurately count exactly how many sigops a transaction\nactually\nrequires to be validated...\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150721/258a0bc6/attachment.html\u003e",
"sig": "b1c339e6cc0423961e18c62b461644d546a34a8582741c7d58077aa599dca201b50fa67fa83e2ff9e70e2e280137931e62f8e20637ef3cfb784fdee29b3a1e63"
}