ueno

該当するのか、よくわからなくなってきた。 c-lightningにissueで確認中。

`commitment_signed` は再送とは呼ばない再送を行うと判断した。 commitment numberが不一致の場合の commitment_signed の再送受信には対応したが、再送ができていない。 unilateral closeしてしまっている。

理想型 * regtest * node * our node[funder] * disconnect if node receive `commitment_signed` * their[fundee] * normal * already channel established ``` 1. (disconnect after established) 2. connect 3....

#618 も類件ではあるが、`commitment_signed`の再送はおこなっているので、closeでよい。

`commitment_signed` / `revoke_and_ack` 交換を4状態に分け、状態2以降であればどちらか片方でもirrevocably committedになっているので再送などを行う。 * 安定 * 状態1: `update_add_htlc`側が`commitment_signed`を送信後 * 状態2: それに対して`revoke_and_ack`返信後 * 状態3: 続けて`commitment_signed`送信後 * 安定: それに対して`revoke_and_ack`送信後 もっと汎用的な見分け方はできないだろうか？ P2Pなのにシーケンスに依存しすぎている気がする。

もう1つ。 状態1から元に戻す場合、HTLCの`id`をどこに戻して良いのかが簡単に決められそうな感じがしていない。 DBに保存すれば可能なのか？　それとも前回の「状態」という考え方を見直す必要があるのか？

現象はrevoked transaction closeのときに発見されたが、unilateral closeでもtimeout待ちになっているHTLCをpreimageで先に取り戻された場合には発生していたと思われる。

graphをグローバル変数にし、`ver_add()`を分離して先に行うように試作した。 `ver_add()`によってgraphへvertexを先に登録することで高速化されることを期待したのだが、まったく効果が無かった(むしろ、先に登録する時間がかかることで増えている)。

起動時にgraphを作成する方法を修正。 起動時間が長くなるが、支払いは速くなった。 しかし、RAM上に持つためコストが高い。 psのRSSが227,356KiBだったので、この方法は厳しい。 もっとRAMが少ないライブラリか、省RAMな検索方式があるとよいのだが。

channel_updateを2週間くらいでpruneしてもよいような書き方をしているので、データを減らせないか。 あるいは、graphのデータを減らせないか。