Rather trivial binary option contract can be created:
Alice submits deposit X
Bob submits deposit Y
If time < t0 + N*block_time:
Alice can withdraw X+Y
Otherwise (timeout):
Bob can withdraw X+Y
While, on first sight, it seems pointless and harmless, something a kid would write on Marlowe, and we can probably find multitude of examples and variations of this contract on-chain, the danger comes from the intended use.
The semantic of the contract above is actually betting against block production, so Y/(X+Y) is estimated probability of N blocks being spammed (or any other type of DoS, bribing SPOs for instance), thus preventing Alice from submitting her transaction.
Parties can adjust probability based on “network conditions”, as well as more alarmingly the state of “death pool derivatives market”. N should start with 1 block, increase N after successful attack. Y should start with something comparable to transaction fees.
The attack itself (whatever it is) does not have to be tied to a contract since timeout is an attestation of a general disruption on its own.
Condition for successful attack (per block):
expenseOfAnyTypeOfAttack < sum(X_i)
For spam attack expenses would depend on fees and penalties. More importantly sum X_i (all bets attacker/s made) is highly dependent on popularity of such “death pool” contracts
Practical conditions:
“Treat every gun as loaded, broken clock is right twice a day”.
Every network based on PoS or even simply on voting blocks with coins, every network that has no other value rather than smart-contract functionality would eventually reach a point where, for whatever reason, not necessarily related to common sense (hi DOGE!) derivatives market would start rewarding spam-attacks. It is unimaginably much higher budget than any group of hackers (Chinese students?) can raise. And all comes from the power of leverage, which derivatives conveniently provide.
Good historical example from traditional markets would be CreditDefaultSwap bubble during Great Recession. And whatever is about to happen with global economy in foreseeable future.
Estimated impact:
PoW-based consensus: <LOW
- While such contracts are possible even on Bitcoin, it is simply too expensive for attacker to produce desirable block.
- Attacker would additionally risk acquired hardware, since it would be rendered useless if network shuts down irrecoverably + we can slash miners by changing hashing algorithm.
- Btc has a limited scripting language, so building variations and improvements of “death pool” attack would be quite challanging.
- Miners have more common sense than stake-pool operators, they have more at stake than stakes. Btc users have more common sense on the average. Hard to start a speculative market.
PoS: MEDIUM-to-HIGH
- It simply depends on popularity of “death-pool” contracts combined with market sentiment (e.g. levels of ADHD), so depends purely on how expensive propaganda against such contracts is, since…
- censoring such contracts is practically impossible: Alice and Bob can always make a regular binary option with timeout (where fake oracle will always output “true”). Same semantic as deathpool, but indistinguishable from regular bet.
- Selfishness: successful bet against block production doesn’t imply that attack would drop the price of the coin. But, from attacker’s perspective it “raises stakes” for next bet, since previous one was successful. Like a rat pressing on opium pedal.
- Worst of all, some variations of deathpool (either oracle or cryptography based) can be done on other chains, and bet can be done with a different coin than the one under attack.
- Investing funds into promotion of “death-pool” markets is cheaper than attacking directly. The amount of damage it can cause can be severe, especially since it could show PoS-networks (and consequently enforcement of contracts running there) as highly dependent on the budgets of “centralized” and quite inter-dependent companies behind them rather than “community of tech-aware users”, or at least independent wallet vendors (and mining pools) in free market competition as is the case with btc etc.
Mitigations:
- bad one: watch out for rise of “death pool” markets and manually raise fees (through “guided” democracy) and penalties depending on conditions. A) It is impossible to automate such fee bump, since managing is equivalent to a bet for healthy block production, so it’s trading (risk mitigation is not automatable by definition - you cannot foresee future conditions automatically) . B) Fee/penalty would reduce blockchain use, moreover attackers can start betting on fees then.
- good one: prepare to switch to PoW, at least as a back-up. Find justifiable use for your coin (e.g. actual payment method for actual goods and services).
- so so one: disable block-height based timeouts and rely on time oracles exclusively. It is more of a smoke-screen solution, since one can bet on block production health from other chains, or even bet on time oracle’s SLA complience in addition to betting against your blockchain.
P.S. If someone already came-up with attack, I really think there is no better name for it than “deathpool”/“deadpool”, since PoW chains have cryptographic “deathpool” equivalent of it (of negligible severity unlike this social one).