Rollback fees are a pre-enlightenment concern

[michielbdejong]

As per https://gist.github.com/emschwartz/1c4a736cea1ecd829ec355483661a0c9#gistcomment-2291631 I thought about what we should do in terms of rollback fees, to mitigate free option attacks.

The attack works as follows: Suppose I am a connector, and you hold two accounts with me: one in BTC, one in USD. You prepare two payments-to-self, one from your BTC account to your USD account, and one from USD account to your BTC account. If BTC becomes more valuable before the timeout, you fulfill the USD-to-BTC payment (buying at the older, lower price) and reject the other one; if it becomes less valuable, you do the opposite. If the movement is less than my effective transaction fee, you let both payments expire. You repeat this continually, and that way, your total position gradually improves over time. Whenever BTC moves enough against the USD, you cash in on your free option.

Transaction fees can easily cover this risk: During steep slopes (e.g. 22 Dec 2017, 2pm UTC ), BTC moves against USD by about 0.1% per minute. That means that a 0.1% transaction fee would be enough to allow timeouts of up to a minute, and make your strategy not work even in times of steep shifts.

Also, post-enlightenment, you don't actually get paid out on the ledger, you only have accounts at my connector, so whenever exchange rates move, I can make sure to temporarily increase my transaction fee. That way, it may look to you like you hold an account that's denominated in BTC, but really I get to decide how much that account balance is worth if you want to use it for Interledger payments. So I could add a clause in my code saying that if any asset suddenly increase in value by more than 0.1% in any 10 second period, then I temporarily increase the spread, so that to buy that asset, you would immediately get charged the higher price, but to sell it, I would temporarily still offer you the older, worse rate.

When moving by 0.1% per 10 seconds, it would take only 96*10 seconds = 16 minutes to cumulatively move as much as 10%, so such a limit on the delta seems reasonable.

For payment channels, whoever funds the channel needs to lock up funds from the channel opening transaction to the channel closing transaction, in the currency of the channel. But "connector opens payment channel to receiver" is a separate item on the "ILP Next Steps" todo list, unrelated to rollback fees.

[dappelt]

During steep slopes (e.g. 22 Dec 2017, 2pm UTC ), BTC moves against USD by about 0.1% per minute.

An attacker would most likely use crypto trading pairs, since the rates change more dramatically than with fiat to crypto.

[michielbdejong]

Right, but that's at most a factor two then, right?

[dappelt]

I wrote up a longer response but lost it unfortunately as the tab was closed 😖 So here is the TL;DR

Exchange rates between cryptos can change more than 0.2% per minute according to historical data (0.5% is not rare), which somewhat influences your calculation above. However, I am confident we can mitigate free option attacks, both, on a protocol design level and in practical connector implementations. More specifically, designing ILP for short payment timeouts reduces the connector's exposure to price fluctuations. Furthermore, it should be fairly easy for practical connector implementations to detect ongoing free option attacks and activate suitable countermeasures. For example:

• Throttle Payment Bandwith: By limiting the payment bandwidth of a suspected attacker, the connector reduces its potential loss as well as the attacker's potential profit.
• Increase Fee: A connector can (temporarily) penalize a suspected attacker with increase transaction fees. This makes free option attacks less profitable and the attacker needs larger price fluctuations to make the attack profitable.
• Reject payments/Cancel Subscription: More drastic measures are to outright reject payments from a suspected attacker (potentially for a limited time) or to cancel his subscription etc.

[justmoon]

@dappelt @michielbdejong Agree and nice work!

[adrianhopebailie]

@dappelt @michielbdejong have these findings been documented in one of the RFCs? Can we close the issue?

[michielbdejong]

I guess they need to be added somewhere in a design choices section?

[dappelt]

@emschwartz might want to include the findings in the upcoming blog posts about ILPv4.

[adrianhopebailie]

Stale