From ed2ff08a5c72742be72c1780cda6c0bd98263ef1 Mon Sep 17 00:00:00 2001 From: "John M. Jones" Date: Fri, 28 Sep 2018 13:06:09 -0500 Subject: [PATCH] Edits based on comments Removed outdated paragraph about user requesting refund after timeout (it is now automatic). Added method to retrieve all HTLC contracts by account. --- bsip-0044.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bsip-0044.md b/bsip-0044.md index 1f6cd62..e0ae2e2 100644 --- a/bsip-0044.md +++ b/bsip-0044.md @@ -88,8 +88,6 @@ Upon presentation of a `preimage`, the HTLC `condition evaluator` validates: If all evaluations succeed, the `secured assets` are transferred to the `recipient`. If any evaluation fails, nothing happens; the HTLC remains ready to evaluate the next `preimage`. -Upon presentation of a request from the `depositor` for return of `secured assets`, the HTLC `condition evaluator` validates that the `timeout threshold` is now in the past. It then returns the `secured assets` to `depositor`. - ### **Timing of Condition Evaluation** The `timeout threshold` of the contract is defined by `depositor` within the HTLC at creation. It can be any time in the future and should allow enough time for `recipient` to review the HTLC and provide the `preimage`. Further, it should not be set too far into the future to mitigate against an unresponsive `recipient` impacting `depositor`, as their `secured assets` will be locked until `timeout threshold` expiry. The accuracy is based on when the `condition evaluator` runs, and should be considered accurate ± 15 seconds. @@ -252,7 +250,7 @@ transaction_obj htlc_extend_expiry(depositor, id, timeout_threshold, htlc_extent return results ``` -### **At Expiry** +### **At Expiry** (evaluated at each block commit) ``` Get: get_htlc(id) @@ -273,6 +271,8 @@ transaction_obj htlc_extend_expiry(depositor, id, timeout_threshold, htlc_extent ### **get_htlc** +### **get_htlcs_by_account** + # **Discussion** https://github.com/bitshares/bsips/pull/104