<p>As you stated, setting 2 different expiration times provides safety.</p>

<p>My recommendation is to select the network with the longest period before immutability as the first contract, and pick a time that is agreeable with both parties. </p>

<p>The second contract on the other chain should use an expiry that is half of the first contract. This gives the redeemer on the first blockchain some time before the expiry.</p>

CC BY-SA 4.0
2018-11-04T13:52:54.883Z
2018-11-04T13:52:54.883Z
jmjatlanta
<p>Before that 48 hours passes, one can't refund funds. The only thing s/he can do is to wait for the initiator to redeem coins.</p>

<p>After the locktime ends, one becomes able to get a refund. However, you're still able to redeem coins.</p>

<p>So, you're still able to redeem coins after the locktime.</p>

CC BY-SA 3.0
2018-04-11T16:07:01.853Z
This is understood, however, the question is a bit different. it describes a potential attack
Damien
CC BY-SA 3.0
2018-04-11T13:48:14.217Z
2018-04-11T13:48:14.217Z
MCCCS
<p>As per the explanation provided here: <a href="https://github.com/decred/atomicswap" rel="nofollow noreferrer">https://github.com/decred/atomicswap</a></p>

<p>The contract is valid for a certain amount of time (example set to 48h) and in order for the party B to recover the found, he needs the secret that is published on the chain after the party A has redeem the coins on the contract.</p>

<p>As far as I understand, it takes some time for party B to actually recover the secret from the chain and then redeem the coins.</p>

<p>What happens if party A wait last seconds (let's say 5 seconds) before expiration of the contract to redeem the coin, which wouldn't provide enough time for party B to redeem its coin before the contract expiration in which case it would be refunded to party A as well as getting party B coins.</p>

<p>Is the understanding correct and that point valid?</p>

<p>Is it fixable by setting different contract expiration period, lets say party A contract would need longer expiration time to ensure party B ha time to redeem the coins?</p>

<atomic-swap>
Atomic Swap - What if redeem is done just before expiration
Damien
# Atomic Swap - What if redeem is done just before expiration

(Asked by: username_0 on 2018-04-11)

As per the explanation provided here: <https://github.com/decred/atomicswap>

The contract is valid for a certain amount of time (example set to 48h) and in order for the party B to recover the found, he needs the secret that is published on the chain after the party A has redeem the coins on the contract.

As far as I understand, it takes some time for party B to actually recover the secret from the chain and then redeem the coins.

What happens if party A wait last seconds (let's say 5 seconds) before expiration of the contract to redeem the coin, which wouldn't provide enough time for party B to redeem its coin before the contract expiration in which case it would be refunded to party A as well as getting party B coins.

Is the understanding correct and that point valid?

Is it fixable by setting different contract expiration period, lets say party A contract would need longer expiration time to ensure party B ha time to redeem the coins?

**Tags:** atomic-swap


---

## 2 answers

### Answer by username_1 on 2018-11-04. Score: 1

As you stated, setting 2 different expiration times provides safety.

My recommendation is to select the network with the longest period before immutability as the first contract, and pick a time that is agreeable with both parties.

The second contract on the other chain should use an expiry that is half of the first contract. This gives the redeemer on the first blockchain some time before the expiry.


---

### Answer by username_2 on 2018-04-11. Score: 0

Before that 48 hours passes, one can't refund funds. The only thing s/he can do is to wait for the initiator to redeem coins.

After the locktime ends, one becomes able to get a refund. However, you're still able to redeem coins.

So, you're still able to redeem coins after the locktime.

> **Comments:**
> **username_0**: This is understood, however, the question is a bit different. it describes a potential attack  

---

