`SortedMap`.`keySet` returns a `SortedSet`, whereas `SortedMap`.`keys`
returns an `Iterable`. This is a critical difference because channel
range queries has requirements on ordering of channel ids.
Using the former allows us to rely on type guarantees instead of on
assumptions that the `Iterable` is sorted in `ChannelRangeQueries`.
There is no cost difference as internally the `Iterator` is actually a
`SortedSet`.
Also, explicitely specified the type instead of relying on comments in
`Router`.
when we query channels with `query_short_channel_ids`, we now use the same compression
format as in their `repy_channel_range` message. So we should be able to communicate
with peers that have not implemented all compression formats.
* Added server address in ElectrumReady object
* Assigned remote address to variable to improve readability
* Checking that the master address exists in the addresses map
* set a minimum feerate-per-kw of 253 (fixes#602)
why 253 and not 250 since feerate-per-kw is feerate-per-kb / 250 and the minimum relay fee rate is 1000 satoshi/Kb ?
because bitcoin core uses neither the actual tx size in bytes or the tx weight to check fees, but a "virtual size" which is (3 * weight) / 4 ...
so we want :
fee > 1000 * virtual size
feerate-per-kw * weight > 1000 * (3 * weight / 4)
feerate_per-kw > 250 + 3000 / (4 * weight)
with a conservative minimum weight of 400, we get a minimum feerate_per-kw of 253
* set minimum fee rate to 2 satoshi/byte
users can still change it to 1 satoshi/byte
* use better weight estimations when computing fees
* test that tx fees are above min-relay-fee
* check that remote fee updates are above acceptable minimum
we need to check that their fee rate is always above our absolute minimum threshold
or we will end up with unrelayable txs
* fix ClaimHtlcSuccessTx weight computation
* channel tests: use actual minimum fee rate
test with our absolute minimum fee rate (253), it should be valid and anything below
sould be invalid and trigger and specific error
Because we keep sending them over and over.
Using `CacheBuilder.weakKeys` will cause the serialized messages to be
cleaned up when messages are garbage collected, hence there is no need
to set a maximum size.
If the closing tx is already in `mutualClosePublished`, it means that we
already know about it and don't need to re-handle it again. Everytime we
succesfully negotiate a mutual close, we end up publishing ourselves the
closing tx, and right after that we are notified of this tx by the
watcher. We always ended up with duplicates in the
`mutualClosePublished`field.
This fixes#568.
