OrangeSurf on Nostr: Ideally the standard transactions & DOS transactions sets don't intersect, that's the ...
Ideally the standard transactions & DOS transactions sets don't intersect, that's the intention of most policy rules.
Note: There are some who believe that policy rules should be used to guide the use of the permissionless network. Personally I think this is a folly when there is an economic incentive.
It's relatively simple to ensure that the standard transactions and known DOS transactions don't intersect because they are both well defined. It's harder to know whether the standard transactions and the unknown DOS transactions don't intersect, but we can reason about how we would construct a DOS transaction and then add some policy rules. For example, we can set a limit on the total size of a transaction, which will presumably mean some unknown DOS transactions are now non standard (and our node is protected).
So to be prudent we can add in lots of policy / standardness rules to protect us from unknown DOS transactions, which makes our node less vulnerable. The tradeoff is that in doing this we also make some safe (non DOS) transactions non standard. Arguably this is what happened over the years with bitcoin core, and for good reason.
This is a key point when considering policy rules. Our understanding of what transactions potentially result in a DOS risk is undoubtedly incomplete, and the widespread adoption of current bitcoin core standardness rules might be protecting the network more than we realise. But, having strict policy rules is also making some perfectly safe transactions non standard. For miners, these non standard, known non DOS transactions represent a safe source of extra revenue.
Published at
2025-04-29 09:32:14Event JSON
{
"id": "d92b4a6a3f08e29729ca8196799108e3f6f331124a13417cdfd82fb642b8108c",
"pubkey": "3ddeea527009e25c88d34212f7c9aa36344fbeebd2b69a04ee77ffc3c0ef7371",
"created_at": 1745919134,
"kind": 1,
"tags": [
[
"e",
"6d37a5cb5dbc7bd1e1256d3a15109aff866545b05e2cb697d800a119ec931fce",
"wss://nostr.oxtr.dev",
"root"
],
[
"e",
"cfaa90c8116c64b59c0a0493c4282cb2168232651efd5acf1e8fef7541bbd0ad",
"wss://nostr.oxtr.dev",
"reply"
],
[
"p",
"3ddeea527009e25c88d34212f7c9aa36344fbeebd2b69a04ee77ffc3c0ef7371",
"",
"mention"
]
],
"content": "Ideally the standard transactions \u0026 DOS transactions sets don't intersect, that's the intention of most policy rules. \n\nNote: There are some who believe that policy rules should be used to guide the use of the permissionless network. Personally I think this is a folly when there is an economic incentive.\n\nIt's relatively simple to ensure that the standard transactions and known DOS transactions don't intersect because they are both well defined. It's harder to know whether the standard transactions and the unknown DOS transactions don't intersect, but we can reason about how we would construct a DOS transaction and then add some policy rules. For example, we can set a limit on the total size of a transaction, which will presumably mean some unknown DOS transactions are now non standard (and our node is protected).\n\nSo to be prudent we can add in lots of policy / standardness rules to protect us from unknown DOS transactions, which makes our node less vulnerable. The tradeoff is that in doing this we also make some safe (non DOS) transactions non standard. Arguably this is what happened over the years with bitcoin core, and for good reason.\n\nThis is a key point when considering policy rules. Our understanding of what transactions potentially result in a DOS risk is undoubtedly incomplete, and the widespread adoption of current bitcoin core standardness rules might be protecting the network more than we realise. But, having strict policy rules is also making some perfectly safe transactions non standard. For miners, these non standard, known non DOS transactions represent a safe source of extra revenue.\nhttps://m.primal.net/QhEf.jpg",
"sig": "66f885368584a889a1a3c0b1241ea7e9452ceae1ac314044fcd3d5a4d4ffa510ac50cebf924887e287e840cccb1c73d06f1338357f4af3502e3db8adb612f4bf"
}