Hiroki Gondo

listpaymentに残っている分については、payment_hashが重複したらエラーにしたほうがいい。 payment_hashをキーにしてpayment_idが逆引きできるDBを作ってチェックする。 json-rpcで支払いを投入しても、接続が切れたりして、進行中なのかいなかわからないときに、支払いをむやみにリトライするとおなじhashで連続支払いしてしまう、などのケースを防ぎたい。

いま実質pingのチェックがなされていない状態。 転送先のchannelでpingのチェックを行い、不通ならcommitment_signedを送らず、送信待ちのupdate_add_htlcはfailで折り返す。 すでにdisconnectの状態のときにupdate_add_htlcが転送されてきた場合は、failで折り返すようになっている。

ちゃんと動くのか コーナーケースがないか

write-transactionだと明示的にcloseしなくてもtxn close時にcloseされる read-only transactionだと明示的にcloseしなくてはならない http://www.lmdb.tech/doc/group__mdb.html#ga9ff5d7bd42557fd5ee235dc1d62613aa

lmdbのエラーチェックがスキップされているところが多い。 MDB_NOTFOUNDの場合、スキップすべきケースが多いが、 そうでないときもスキップされている。

M_DB_CHANNEL_SAVE呼び出しについて 保存タイミングを限定しないと復旧できない

https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#closing-negotiation-closing_signed >The receiving node: > >if the signature is not valid for either variant of closing transaction specified in BOLT #3: >MUST fail the connection.

jsonrpc-c's number type problem

1

numberについて、 cの型に変換するときに曖昧さが。 例えば4294967295を渡すと、valueintでは溢れる。 カスタマイズされたvalueu64では渡せるが、結局上限値のチェックなどはできない。 いっそのこと文字列で取得できればいいのに。

ucoincliを実行すると{}が返ってくることがあった。 すごくまれ。

freerate problems

2

open channelでfreereteの不一致でエラーになるケースが多い。 各自のNodeで許容範囲が異なるので仕方がないが、 - 送信側のfreerateを設定できるようにする。 - 受信側の許容範囲を設定できるようにする。