From cb5a29f35570328b6ff52ac868de5e298240a3e8 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Mon, 8 Jan 2018 19:32:53 -0800 Subject: [PATCH] Change wording --- drafts/arcalinea-xcat/draft.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drafts/arcalinea-xcat/draft.rst b/drafts/arcalinea-xcat/draft.rst index 48f4ed04..0b818497 100644 --- a/drafts/arcalinea-xcat/draft.rst +++ b/drafts/arcalinea-xcat/draft.rst @@ -70,7 +70,7 @@ Timeout Periods Having timeout periods on both transactions allows the XCAT protocol to work by enabling refunds in case a counterparty misbehaves. The example above uses a timeout period of 24 hours for the first transaction and 48 hours for the second, but these are simply suggestions. Actual timeout periods should be considered to be variables that depend on the following factors for any given implementation of XCAT: -**Duration** - The time-lock period on the transaction in which the initiating party reveals R must be significantly shorter than the time-lock period on the second transaction which allows the other party to use the revealed R, in order to give them enough time to redeem their funds using R. +**Duration** - The time-lock period on the transaction in which the initiating party reveals R must be significantly shorter than the time-lock period on the second transaction in which the other party uses the revealed R, in order to give them enough time to make use of R to redeem their funds. For example, once Alice reveals R by spending what Bob sent to her P2SH address, Bob must have enough time to use R to redeem his funds on the other blockchain before Alice can be allowed to refund herself. If there were an insufficient time delay between the first and second timeout periods, Alice could potentially spend Bob's funds at the last minute, then quickly refund herself on the other blockchain before Bob gets a chance to redeem his portion using the R she reveals.