A state machine.

Summary:

In 2015, Pierre raised concerns with Rusty Russell regarding the order of events in the Lightning Network protocol. Pierre questioned whether BITCOIN_ANCHOR_DEPTHOK would always occur before the other party's PKT_OPEN_COMPLETE or if it could vary depending on each party's minDepth. He also asked for clarification on the state of Bob in a multi-party transaction scenario.Rusty responded by sharing details on a state machine he had written for the wire protocol that handles all commands and bitcoin event notifications. Rusty provided links to diagrams illustrating the different states of the protocol and noted that the protocol should handle re-transmits and be able to recover from them if state is saved after every transition. He also outlined the various combinations of events that participants in the network could be waiting for during the closing phase of a transaction.The context provided includes a list of enums used in the Lightning Network protocol implementation. The first set of enums describe different states that the protocol can be in, such as STATE_CLOSE_WAIT_STEAL and STATE_CLOSED. The second set of enums describe inputs that can trigger state changes, such as PKT_OPEN and BITCOIN_ANCHOR_DEPTHOK. There are also enums for timeouts and commands.The Lightning Network is a layer two protocol built on top of Bitcoin that enables faster and cheaper transactions. By creating payment channels between users, they can transact without broadcasting every transaction to the Bitcoin network. Instead, they only need to broadcast the final state of the channel when they are done using it.The use of enums makes it easier to manage the different states and inputs in the protocol implementation code, and allows for clear communication among developers working on the project. The provided context was posted on the Lightning-dev mailing list, which is a forum for developers working on Lightning Network implementations to discuss and share ideas.

Updated on: 2023-05-23T19:57:44.793063+00:00