<p>I was hoping somebody else would answer this, since I am the author of eltoo, I would have preferred an independent answer.</p>

<p>To recap: the locktime is used in eltoo to enable a numeric comparison between an element on the stack (state number) and a value that the signature commits to. The reason we can't simply push a number on the stack ourselves is that this push would happen in the <code>redeemScript</code>, which cannot be committed in the signature, since it contains the signature. <code>OP_CLTV</code> combines the push, comparison and verification in one opcode:</p>

<blockquote>
  <p>Marks transaction as invalid if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed.</p>
</blockquote>

<p>To your question about it being safe: <code>OP_CLTV</code> is the only opcode that ever touches the <code>nLocktime</code> (intended to be used in the <code>scriptPubkey</code>), and the only other use is to mark a transaction as invalid until a certain height. Both usecases only specify what happens with future blockheights and timestamps, and do not have any effect if the <code>nLocktime</code> is in the past.</p>

<p>Therefore eltoo's use of the <code>nLocktime</code> field and <code>OP_CLTV</code> is technically not a repurposing, rather it makes use of the existing semantics.</p>

<p>Of course I can't foresee if there is any future proposal that might want to repurpose past blockheights and timestamps, but I'm not aware of any, and searching the <a href="https://github.com/bitcoin/bips/search?q=nLocktime&amp;unscoped_q=nLocktime" rel="nofollow noreferrer">BIPs</a> doesn't return any conflicting results. It'd also be very unsafe redefine its semantics for timestamps that were plausible in the blockchain, leaving us a few million unique timestamps even if we only consider 2009-01-03 - today.</p>

CC BY-SA 4.0
2018-07-31T10:42:11.217Z
2018-07-31T10:42:11.217Z
cdecker
<p>In the eltoo proposal for paymentchannel management with less overhead proposed by Christian Decker et al. the <code>update transactions</code> need to be ordered. In chapter 4.1.2 of the proposal it is described for the sake of being backwards compatible that the <code>nLocktime</code> field can be repurposed within the update transactions. </p>

<p>Are there any other pitfalls of this solution besides the fact that it seams a little bit hacky? </p>

<bitcoin-core-development><lightning-network><micropaymentchannels><eltoo>
What are the pitfalls of repurposing the nLocktime field for backward compatability in eltoo?
Rene Pickhardt
# What are the pitfalls of repurposing the nLocktime field for backward compatability in eltoo?

(Asked by: username_0 on 2018-07-08)

In the eltoo proposal for paymentchannel management with less overhead proposed by Christian Decker et al. the `update transactions` need to be ordered. In chapter 4.1.2 of the proposal it is described for the sake of being backwards compatible that the `nLocktime` field can be repurposed within the update transactions.

Are there any other pitfalls of this solution besides the fact that it seams a little bit hacky?

**Tags:** bitcoin-core-development, lightning-network, micropaymentchannels, eltoo


---

## 1 answers

### Answer by username_1 on 2018-07-31. Score: 4 | Accepted answer

I was hoping somebody else would answer this, since I am the author of eltoo, I would have preferred an independent answer.

To recap: the locktime is used in eltoo to enable a numeric comparison between an element on the stack (state number) and a value that the signature commits to. The reason we can't simply push a number on the stack ourselves is that this push would happen in the `redeemScript`, which cannot be committed in the signature, since it contains the signature. `OP_CLTV` combines the push, comparison and verification in one opcode:

> Marks transaction as invalid if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP\_NOP was executed.

To your question about it being safe: `OP_CLTV` is the only opcode that ever touches the `nLocktime` (intended to be used in the `scriptPubkey`), and the only other use is to mark a transaction as invalid until a certain height. Both usecases only specify what happens with future blockheights and timestamps, and do not have any effect if the `nLocktime` is in the past.

Therefore eltoo's use of the `nLocktime` field and `OP_CLTV` is technically not a repurposing, rather it makes use of the existing semantics.

Of course I can't foresee if there is any future proposal that might want to repurpose past blockheights and timestamps, but I'm not aware of any, and searching the [BIPs](https://github.com/bitcoin/bips/search?q=nLocktime&unscoped_q=nLocktime) doesn't return any conflicting results. It'd also be very unsafe redefine its semantics for timestamps that were plausible in the blockchain, leaving us a few million unique timestamps even if we only consider 2009-01-03 - today.


---

