A pinning attack is a type of censorship in which the attacker takes advantage of mempool policy to prevent a transaction from confirming. Mempool validation uses imperfect heuristics to protect against DoS (and other reasons), so if you don't have full control over your transaction (sharing inputs with counterparty or signing ANYONECANPAY), there's almost always opportunity for pinning. Our job in writing mempool code is to protect the node operator from DoS or incentive-incompatible transactions; protecting transaction senders from pinning attacks (especially if easily avoidable) is important but secondary.
The attack might (1) prevent your transaction from entering the mempool or (2) prevent your mempool transaction from being mined.
Again, all pinning attacks arise from your transaction not being entirely controlled by you. You might distinguish pinning attacks based on whether (1) the attacker mutates/modifies your transaction or (2) doesn't. Maybe they just attach descendants or publish their own transaction.
Same txid different witness, Witness Replacement and PR #19645
LN Penalty Commitment Transactions cannot replace each other. Described in part 4 of This Talk
Transactions signed ANYONECANPAY | SINGLE or ANYONECANPAY |NONE can always be pinned, since attackers can change the transaction to add inputs and outputs
Transactions signed with ANYONECANPAY | ALL can still be pinned: PR #23121. More specific Revault example:
- Improve the heuristics used to narrow the window of pinning opportunity
- Make RBF better
- Implement the ability to reason about multiple transactions together, aka Package Mempool Accept
Almost every pinning attack is mitigated if you can put a good feerate on the transaction.
- Bitcoin Development Podcast episode 3
- T-Bast's Lightning Pinning Attacks
- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html