⚗️ Create basic expiry model of RFC003

[LLFourn]

Calculate the appropriate alpha_expiry and beta_expiry for each party given the following:

• A function which when given the time since broadcasting a transaction and the transaction fee will return the probability that the transaction has been included in a block.
• A function which when given the time a transaction has been included in a block will return the probability of it being permanently in the blockchain.
• The party's required confidence that they won't lose an asset.

DOD:

• Make a meeting to demonstrate the model
• Give realistic alpha_expiry, beta_expiry values for BTC-ETH and ETH-BTC.
• Include results in relevant RFCs.
• Create issue to default to such realistic values in COMIT-i

Child of comit-network/comit-rs#670

[luckysori]

Findings

@LLFourn and I had a couple of meetings and we figured out some things:

• The difference between alpha_expiry and beta_expiry has an effect on the security of the model for Bob. This does not affect Alice since she will have already redeemed beta_asset by the time this is relevant.
• beta_expiry has an effect on the time that Alice will have to redeem alpha_asset and therefore on the likelihood that the protocol will be completed successfully. This does not have any direct effect on the security of the protocol, but rather on its execution guarantees.

Given this, the topic of this spike changed from creating a security model to, more generally, creating a basic model to calculate expiry times.

Alpha expiry

There are two ways in which alpha_expiry, , has an effect on the protocol:

1. How long Bob will (at least) have to redeem alpha_asset if Alice redeems beta_asset.
2. How long Alice will have to wait to be able to refund alpha_asset if the protocol isn't carried out to completion.

It would therefore be ideal to find a value of alpha_expiry that lets Bob redeem alpha_asset with high probability while also ensuring Alice doesn't have to wait too long to be able to be refunded if it comes to that.

Assumptions

• Bob provides , the time he thinks it will take him to get his redeem transaction confirmed on alpha_ledger. He has direct influence over this since he can choose the fee.
• Bob provides , the number of additional confirmations he would need to have on his redeem transaction before he considers alpha_asset to be his own.
• Block time on alpha_ledger can be modelled as a random variable that follows an exponential distribution with parameter .
• A confirmation is given by the arrival of a new block.
• The value of beta_expiry, , is constant.

Model

To determine alpha_expiry, the time Bob will need to get his desired number of confirmations on his redeem transaction of alpha_asset will need to be estimated. Given the assumptions listed,

,

where is the expected value for the time it would take for the redeem transaction to obtain confirmations on alpha_ledger.

The sum of mutually independent exponential random variables with the same parameter is an Erlang. The expected value for an Erlang random variable is given by .

Therefore,

,

from which alpha_expiry can be easily calculated:

.

Beta expiry

There are two ways in which beta_expiry, , has an effect on the protocol:

1. How long Alice will (at least) have to redeem beta_asset if Bob funds beta_asset.
2. How long Bob will have to wait to be able to refund beta_asset if Alice has yet to redeem it.

Consequently, it would be ideal to find a value of beta_expiry that lets Alice redeem alpha_asset with high probability, allowing the protocol to continue, while also ensuring Bob doesn't have to wait too long to be able to be refunded if it comes to that.

Assumptions

• Alice provides , the time she thinks it will take her to get her redeem transaction confirmed on beta_ledger. She has direct influence over this since she can choose the fee.
• Alice provides , the number of additional confirmations she would need to have on her redeem transaction before she considers beta_asset to be her own.
• Block time on alpha_ledger can be modelled as a random variable that follows an exponential distribution with parameter .
• A confirmation is given by the arrival of a new block.
• Alice needs time to fund alpha_asset.
• Bob needs time to fund beta_asset.

Model

To determine beta_expiry, the random variable to model the time Alice will need to get her desired number of confirmations on her redeem transaction of beta_asset will need to be considered.

Given the assumptions, beta_expiry could be expressed as

,

where is the time when the swap parameters are set, and is the expected value for the time it would take for the redeem transaction to obtain confirmations on beta_ledger.

The sum of mutually independent exponential random variables with the same parameter is an Erlang. The expected value for an Erlang random variable is given by .

Therefore,

.

[LLFourn]

Hey nice work. Here's a few notes on first reading:

• For alpha_expiry I don't think we should use the expected value of the erlang distribution, rather the value that gives Bob's required confidence. (i.e. use the CDF rather than mean).
• "the time she thinks it will take her to get her redeem transaction confirmed on beta_ledger." - This is actually the time in which she is overwhelming confident she will be able to confirm a transaction on the beta ledger.
• I think both parties provide this value for both ledgers.

Obviously we haven't figured out the right answer™ here but I think we know enough about the problem to start reading research papers in this area. Well done!

[D4nte]

Can we finish with the spike PR and move this outcome to our spike repo? It'll be easier to review :)

[luckysori]

Can we finish with the spike PR and move this outcome to our spike repo? It'll be easier to review :)

Absolutely. As soon as that's done I'll submit it there!

[bonomat]

Well written, thanks. Here some comments:

• beta_expiry has an effect on the time that Alice will have to redeem alpha_asset and therefore on the likelihood that the protocol will be completed successfully. This does not have any direct effect on the security of the protocol, but rather on its execution guarantees.

1. Don"t you mean this?
   beta_expiry has an effect on the time that Alice will have to redeem beta_asset...

2. It depends what you mean with security of the protocol.. I'd say it has an effect on the security as Alice could lose all her money if beta_expiry is too small. While trying to redeeming it she reveals the secret, however, if beta_expiry has passed already, Bob can call refund and knows the secret now allowing him to take the funds from the other ledger.

3. under the heading Beta Expiry

Consequently, it would be ideal to find a value of beta_expiry that lets Alice redeem beta_asset with high probability, allowing the protocol to continue, while also ensuring Bob doesn't have to wait too long to be able to be refunded if it comes to that.

Thanks for the model, looks good in general but I'd be interested in some numbers and examples please :)

[luckysori]

1. Don"t you mean this?
   beta_expiry has an effect on the time that Alice will have to redeem beta_asset...

Yep, that's a typo.

2. It depends what you mean with security of the protocol.. I'd say it has an effect on the security as Alice could lose all her money if beta_expiry is too small. While trying to redeeming it she reveals the secret, however, if beta_expiry has passed already, Bob can call refund and knows the secret now allowing him to take the funds from the other ledger.

I agree, but I'd say we have direct control of whether we show the redeem action to Alice, so it's on us to not show the action if it's getting too close to beta_expiry. This means that the protocol will not proceed to completion, but Alice won't be put in a position to try to redeem when it's too risky.

3. under the heading Beta Expiry

Consequently, it would be ideal to find a value of beta_expiry that lets Alice redeem beta_asset with high probability, allowing the protocol to continue, while also ensuring Bob doesn't have to wait too long to be able to be refunded if it comes to that.

Good catch, another typo 😛

Thanks for the model, looks good in general but I'd be interested in some numbers and examples please :)

Good idea!

[bonomat]

I agree, but I'd say we have direct control of whether we show the redeem action to Alice, so it's on us to not show the action if it's getting too close to beta_expiry. This means that the protocol will not proceed to completion, but Alice won't be put in a position to try to redeem when it's too risky.

I'm not sure if I understand your comment correctly: My understanding of this model is exactly for making this secure for anyone (not just our implementation)

[luckysori]

Alice's risk is determined by whether she attempts to redeem alpha_asset when it's too close to alpha_expiry.

The model calculates alpha_expiry, which determines the likelihood that Alice will have enough time to redeem alpha_asset. But in terms of security this value doesn't matter.

Obviously, for egregiously large values of alpha_expiry Alice could never possibly be in a situation in which she would be attempting to redeem when it's too dangerous, but the model does not take any of this into account.

[LLFourn]

The latex conversion I made of the previous work is here: https://www.overleaf.com/read/sswbyytnfjhy

Please review.

[D4nte]

@LLFourn who should be reviewing?

[bonomat]

Really good work on that so far. I've added some comments and discussed with @LLFourn offline.