public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeremy Rubin <jeremy.l.rubin.travel@gmail•com>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] For discussion: limit transaction size to mitigate CVE-2013-2292
Date: Wed, 22 Jul 2015 02:18:00 +0800	[thread overview]
Message-ID: <CAJ+8mEPt1xe6dxx1+jm=sndArHXCbjEfYKNVhJw=OO1aG=CBJQ@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T2ZX3iuCN4g6Yh0k8R7Ad0yx-yfx1f2XhCEPtz-vt2xsw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]

I think it's not a horrible idea to just add a field into the transaction
metadata for N_SIG_OPS in the script_sig

It is much simpler in implementation if the concern is complexity (once a
transaction goes above N_SIG_OPS it could be considered invalid, number
computed must be equal). It wouldn't even need to be stored permanently as
it can be pruned easily and recomputed later (hashes would protect against
buggy complicated sig counting code).

Furthermore, it would differentiate a branch with different counts well.



On Wed, Jul 22, 2015 at 2:09 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell <gmaxwell@gmail•com>
> wrote:
>
>> On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev
>> <bitcoin-dev@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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3397 bytes --]

  reply	other threads:[~2015-07-21 18:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-20 19:10 Gavin Andresen
2015-07-20 19:43 ` Tier Nolan
2015-07-20 20:30   ` Gavin Andresen
2015-07-20 19:58 ` Ross Nicoll
2015-07-20 20:55 ` Gregory Maxwell
2015-07-21 18:09   ` Gavin Andresen
2015-07-21 18:18     ` Jeremy Rubin [this message]
2015-07-23 15:41   ` Gavin Andresen
2015-07-24 20:59     ` Gavin Andresen
2015-07-25  0:47       ` odinn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ+8mEPt1xe6dxx1+jm=sndArHXCbjEfYKNVhJw=OO1aG=CBJQ@mail.gmail.com' \
    --to=jeremy.l.rubin.travel@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=gavinandresen@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox