Published on: 2015-10-13T19:52:50+00:00
Pierre expressed difficulty in understanding the rationale behind all existing closing flows and states related to svg. He asked for an updated version of svg and also requested aj to do the same with his 'flat' version. Pierre questioned the need to handle combinations of the three basic cases regarding current commit, revoked commit, or mutual close. Rusty chimed in to explain that despite these three cases spending the same anchor, it is necessary to keep watching until any one of them is buried deep enough (say 100 deep) so that a revoked transaction plus chain reorganization could not cheat us of funds. Overall, these details make a robust implementation difficult.A user requested for an updated version of svg and also asked for aj's 'flat' version. Aj responded by saying that he has updated state.py and provided a new flow that works. However, Pierre is still confused about the rationale behind all the existing closing flows and states. He questioned why they need to handle combinations of the three basic cases (current commit, revoked commit or mutual close) since they all spend the same anchor right. Pierre wondered why it matters if they are broadcasted and not confirmed.In this email conversation, Rusty Russell is discussing state coverage testing with Anthony Towns. Rusty mentions that the testing isn't exhaustive and only serves to ensure that the state machine doesn't crash. He lists the varying degrees of thoroughness of the tests, which include ensuring that the state machine never gets into an invalid state, never sends a packet the other side doesn't expect, terminates if not on the main loop, does not deadlock, and cleans up. Anthony asks about testing agreeing on two HTLCs and having one time out before the other. Rusty responds that STATE_CLOSED means "completely finished" and that they don't support mutual close with outstanding HTLCs because the protocol is complex enough already. He also suggests adding optional output of traces for successful test cases to make it more obvious what's being tested. Rusty concludes by saying that while more comments and testing would be nice, he has to stop writing tests at some point.In an email conversation, Rusty Russell and aj discussed the state coverage testing for a certain code. Although Rusty suggested drawing diagrams to perform exhaustive testing, he acknowledged that it was not enough. However, he was unsure of what the code actually does with the exhaustive testing as there were many asserts which may only be testing if things "don't crash" instead of whether they "make sense". He proposed having optional output of traces for successful test cases to make it more evident. Furthermore, aj speculated on the behavior of the CLOSE protocol when there are HTLCs in progress. Despite being expected and normal protocol behavior, aj suggested that CLOSE should track HTLCs and spend when timeouts hit or R’s become known, similar to when a commitment is published.A discussion is taking place between Anthony Towns and Pierre regarding the updated version of svg. Aj, previously designed a flow which has been updated by Towns to work more efficiently. The updated svg can be viewed at http://azure.erisian.com.au/~aj/tmp/lightstate/simplified-states-20150929.svg. However, some transitions are still missing. The discussion continues with Towns explaining the issues he faced while testing states coverage. He explains that thorough testing requires more than throwing every packet at it and recording what happens, stating that state doesn't quite encapsulate everything. Furthermore, he says that simulating pairs and covering all combinations of states between them, as well as taking into account non-packet events, like timeouts and bitcoin watch events, are also important. Finally, he adds that injecting errors is also necessary. After updating the final result, Towns pushed it online.On September 24, 2015, Pierre expressed confusion regarding the updated closing flows and states in response to the announcement of Close now having a second ACK stage. He requested an updated version of the SVG, which ajtowns provided through state.py, and updated flow works with test_state_coverage --dump-states. Ajtowns shared the link for the viewable SVG, which is still missing some transitions such as PKT_UPDATE_DECLINE_HTLC. The context ends with a partial code related query by ajtowns.In a recent email conversation, Rusty has shared some updates on the Close and HTLC rejection scenarios in Lightning Network. The new update includes an additional ACK stage for close which confirms that the close ack has been received. The HTLC rejection now handles cases such as bad route and insufficient fees. A protocol error is generated, if a new HTLC is proposed which will cause the commit tx to be malformed. Rusty also talked about placing an upper bound of 0.04 BTC on each HTLC, which is more than enough to cover micropayment uses of lightning. According to him, early adopters are going to be microtransactions.
Updated on: 2023-07-31T18:21:52.614157+00:00