📅 Original date posted:2011-09-26
🗒️ Summary of this message: A discussion about the acceptance of transactions with "non-standard" sig op count in blocks, and the potential for DoS attacks.
📝 Original message: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.
Luke-Jr [ARCHIVE] /
npub1dt…u7wrs
2023-06-07 04:29:22
in reply to nevent1q…y29u
Author Public Key
npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrsPublished at
2023-06-07 04:29:22Event JSON
{
"id": "e9d6d821c112b5559a53b1daf873b2dd49c89f1aa1c5c50d4d9164b963576f1a",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686104962,
"kind": 1,
"tags": [
[
"e",
"d6d0027f983f7cf39b7bceeaefc2da4fd33248e5b23365297769f7aaa959dad8",
"",
"root"
],
[
"e",
"3f446015d9c2ad99645dd68478e558e26980d14f5d75569ea725b1a16f994da3",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2011-09-26\n🗒️ Summary of this message: A discussion about the acceptance of transactions with \"non-standard\" sig op count in blocks, and the potential for DoS attacks.\n📝 Original message:On Monday, September 26, 2011 5:38:41 PM Gavin Andresen wrote:\n\u003e \u003e The first one I was referring to is a *transaction* with \"non-standard\"\n\u003e \u003e sig op count, which is AFAIK allowed in blocks, just not accepted by the\n\u003e \u003e mainline rules.\n\u003e \n\u003e I sit corrected. The context is:\n\u003e // Checking ECDSA signatures is a CPU bottleneck, so to avoid\n\u003e denial-of-service\n\u003e // attacks disallow transactions with more than one SigOp per 34\n\u003e bytes.\n\u003e // 34 bytes because a TxOut is:\n\u003e // 20-byte address + 8 byte bitcoin amount + 5 bytes of ops + 1\n\u003e byte script length\n\u003e if (GetSigOpCount() \u003e nSize / 34 || nSize \u003c 100)\n\u003e \treturn DoS(10, error(\"AcceptToMemoryPool() : transaction with\n\u003e out-of-bounds SigOpCount\"));\n\u003e \n\u003e I'm having trouble imagining some future world where valid,\n\u003e new-versions-agree-to-relay-transactions have more than one SigOp per\n\u003e 34 bytes; can you give an example?\n\nIt's not future. It's presently allowed in blocks. Which means it's perfectly \nvalid to relay (and also perfectly value to NOT relay or accept). Ergo, \nshouldn't be punished.\n\n\u003e \u003e Maybe the person spending it sees it matured beyond 100 confirmations,\n\u003e \u003e and you only see 99. An attacker could use these things to get nodes to\n\u003e \u003e ban each other.\n\u003e \n\u003e That would imply you're on a blockchain fork of more than 99 blocks\n\u003e with respect to the person spending the transaction, in which case I'd\n\u003e argue you have much bigger problems and it is a good idea for the DoS\n\u003e code to kick in and kick either you or them off the network...\n\nUm, no? It implies you have 99 blocks since the coinbase, and he has 100 and \nwants to spend. In this scenario, it's proper to reject his transaction *until \nyou have the next block*, but it doesn't make sense to punish for it.",
"sig": "e9dc3d0ff6abe5500c7bb6be659be24e604b85bb210477873bfda65735fe48c1eb62f6165e050db0676a2875dda28aa5777327637b665122ada5453c4a5a25e6"
}