From: "Luke-Jr" <luke@dashjr•org>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Newly introduced DoS
Date: Mon, 26 Sep 2011 17:53:23 -0400 [thread overview]
Message-ID: <201109261753.25549.luke@dashjr.org> (raw)
In-Reply-To: <CABsx9T0TN+Nzzjod7xNJk4PNHnWPMWZUVsTHP3Yxq0C_-EgBLQ@mail.gmail.com>
On Monday, September 26, 2011 5:38:41 PM Gavin Andresen wrote:
> > The first one I was referring to is a *transaction* with "non-standard"
> > sig op count, which is AFAIK allowed in blocks, just not accepted by the
> > mainline rules.
>
> I sit corrected. The context is:
> // Checking ECDSA signatures is a CPU bottleneck, so to avoid
> denial-of-service
> // attacks disallow transactions with more than one SigOp per 34
> bytes.
> // 34 bytes because a TxOut is:
> // 20-byte address + 8 byte bitcoin amount + 5 bytes of ops + 1
> byte script length
> if (GetSigOpCount() > nSize / 34 || nSize < 100)
> return DoS(10, error("AcceptToMemoryPool() : transaction with
> out-of-bounds SigOpCount"));
>
> I'm having trouble imagining some future world where valid,
> new-versions-agree-to-relay-transactions have more than one SigOp per
> 34 bytes; can you give an example?
It's not future. It's presently allowed in blocks. Which means it's perfectly
valid to relay (and also perfectly value to NOT relay or accept). Ergo,
shouldn't be punished.
> > Maybe the person spending it sees it matured beyond 100 confirmations,
> > and you only see 99. An attacker could use these things to get nodes to
> > ban each other.
>
> That would imply you're on a blockchain fork of more than 99 blocks
> with respect to the person spending the transaction, in which case I'd
> argue you have much bigger problems and it is a good idea for the DoS
> code to kick in and kick either you or them off the network...
Um, no? It implies you have 99 blocks since the coinbase, and he has 100 and
wants to spend. In this scenario, it's proper to reject his transaction *until
you have the next block*, but it doesn't make sense to punish for it.
next prev parent reply other threads:[~2011-09-26 21:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-26 19:17 Luke-Jr
2011-09-26 20:47 ` Gavin Andresen
2011-09-26 20:55 ` Luke-Jr
2011-09-26 21:38 ` Gavin Andresen
2011-09-26 21:53 ` Luke-Jr [this message]
2011-09-26 22:34 ` theymos
2011-09-27 0:07 ` Gavin Andresen
2011-09-27 20:08 ` Luke-Jr
2011-09-27 20:23 ` Gregory Maxwell
2011-09-27 20:39 ` Gavin Andresen
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=201109261753.25549.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--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