When you 'spend' in Bitcoin you are giving someone else the right to move coins and you can place conditions on that future move. A common method in chaining is to output to a multi-sig p2sh that contains one of your keys.
Image Source: Scalable Funding of Bitcoin Micropayment Channel Networks by Burchert, Decker, and Wattenhofer
Transaction publish is limited through the use of nLockTime to ensure that a redeem or commit transaction can only be added to a block after the desired wait time. This method is used to delay revocation spends, redeem scripts as well as settlement (channel close) transactions.
CheckLockTimeVerify (CLTV) is used to enforce output spends at a certain absolute height or time. CheckSequenceVerify (CSV) is used to encumber an output and prevent it from being spent during a relative period (revocation or challenge period). While used for different cases the idea is the same. A waiting period is created using CLTV or CSV in order to allow for many spends in a channel or for a challenge period.
The idea is to allow for a conditional payment where the bearer of the secret can claim funds immediately. The sender of funds creates the preimage and discloses it to the receiver only when a next channel state is negotiated. This shuns the broadcasting of a previous state. One-off private keys or hash preimages are used to allow for revocation. Duplex, Poon-Dryja and HLTC-based channels all employ this mechanism. Used in conjunction with timeout period.
Image Source: Scalable Funding of Bitcoin Micropayment Channel Networks by Burchert, Decker, and Wattenhofer
HASH160 <revokehash> EQUAL
IF
<Bob's pubkey>
ELSE
"24h" CHECKSEQUENCEVERIFY DROP
<Alice's pubkey>
ENDIF
CHECKSIG
Payment channels - Bitcoin Wiki
Channels on Bitcoin Magazine for diagrams one two three
Duplex channels by Decker - YT
This repo uses markdown with embedded mermaid that isn't fully support on Github
A few options for rendering:
- Atom + Markdown Preview Enhanced
- Mermaid live editor