RFC: Burn slashed collateral

[aesedepece]

Where are we?

• WIP-0002 introduced a collateral functionality that helps preventing bribery attacks as well as sybil attacks.
• The specification states that collateralized coins that get slashed from witnesses that fail to reveal or that committed an outlier (aka liars) are distributed to the other witnesses that participated in resolving the same oracle query.
• Distribution of slashed collateral was introduced only because back in the day when we were designing the protocol, we wanted to stay away from any coins burning in fear of any legal implications of introducing such mechanisms.

What's the problem?

• Redistribution of slashed collateral creates a clear incentive for malicious nodes operators to try to perform different collateral-stealing attacks on other witnesses.
• Attack 1:
  • This attack starts with a large scale crawling of the Witnet network with a view to deanonymizing as many nodes as possible, i.e. build a list of public keys → IP addresses.
  • Then, every time an attacker's node participate in witnessing, it will look in the list for the IP of the fellow committers, and DDoS some of those addresses through some shady 3rd party service, such that a percentage of committers lesser than 100% minus the quorum requirement of the oracle query (always >50%) can't broadcast their reveals, which will trigger slashing on them.
  • For a query with w witnesses, c collateral per witness and q percentage of quorum, each attacking witness can theoretically steal up to w * c * (1 - q) / (q * w) Wits.
  • For the typical price feed request we see these days, that's 3.33 Wits for the attacker (a 66% ROI on the collateralized amount), while for differently sized queries, there's a mathematical limit on 96% ROI.
  • Of course this attack would also fan out funds to another q * w - 1 identities potentially not controlled by the attacker, but after enough rounds of attack, that wouldn't have much of an effect and the attacker would end up stealing a majority of the collateralized Wits.
  • There's no evidence of this type of attack ever happening, due to the difficulty of doing a wide scale deanonymization of the nodes, and different rules and filters that affect inbound peering (e.g. bucketing).
• Attack 2:
  • This is similar to the first one, but instead of acting on denying service to fellow committers, it acts on crafting oracle queries so they contain "inconsistent" data sources that, under control of the attacker, will provide different values to each of the witnesses, such that the quorum requirement is still passed, but slashing is always triggered on w * (1 - q) witnesses.
  • As with the previous attack, this will consistently cause w * c * (1 - q) Wits to be distributed across q * w random witnesses.
  • However, it is not possible for the attacker to force itself into the witnessing committee of the specially crafted oracle queries, and hence this doesn't make for a great collateral-stealing attack unless the attacker already controls a significant part of the network and have some reasonable expectation for any of their nodes to be aligible to witness a good share of the crafted requests. In any other scenario, this attack will simply fan out collateralized Wits randomly across the network.
  • There was actual evidence of this type of attack being performed in the testnets to try to accelerate expiration and redistribution of reputation points, so it is reasonable to think that this kind of attack may also be feasible on the mainnet.

Can devs do something?

• There is already a proposed update to the witnet-rust software that might protect nodes from Attack 2:
  • Often referred as smart retrievals, it is presented as an opt-in feature to let a node perform the data retrieval through multiple network interfaces (e.g. their regular Internet connection, plus some proxy, plus Tor).
  • When doing so, they will only commit to an oracle query if the source appears to be consistent enough across the multiple interfaces, that is, if the data obtained through those retrievals would pass the same filters and aggregations as the actual committed values will need to pass.
  • If the data sources look inconsistent, the witness will refrain from committing altogether, keeping itself away from a more than probable slashing.
  • Smart retrievals is an opt-in feature and doesn't require any protocol change. It can be shipped at any time without any consensus implication.
  • While this should be a pretty effective countermeasure against Attack 2, it does nothing against Attack 1.
• Acting on how the slashed collateral is distributed would actually tackle Attack 1, specially if the slashed coins are burnt. Under that scenario, we'd be assimilating Attack 1 to Attack 2: any attackers triggering slashing on purpose would just make everyone in the ecosystem "richer" by means of burning coins out of circulation, with no particular advantage to them individually.
• With a sufficiently decentralized network, there are no legal concerns at all about protocol-enacted burning mechanisms. The Witnet Foundation won't oppose this anymore.

My proposal

• Introduce a WIP that changes the collateral logic in Tally transactions, such that any slashed collaterals will not be distributed to witnesses, but rather taken out of circulation, i.e. burnt.
• Rehash the smart retrievals proposal immediately and make it available to all miners through a minor release of witnet-rust.
• Educate the miners on the best practices around the smart retrieval features, how to configure proxies, etc.

[aesedepece]

This is now live on mainnet as WIP-0023!