<p>These types of attacks are inherent to the auction model and are not dependent on the technology used. To protect against these, auctions have a minimum bid increase. Other solutions would be (i) a whitelist of known wallets making sure that every participants has at most one wallet, or (ii) bidding fees making DoS attacks expensive.</p>
<p>If you want to run an auction without identity control opened to the general public, minimum bid increases would be the way to go, in my opinion.</p>

CC BY-SA 4.0
2021-09-13T09:39:14.180Z
My point is that those attacks are much easier with eUTXO/Cardano than on Solidity. It is incredibly expensive to "stall" the Ethereum-mainnet for multiple blocks, whereas it is much cheaper to re-generate a single Cardano-UTXO over multiple blocks. So the defense becomes more important because the attack-tresholds are lower.
Mike76
CC BY-SA 4.0
2021-09-13T09:49:42.693Z
Minimum bid increases are doable, but I still find it problematic if you compare it with Ethereum. I strongly believe that there should be a more general solution which increases the cost of conducting DOS attacks. Those attacks will always be theoretically possible, but we need to think about the cost of performing the attacks.
Mike76
CC BY-SA 4.0
2021-09-13T10:52:46.540Z
Many of the people complaining about the UTxO model only think that Ethereum has less problems because they don't understand what happens there behind the scenes. I personally think that the issues of Ethereum are unfixable. The fact that you can write your question above shows how transparent the Cardano model is and how it allows developers to reason about it and think about what could go wrong and what can be done about it. The only way to prevent DoS in open networks is to make them expensive or difficult. UTxO are not more vulnerable than other models.
Jey
CC BY-SA 4.0
2021-09-13T11:51:04.703Z
I am definitely not a chain maximalist since different models have different tradeoffs. I would not claim that Ethereum is better, but I am interested in this particular concurrency-attack.
Mike76
CC BY-SA 4.0
2021-09-13T12:23:00.390Z
One important thing to consider is the 'why'. What does an attacker gain from such an attack? Blocking other people from placing a bid doesn't gain the attacker anything. The attacker will just pay fees each block. So while this is theoretically possible, it's not worth it. At least not in your example.
eddex
CC BY-SA 4.0
2021-09-13T12:28:34.853Z
He would gain by winning the auction when the deadline is reached.
Jey
CC BY-SA 4.0
2021-09-13T13:02:43.233Z
You are right, you would need a pretty valuable NFT to make this attack profitable. Nevertheless, the attack would be much cheaper than a comparable attack on EVM-chains. Moreover, the NFT auction is just one example of the larger problem.
Mike76
CC BY-SA 4.0
2021-09-13T18:38:50.473Z
@Jey This class of attack, contention of a shared resource, is something I believe can only happen on a UTxO chain. So I believe it's not correct to say that "These types of attacks are inherent to the auction model and are not dependent on the technology used." Within a global-state system like the EVM, nearly an entire block could be filled up with bids to a particular contract and it still wouldn't prevent someone else from posting a bid. No whitelist system or bidding fee would be necessary.
Maximillian Laumeister
CC BY-SA 4.0
2021-09-14T08:33:19.683Z
One solution as proposed by Minswap and others are batching bots. Basically you split the bidding process in two steps. First transaction is a b as tch request to add your bid to the contract. Batching bots will compete to collect as many batch requests as possible and construct the actual bidding transaction. Their incentive is that they get a small fee for each processed batch request. Anyone can run auch a bot.
Xiaofei
CC BY-SA 4.0
2021-09-14T09:16:30.663Z
@Xiaofei This resolves the concurrency issue but does not protect agains DoS attacks as a malicious user could monopolise the bottleneck UTxO by continuously batching only his requests. @ Maximilian You have a point here but only if you don't take Ethereum's flaws into account. I think Ethereum trades its concurrency model for the MEV issue which is at least as bad. It is like a rug that is too large to fit into a room. Cardano and Ethereum each pull the rug to fit into a different corner.
Jey
CC BY-SA 4.0
2021-09-15T07:41:57.110Z
@jey multiple batchers will compete to get their transactions on the block. Stake pools have an incentive to append large transactions to the block to increase the reward pool, so they'd prefer the honest batcher's transaction bundle over the other.
Xiaofei
CC BY-SA 4.0
2021-09-15T08:21:44.797Z
@Xiaofei Very good point! I think this is the answer to the question. If stake pools have an incentive to choose the honest batches, the DoS attack problem is solved.
Jey
CC BY-SA 4.0
2021-09-13T09:15:51.057Z
2021-09-13T09:15:51.057Z
Jey
<p>I can think of a different way to structure the contract to avoid this attack.</p>
<p>If you allow all the bidders to lock up their funds at the same time, in separate UTxOs, the auctioneer could just choose which to accept when the deadline has past. This works in Plutus because you can redeem multiple datums in a single transaction, and have the validators check that the other UTxO is being spent, i.e. the <code>PickWinner</code> redemption path for a <code>Auction</code> datum would requires a <code>Bid</code> datum get redeemed as well, and vice-versa.</p>
<p>And say someone wants to update their bid, the <code>Bid</code> datum would have a redeemer of <code>Update</code>, otherwise your funds are locked until after some grace-period has passed.</p>
<p>This might come with some drawbacks, like the opportunity cost of all the losing bids being locked up, but I can think of ways to minimize those pain. In many cases, it seems like a reasonable cost to pay regardless.</p>

CC BY-SA 4.0
2021-09-18T04:14:58.810Z
People are talking about how order-book style DEXs are going to be more popular on Cardano because it fits the UTxO model better than the Ethereum accounts model. It would work similarly to what I just explained, however a DEX has a Many-to-Many market, unlike an auction which is Many-to-One. So a DEX is a little more difficult to architect than an auction.
Mitchell Turner
CC BY-SA 4.0
2021-11-17T00:30:28.303Z
Thanks for your detailed answer. I see several drawbacks with separate UTXOs. Firstly, the need of longer locking periods. Secondly, the highest bider does not automatically win, which might lead to more corruption. Sure, all of this can be solved, but I don‘t know whether all those eUTXO troubles are worth the effort.
Mike76
CC BY-SA 4.0
2021-11-17T00:49:28.333Z
I don't see the eUTxO model as a problem to be solved. I see it as a way to move the complexity of safety to a lower level. There have been billions of dollars lost in Solidity contracts that could have been prevented with the restrictions Plutus has. And those Solidity contracts aren't less complex, Solidity just has a lower barrier to entry to Plutus. Best of all, it gives an dApp developer options.
Mitchell Turner
CC BY-SA 4.0
2021-11-17T21:39:41.300Z
I agree that Solidity has too many bugs right now, but those can be solved. For example, reentrancy bugs can be prevented with compiler-inserted locks, although those locks have some gas-cost-overhead. For Plutus, however, we still need to ask the feasibility question: Is it even feasible to build an atomically composable DeFi-ecosystem with Plutus? I mean not only a DEX, but a composition of complex protocols like flash-loans
Mike76
CC BY-SA 4.0
2021-11-17T21:44:52.467Z
One more sidenote: Just because someone like SundaeSwap has a workaround for the concurrency-problem does not mean that the problem is solved. In contrast, the following "Scooper model" questions the ability of eUTXO to run a truly decentralized DEX without any off-chain-sequencer or sidechain: https://sundaeswap-finance.medium.com/sundaeswap-labs-presents-the-scooper-model-678d6054318d
Mike76
CC BY-SA 4.0
2021-11-17T22:50:22.103Z
"Is it even feasible to build an atomically composable DeFi-ecosystem with Plutus?" Oh. Absolutely. All the smart contracts I've looked at are compositions of multiple scripts. Plutus actually is great for composition.
Mitchell Turner
CC BY-SA 4.0
2021-11-17T22:58:26.563Z
I'm familiar with SundaeSwap's proposed architecture. I hope it meets their needs. From a first principles perspective I don't get this allergy to "off-chain-sequencer or sidechain". Ethereum is expensive, so they're looking for layer 2 solutions. I'm excited for those. I'm excited for Cardano to have them too. Luckily the Cardano devs took the usefulness of layer 2, sidechannels, and side chains into account when designing the system. Sounds like we're getting Hydra in the Spring. That's pretty soon. I know there is an arms race going on within DeFi, but I'm hoping for sustainable solutions.
Mitchell Turner
CC BY-SA 4.0
2021-11-18T21:44:33.737Z
I agree that layer 2 solutions are necessary, however this should not come at the cost of increased centralization. If SundaeSwap is forced to run a semi-centralized sequencer because of eUTXO-limitations, then this is a cause for concern. Remember that SundaeSwap's sequencer is not even a layer 2 solution, instead it is a traditional webservice that works around their concurrency problems.
Mike76
CC BY-SA 4.0
2021-11-18T22:02:15.580Z
Yeah. For sure, there are trade-offs. The blockchain is an awesome tool, but just because we have it doesn't mean that everything needs be completely decentralized to achieve a useful/compelling product. On the other hand, SundaeSwap's model might fail due to too much centralization/bad game theory, and then we can learn from it. Still lots to learn.
Mitchell Turner
CC BY-SA 4.0
2021-11-18T22:10:02.010Z
In my view, a good layer 2 solution should provide not only decentralization, but also the capability of running a smart contract forever, without any monitoring or additional infrastructure. For example, If I deploy a smart contract on a layer 2 solution, then I don't want to run my own sequencing-services, and neither do I want to incentivize other actors to run sequencing-services for me. Of course there might be solutions for decentralized sequencing, but I wonder what research the Cardano-team has done during the last 5 years if they have not even thought about basic eUTXO-sequencing.
Mike76
CC BY-SA 4.0
2021-09-18T04:07:44.400Z
2021-09-18T04:07:44.400Z
Mitchell Turner
<blockquote>
<p>How would you implement a Plutus-NFT-auction that defends against
economic DOS attacks?</p>
</blockquote>
<p>My approach is a little bit complex, since it involves thinking about the problem in a very different way, so sorry for that.</p>
<p>Instead of having a unique UTxO to handle bids, you could create an &quot;account&quot; script. So each user that want's to be part of an auction would need to create an &quot;account&quot;, sending the bid value (e.g. 100 ADA) or the auction value (e.g. random NFT) to this account address (creating a new UTxO).</p>
<p>The datum would also be important, since we don't have a way of looking at the value and knowing if it's an auction or a bid and, if it is a bid, we don't know what auction is it bidding on. Therefore the datum could hold a special data type that, if it's an auction, should indicate what is being auctioned and what the deadline is and, if it's a bid, should indicate the value being offered and the auction which it's part of.</p>
<p>Example</p>
<pre><code>data AccountDatum = Auction Value POSIXTime | Bid Value Auction
</code></pre>
<p>One problem you could see is that we are still not able to identify who is offering what (since we only have values inside the datum and not public keys). Also, anyone can create any arbitrary Datum in a newly created UTxO. Therefore, we need a way of &quot;authenticating&quot; these UTxOs and &quot;stamp&quot; them, signalizing who the owner of the account is.</p>
<p>This can easily be done with minting policies, as they can execute arbitrary logic without consuming any UTxOs (preserving concurrency). In our case, our policy should make sure that the datum is not corrupted, that the token name it is minting corresponds to the user's public key hash (since we want to identify the owner) and that the minted amount is being transferred (and locked) to the right script (our account script).</p>
<p>After all this is done, the account script can handle transactions however you want. For example, the auction bidders shouldn't be able to change their bid for a smaller amount or retrieve it before the auction deadline is passed. Also, no DOS would be doable since only the owner of this account and the owner of the auction he is bidding on could consume this UTxO (and only if certain conditions are met).</p>
<p>Bidders would be able to compare their bids with other by verifying (off-chain) what other valid accounts are offering. The auction seller would, after the deadline, be able to consume one account UTxO from a bidder by giving it the desired NFT or token of any sort.</p>
<blockquote>
<p>how would you generalize a defense-pattern for other Plutus-contracts?</p>
</blockquote>
<p>I believe this &quot;account model&quot; (unfortunate name lol) is very general, I'm using it in a project I'm working on that has nothing to do with auctions. The main idea you should keep in mind when designing a validator script is to create multiple UTxOs that can only be consumed by the people interested, so if a DOS would happen, it would only affect the attacker him-self.</p>

CC BY-SA 4.0
2021-11-17T00:39:45.303Z
Thanks for the detailed proposal. One more question about your proposal: How can you withdraw a losing bid very fast? It would not be good to lock all losing bids until the the entire auction is finished
Mike76
CC BY-SA 4.0
2021-09-17T20:02:35.803Z
2021-09-17T20:02:35.803Z
Mateus
<p>I think it boils down to the concurrency issue that's been floating around recently. When that's solved (which some projects claim they did), this problem goes away.</p>

CC BY-SA 4.0
2021-09-13T15:11:38.300Z
Yes it is related to the concurrency issue, but it's not exactly the same. For example, I could imagine a DEX that solved the regular concurrency issue with a decentralized auction-order-book, but is still vulnerable to economic DOS attacks within its order-book.
Mike76
CC BY-SA 4.0
2021-09-13T14:17:50.527Z
2021-09-13T14:17:50.527Z
Jelil Akjaly
<p>Many people wrote about the eUTXO model and the benefits it brings compared to Ethereum.
However, eUTXO also comes with some challenges.
In particular, eUTXO is susceptible to &quot;economic denial of service (DOS) attacks&quot;.</p>
<p>Let me give you an example of an economic DOS attack.
Consider the following NFT-auction from the Plutus pioneer program: <a href="https://plutus-pioneer-program.readthedocs.io/en/latest/pioneer/week1.html" rel="noreferrer">https://plutus-pioneer-program.readthedocs.io/en/latest/pioneer/week1.html</a>
This contract is a simple auction where anybody can bid for an NFT until a specified deadline has passed.
However, this contract is vulnerable to an economic DOS attack where a malicious bidder creates a sequence of low bids that prevent other people from placing their bids (e.g. 0.001 ADA, 0.002 ADA and so on).
Such an attack is possible because each eUTXO can be spent only once, and if the attacker is faster than you, then you fail to place your bid on the Cardano blockchain.</p>
<p>It requires some technical sophistication to execute an economic DOS attack, but an average (non-technical) wallet-user cannot defend against it.
Although economic DOS attacks are also possible on Ethereum, it is much harder to execute them successfully within Ethereum's account model.</p>
<p>See the following paper for more details about economic DOS attacks:
<a href="https://docs.google.com/document/u/0/d/12atK0oEME0y1GHo_HmqhrcZ3pQeEqB_0tFKknhsjsLY/mobilebasic" rel="noreferrer">https://docs.google.com/document/u/0/d/12atK0oEME0y1GHo_HmqhrcZ3pQeEqB_0tFKknhsjsLY/mobilebasic</a></p>
<p>So my question is:
(1.) How would you implement a Plutus-NFT-auction that defends against economic DOS attacks and (2.) how would you generalize a defense-pattern for other Plutus-contracts?</p>

<plutus><plutus-pioneer-program><attacks><eutxo>
How to prevent economic DOS attacks against Plutus contracts
# How to prevent economic DOS attacks against Plutus contracts

(Asked by: username_0 on 2021-09-13)

Many people wrote about the eUTXO model and the benefits it brings compared to Ethereum.
However, eUTXO also comes with some challenges.
In particular, eUTXO is susceptible to "economic denial of service (DOS) attacks".

Let me give you an example of an economic DOS attack.
Consider the following NFT-auction from the Plutus pioneer program: <https://plutus-pioneer-program.readthedocs.io/en/latest/pioneer/week1.html>
This contract is a simple auction where anybody can bid for an NFT until a specified deadline has passed.
However, this contract is vulnerable to an economic DOS attack where a malicious bidder creates a sequence of low bids that prevent other people from placing their bids (e.g. 0.001 ADA, 0.002 ADA and so on).
Such an attack is possible because each eUTXO can be spent only once, and if the attacker is faster than you, then you fail to place your bid on the Cardano blockchain.

It requires some technical sophistication to execute an economic DOS attack, but an average (non-technical) wallet-user cannot defend against it.
Although economic DOS attacks are also possible on Ethereum, it is much harder to execute them successfully within Ethereum's account model.

See the following paper for more details about economic DOS attacks:
<https://docs.google.com/document/u/0/d/12atK0oEME0y1GHo_HmqhrcZ3pQeEqB_0tFKknhsjsLY/mobilebasic>

So my question is:
(1.) How would you implement a Plutus-NFT-auction that defends against economic DOS attacks and (2.) how would you generalize a defense-pattern for other Plutus-contracts?

**Tags:** plutus, plutus-pioneer-program, attacks, eutxo

---

## 4 answers

### Answer by username_1 on 2021-09-13. Score: 3

These types of attacks are inherent to the auction model and are not dependent on the technology used. To protect against these, auctions have a minimum bid increase. Other solutions would be (i) a whitelist of known wallets making sure that every participants has at most one wallet, or (ii) bidding fees making DoS attacks expensive.

If you want to run an auction without identity control opened to the general public, minimum bid increases would be the way to go, in my opinion.

> **Comments:**
> **username_0**: My point is that those attacks are much easier with eUTXO/Cardano than on Solidity. It is incredibly expensive to "stall" the Ethereum-mainnet for multiple blocks, whereas it is much cheaper to re-generate a single Cardano-UTXO over multiple blocks. So the defense becomes more important because the attack-tresholds are lower.  
> **username_0**: Minimum bid increases are doable, but I still find it problematic if you compare it with Ethereum. I strongly believe that there should be a more general solution which increases the cost of conducting DOS attacks. Those attacks will always be theoretically possible, but we need to think about the cost of performing the attacks.  
> **username_1**: Many of the people complaining about the UTxO model only think that Ethereum has less problems because they don't understand what happens there behind the scenes. I personally think that the issues of Ethereum are unfixable. The fact that you can write your question above shows how transparent the Cardano model is and how it allows developers to reason about it and think about what could go wrong and what can be done about it. The only way to prevent DoS in open networks is to make them expensive or difficult. UTxO are not more vulnerable than other models.  
> **username_0**: I am definitely not a chain maximalist since different models have different tradeoffs. I would not claim that Ethereum is better, but I am interested in this particular concurrency-attack.  
> **username_2**: One important thing to consider is the 'why'. What does an attacker gain from such an attack? Blocking other people from placing a bid doesn't gain the attacker anything. The attacker will just pay fees each block. So while this is theoretically possible, it's not worth it. At least not in your example.  
> **username_1**: He would gain by winning the auction when the deadline is reached.  
> **username_0**: You are right, you would need a pretty valuable NFT to make this attack profitable. Nevertheless, the attack would be much cheaper than a comparable attack on EVM-chains. Moreover, the NFT auction is just one example of the larger problem.  
> **username_3**: @Jey This class of attack, contention of a shared resource, is something I believe can only happen on a UTxO chain. So I believe it's not correct to say that "These types of attacks are inherent to the auction model and are not dependent on the technology used." Within a global-state system like the EVM, nearly an entire block could be filled up with bids to a particular contract and it still wouldn't prevent someone else from posting a bid. No whitelist system or bidding fee would be necessary.  
> **username_4**: One solution as proposed by Minswap and others are batching bots. Basically you split the bidding process in two steps. First transaction is a b as tch request to add your bid to the contract. Batching bots will compete to collect as many batch requests as possible and construct the actual bidding transaction. Their incentive is that they get a small fee for each processed batch request. Anyone can run auch a bot.  
> **username_1**: @Xiaofei This resolves the concurrency issue but does not protect agains DoS attacks as a malicious user could monopolise the bottleneck UTxO by continuously batching only his requests. @ Maximilian You have a point here but only if you don't take Ethereum's flaws into account. I think Ethereum trades its concurrency model for the MEV issue which is at least as bad. It is like a rug that is too large to fit into a room. Cardano and Ethereum each pull the rug to fit into a different corner.  
> **username_4**: @jey multiple batchers will compete to get their transactions on the block. Stake pools have an incentive to append large transactions to the block to increase the reward pool, so they'd prefer the honest batcher's transaction bundle over the other.  
> **username_1**: @Xiaofei Very good point! I think this is the answer to the question. If stake pools have an incentive to choose the honest batches, the DoS attack problem is solved.  

---

### Answer by username_5 on 2021-09-18. Score: 1

I can think of a different way to structure the contract to avoid this attack.

If you allow all the bidders to lock up their funds at the same time, in separate UTxOs, the auctioneer could just choose which to accept when the deadline has past. This works in Plutus because you can redeem multiple datums in a single transaction, and have the validators check that the other UTxO is being spent, i.e. the `PickWinner` redemption path for a `Auction` datum would requires a `Bid` datum get redeemed as well, and vice-versa.

And say someone wants to update their bid, the `Bid` datum would have a redeemer of `Update`, otherwise your funds are locked until after some grace-period has passed.

This might come with some drawbacks, like the opportunity cost of all the losing bids being locked up, but I can think of ways to minimize those pain. In many cases, it seems like a reasonable cost to pay regardless.

> **Comments:**
> **username_5**: People are talking about how order-book style DEXs are going to be more popular on Cardano because it fits the UTxO model better than the Ethereum accounts model. It would work similarly to what I just explained, however a DEX has a Many-to-Many market, unlike an auction which is Many-to-One. So a DEX is a little more difficult to architect than an auction.  
> **username_0**: Thanks for your detailed answer. I see several drawbacks with separate UTXOs. Firstly, the need of longer locking periods. Secondly, the highest bider does not automatically win, which might lead to more corruption. Sure, all of this can be solved, but I don‘t know whether all those eUTXO troubles are worth the effort.  
> **username_5**: I don't see the eUTxO model as a problem to be solved. I see it as a way to move the complexity of safety to a lower level. There have been billions of dollars lost in Solidity contracts that could have been prevented with the restrictions Plutus has. And those Solidity contracts aren't less complex, Solidity just has a lower barrier to entry to Plutus. Best of all, it gives an dApp developer options.  
> **username_0**: I agree that Solidity has too many bugs right now, but those can be solved. For example, reentrancy bugs can be prevented with compiler-inserted locks, although those locks have some gas-cost-overhead. For Plutus, however, we still need to ask the feasibility question: Is it even feasible to build an atomically composable DeFi-ecosystem with Plutus? I mean not only a DEX, but a composition of complex protocols like flash-loans  
> **username_0**: One more sidenote: Just because someone like SundaeSwap has a workaround for the concurrency-problem does not mean that the problem is solved. In contrast, the following "Scooper model" questions the ability of eUTXO to run a truly decentralized DEX without any off-chain-sequencer or sidechain: https://sundaeswap-finance.medium.com/sundaeswap-labs-presents-the-scooper-model-678d6054318d  
> **username_5**: "Is it even feasible to build an atomically composable DeFi-ecosystem with Plutus?" Oh. Absolutely. All the smart contracts I've looked at are compositions of multiple scripts. Plutus actually is great for composition.  
> **username_5**: I'm familiar with SundaeSwap's proposed architecture. I hope it meets their needs. From a first principles perspective I don't get this allergy to "off-chain-sequencer or sidechain". Ethereum is expensive, so they're looking for layer 2 solutions. I'm excited for those. I'm excited for Cardano to have them too. Luckily the Cardano devs took the usefulness of layer 2, sidechannels, and side chains into account when designing the system. Sounds like we're getting Hydra in the Spring. That's pretty soon. I know there is an arms race going on within DeFi, but I'm hoping for sustainable solutions.  
> **username_0**: I agree that layer 2 solutions are necessary, however this should not come at the cost of increased centralization. If SundaeSwap is forced to run a semi-centralized sequencer because of eUTXO-limitations, then this is a cause for concern. Remember that SundaeSwap's sequencer is not even a layer 2 solution, instead it is a traditional webservice that works around their concurrency problems.  
> **username_5**: Yeah. For sure, there are trade-offs. The blockchain is an awesome tool, but just because we have it doesn't mean that everything needs be completely decentralized to achieve a useful/compelling product. On the other hand, SundaeSwap's model might fail due to too much centralization/bad game theory, and then we can learn from it. Still lots to learn.  
> **username_0**: In my view, a good layer 2 solution should provide not only decentralization, but also the capability of running a smart contract forever, without any monitoring or additional infrastructure. For example, If I deploy a smart contract on a layer 2 solution, then I don't want to run my own sequencing-services, and neither do I want to incentivize other actors to run sequencing-services for me. Of course there might be solutions for decentralized sequencing, but I wonder what research the Cardano-team has done during the last 5 years if they have not even thought about basic eUTXO-sequencing.  

---

### Answer by username_6 on 2021-09-17. Score: 0

How would you implement a Plutus-NFT-auction that defends against
economic DOS attacks?

My approach is a little bit complex, since it involves thinking about the problem in a very different way, so sorry for that.
Instead of having a unique UTxO to handle bids, you could create an "account" script. So each user that want's to be part of an auction would need to create an "account", sending the bid value (e.g. 100 ADA) or the auction value (e.g. random NFT) to this account address (creating a new UTxO).
The datum would also be important, since we don't have a way of looking at the value and knowing if it's an auction or a bid and, if it is a bid, we don't know what auction is it bidding on. Therefore the datum could hold a special data type that, if it's an auction, should indicate what is being auctioned and what the deadline is and, if it's a bid, should indicate the value being offered and the auction which it's part of.
Example
data AccountDatum = Auction Value POSIXTime | Bid Value Auction

One problem you could see is that we are still not able to identify who is offering what (since we only have values inside the datum and not public keys). Also, anyone can create any arbitrary Datum in a newly created UTxO. Therefore, we need a way of "authenticating" these UTxOs and "stamp" them, signalizing who the owner of the account is.
This can easily be done with minting policies, as they can execute arbitrary logic without consuming any UTxOs (preserving concurrency). In our case, our policy should make sure that the datum is not corrupted, that the token name it is minting corresponds to the user's public key hash (since we want to identify the owner) and that the minted amount is being transferred (and locked) to the right script (our account script).
After all this is done, the account script can handle transactions however you want. For example, the auction bidders shouldn't be able to change their bid for a smaller amount or retrieve it before the auction deadline is passed. Also, no DOS would be doable since only the owner of this account and the owner of the auction he is bidding on could consume this UTxO (and only if certain conditions are met).
Bidders would be able to compare their bids with other by verifying (off-chain) what other valid accounts are offering. The auction seller would, after the deadline, be able to consume one account UTxO from a bidder by giving it the desired NFT or token of any sort.

how would you generalize a defense-pattern for other Plutus-contracts?

I believe this "account model" (unfortunate name lol) is very general, I'm using it in a project I'm working on that has nothing to do with auctions. The main idea you should keep in mind when designing a validator script is to create multiple UTxOs that can only be consumed by the people interested, so if a DOS would happen, it would only affect the attacker him-self.

> **Comments:**
> **username_0**: Thanks for the detailed proposal. One more question about your proposal: How can you withdraw a losing bid very fast? It would not be good to lock all losing bids until the the entire auction is finished  

---

### Answer by username_7 on 2021-09-13. Score: 0

I think it boils down to the concurrency issue that's been floating around recently. When that's solved (which some projects claim they did), this problem goes away.

> **Comments:**
> **username_0**: Yes it is related to the concurrency issue, but it's not exactly the same. For example, I could imagine a DEX that solved the regular concurrency issue with a decentralized auction-order-book, but is still vulnerable to economic DOS attacks within its order-book.  

---

