Expiring HTLCs without free relay

The email raises a series of technical inquiries about the implementation and implications of certain blockchain transaction rules, specifically relating to nSequence and nLockTime. The sender is querying the origin and application of a variable 'R' within the context of blockchain transaction sequences. It is questioned whether 'R' originates from the normal bit space used in BIP68 relative timelocks (from bit 1 to bit 15 of nSequence), or if it is derived by calculating the difference between the actual inclusion blockheight of a transaction and the blockheight at which the coin was created, with a stipulation that this difference must exceed 100.

Furthermore, there is an exploration into how the nLockTime parameter functions within transactions. The sender understands that while this approach aims to set a minimum threshold for nLockTime, it does not restrict its maximum value. This setup allows for a secondary transaction (Tx2) with a specific nLockTime to mandate that another transaction (Tx1) must be included in the blockchain before the nLockTime of Tx2 minus a predetermined value (at least 100 or capped at 100). If Tx1 is not included by this time, Tx2 would be rendered invalid.

Lastly, the discussion touches on how the concept of "expiry" is linked to the parent transaction (Tx1). The sender seeks clarification on whether the expiry time is defined by the nLockTime of Tx1, which is pre-signed and unaffected by the actual inclusion time of the transaction. This mechanism employs the nLockTime of Tx1 to ensure its inclusion occurs prior to a specified blockheight. Through these questions, the sender is attempting to deepen their understanding of the operational mechanics and constraints imposed by these parameters within blockchain transactions.