<p>Such a functionality is currently not implemented and as far as I understand not intended. You can look at <a href="https://medium.com/@gertjaap/discreet-log-contracts-invisible-smart-contracts-on-the-bitcoin-blockchain-cc8afbdbf0db" rel="nofollow noreferrer">Discreet Log Contracts</a> which where intended to solve CFD (Call for difference) contracts for example with cross asset swaps and changing exchange rate within the timelock period. We have <a href="https://hackmd.io/@lpQxZaCeTG6OJZI3awxQPQ/LN-DLC" rel="nofollow noreferrer">a proposal how they could be transfered to lightning</a>. That being said this would mean severe protocol changes and also computation of many signatures. Yet I think a similar construction could be applied for your usecase.</p>

CC BY-SA 4.0
2020-05-08T13:51:34.413Z
Thanks @Rene Pickhardt for sharing the resource.
Subhra Mazumdar
CC BY-SA 4.0
2020-05-08T14:05:27.780Z
Just wanted to know while updation of state in DLC, so if it is combined with LN, how does one keep track of the latest state? In LN the last state is first invalidated before moving on to the next state. So if the other party stops responding intentionally and the party affected broadcasts last updated state, so there is a chance the other party wakes up and claims all the channel fund.
Subhra Mazumdar
CC BY-SA 4.0
2020-05-08T20:06:02.367Z
that is exactly why we have this channel factory construction. This splits the channel into a part that operates as before with alle the state handling as known and independent of that we have the DLC. the DLC does not have to be touched if balances change. viceverca lightning state does not have to be touched if the DLC settles or is renegotiated. of course a lot of details are not described in the proposal
Rene Pickhardt
CC BY-SA 4.0
2020-05-09T03:07:03.953Z
Oh sorry yes missed that part! I haven't got much idea about channel factories, so I will read it up
Subhra Mazumdar
CC BY-SA 4.0
2020-05-09T03:51:26.677Z
But can one do away with the problem of stale state  if one of the parties do not cooperate for updation ? In that case there is no way the party can update the fund to be received by imposing a penalty (like the one above 0.005 BTC and 0.005 BTC for half a day delay).
Subhra Mazumdar
CC BY-SA 4.0
2020-05-09T21:19:17.527Z
whenever someone is not cooperative we go on chain. it is hard to speculate how a potential feature which might be possible by using ideas described above would handle that case on chain. in regular lightning everything works. for such a special case one would have to make a concrete suggestion how to realize such a feature and we could then discuss if it works or not
Rene Pickhardt
CC BY-SA 4.0
2020-05-08T06:28:34.473Z
2020-05-08T06:28:34.473Z
Rene Pickhardt
<p>Suppose in a payment route A->B->C, A desires to pay 0.01 BTC to C. It locks in 0.01 BTC with B in the HTLC having timeout period of say 2 days and B locks 0.01 BTC with C in HTLC having timeout period of 1 day. Now can something like this be done that if C delays in revealing the preimage say takes 1/2 day, then it gets 0.005 BTC and 0.005 BTC is returned to B. Can the contract support such dynamic settlement of payment based on amount of time lost? In the worst case, if C doesn't respond then B gets back full 0.1 BTC. </p>

<lightning-network><micropaymentchannels><hash-time-locked-contract>
settling timelocked contracts based on amount of time elapsed in Lightning network
Subhra Mazumdar
# settling timelocked contracts based on amount of time elapsed in Lightning network

(Asked by: username_0 on 2020-05-08)

Suppose in a payment route A->B->C, A desires to pay 0.01 BTC to C. It locks in 0.01 BTC with B in the HTLC having timeout period of say 2 days and B locks 0.01 BTC with C in HTLC having timeout period of 1 day. Now can something like this be done that if C delays in revealing the preimage say takes 1/2 day, then it gets 0.005 BTC and 0.005 BTC is returned to B. Can the contract support such dynamic settlement of payment based on amount of time lost? In the worst case, if C doesn't respond then B gets back full 0.1 BTC.

**Tags:** lightning-network, micropaymentchannels, hash-time-locked-contract


---

## 1 answers

### Answer by username_1 on 2020-05-08. Score: 2

Such a functionality is currently not implemented and as far as I understand not intended. You can look at [Discreet Log Contracts](https://medium.com/@gertjaap/discreet-log-contracts-invisible-smart-contracts-on-the-bitcoin-blockchain-cc8afbdbf0db) which where intended to solve CFD (Call for difference) contracts for example with cross asset swaps and changing exchange rate within the timelock period. We have [a proposal how they could be transfered to lightning](https://hackmd.io/@lpQxZaCeTG6OJZI3awxQPQ/LN-DLC). That being said this would mean severe protocol changes and also computation of many signatures. Yet I think a similar construction could be applied for your usecase.

> **Comments:**
> **username_0**: Thanks @username_1 for sharing the resource.  
> **username_0**: Just wanted to know while updation of state in DLC, so if it is combined with LN, how does one keep track of the latest state? In LN the last state is first invalidated before moving on to the next state. So if the other party stops responding intentionally and the party affected broadcasts last updated state, so there is a chance the other party wakes up and claims all the channel fund.  
> **username_1**: that is exactly why we have this channel factory construction. This splits the channel into a part that operates as before with alle the state handling as known and independent of that we have the DLC. the DLC does not have to be touched if balances change. viceverca lightning state does not have to be touched if the DLC settles or is renegotiated. of course a lot of details are not described in the proposal  
> **username_0**: Oh sorry yes missed that part! I haven't got much idea about channel factories, so I will read it up  
> **username_0**: But can one do away with the problem of stale state  if one of the parties do not cooperate for updation ? In that case there is no way the party can update the fund to be received by imposing a penalty (like the one above 0.005 BTC and 0.005 BTC for half a day delay).  
> **username_1**: whenever someone is not cooperative we go on chain. it is hard to speculate how a potential feature which might be possible by using ideas described above would handle that case on chain. in regular lightning everything works. for such a special case one would have to make a concrete suggestion how to realize such a feature and we could then discuss if it works or not  

---

