ueno

lmdbのファイルサイズは128MBだが、`mdb_copy -c`でコンパクト化すると1桁小さくなった * 前 : 134,217,728 * 後 : 11,931,648 `channel_announcement系`が16749個、`node_announcement`が1884個。 概算すると、データだけで11MB程度になるため、ファイルサイズとそれほど乖離はない。 (データのほとんどは`channel_announcement系`である。)

#129 で枝刈りをしていく程度でよいのではないかと考えている。

#724 でmaxdbをチャネル数から計算するように変更。

Raspberry Pi3でswapを大きく確保したが、mapsizeが1,610,612,736byte(=1.5GB)まではOKで、2.0GBだとエラーで確保できなかった。 前回の件数で11MB程度なので、枝刈りも含めればこの程度で十分ではないだろうか。 今までは134,217,728byte=128MBとしていたが、LMDBは増加していくDBのため上限に達したのではないかと思われる。 PR #828 で圧縮する試作を行ったが、テスト環境を考え出せていない。

何かの値から計算できる方がよいのだが、見つからないため暫定で対策する。

#600 と同じ？

This document explain how to build. https://github.com/nayutaco/ptarmigan/blob/master/docs/build_for_spv.md#build # Ubuntu 18.04 setup 1. `make clean` 2. edit [options.mak](https://github.com/nayutaco/ptarmigan/blob/8332f08edae83104ffb77ca19809c0496a468d0a/options.mak#L3) ``` set NODE_TYPE=BITCOIND ↓↓↓ set NODE_TYPE=BITCOINJ ``` 3. `make` 4. set `LD_LIBRARY_PATH` for...

#525 と同じ状況を、c-lightningを相手にして確認した。 c-lightningは`commitment_signed`を送信した方になるが、再接続時に同じ`commitment_signed`を再送してきた。 BOLT仕様に明記されていない動作のように思うが、どうなのだろうか？ ---- * ptarmiganがc-lightningに送金し、`commitment_signed`受信によってabort() * 再接続し、`channel_reestablish`送信 * [ptarm]next_local_commitment_number: 7 / next_remote_revocation_number: 7 * [cln]next_local_commitment_number: 8 / next_remote_revocation_number: 6 * [cln]前回ptarmが受信に失敗した`commitment_signed`を再送

上記のログ [fail_comsig_log.zip](https://github.com/nayutaco/ptarmigan/files/2107754/fail_comsig_log.zip)

BOLT#02の、一番下が該当すると思われる。 ---- A node: - MUST NOT assume that previously-transmitted messages were lost, - if it has sent a previous `commitment_signed` message: - MUST handle the case where the corresponding...