|
|
|
@ -697,7 +697,7 @@ to wait for their funds ((("payment channels", "trustless channels", startref="p
|
|
|
|
|
|
|
|
|
|
==== Asymmetric Revocable Commitments
|
|
|
|
|
|
|
|
|
|
Another way to handle the prior commitment states
|
|
|
|
|
Another way((("payment channels", "asymmetric revocable commitments", id="payment-channel-revoke")))((("asymmetric revocable commitments", id="asymmetric-revoke-commit")))((("commitment transactions", "asymmetric revocable commitments", id="commit-revoke")))((("revocable commitments", id="revoke-commit"))) to handle the prior commitment states
|
|
|
|
|
is to explicitly revoke them. However, this is not easy to achieve. A
|
|
|
|
|
key characteristic of Bitcoin is that once a transaction is valid, it
|
|
|
|
|
remains valid and does not expire. The only way to cancel a transaction
|
|
|
|
@ -911,7 +911,7 @@ innovation in this technology. With this construct, the channel can
|
|
|
|
|
remain open indefinitely and can have billions of intermediate
|
|
|
|
|
commitment transactions. In implementations of Lightning
|
|
|
|
|
Network, the commitment state is identified by a 48-bit index, allowing
|
|
|
|
|
more than 281 trillion (2.8 × 10^14^) state transitions in any single
|
|
|
|
|
more than 281 trillion (2.8 × 10^14^) state transitions in ((("payment channels", "asymmetric revocable commitments", startref="payment-channel-revoke")))((("asymmetric revocable commitments", startref="asymmetric-revoke-commit")))((("commitment transactions", "asymmetric revocable commitments", startref="commit-revoke")))((("revocable commitments", startref="revoke-commit")))any single
|
|
|
|
|
channel.
|
|
|
|
|
|
|
|
|
|
==== Hash Time Lock Contracts (HTLC)
|
|
|
|
|