Pierre-Marie Padiou

> there is a massive spike which could have caused significant changes to the average Tx fee, if that's what you mean Exactly. > long before the ultimate closing of...

@dpad85 we could indeed add a setting to set the tolerance to fee mismatches (e.g. low/medium/high). @kozo-cz how about submitting a PR?

@STAWKEYE your setup is different: your mobile is the funder, so it chooses the feerate, and you can configure your node to be tolerant. In @kozo-cz's case the funder is...

Sounds like a reasonable request. Related code is here: https://github.com/ACINQ/eclair/blob/master/eclair-core/src/main/scala/fr/acinq/eclair/blockchain/electrum/ElectrumClient.scala#L66-L75

While I agree with @cfromknecht that a litteral interpretation of the spec does allow sending of `announcement_signatures` before `channel_reestablish`, I think that it is wrong because the exchange of `announcement_signatures`...

> I'd argue that the restriction to block on announcement_signatures is unnecessary > What would we gain by restricting counterparties from using their own channel before the proofs have been...

> I don't think this implies though that funding_locked has to be sent before announcement_signatures. Isn't it sufficient to recommend waiting max(6, min_depth) blocks in BOLT 7 before sending announcement...

Fwiw we can already opt out entirely of updates on a peer by peer basis by not sending `gossip_timestamp_filter`. Le mer. 20 mars 2019 à 21:17, n1bor a écrit :...

Those are orthogonal things: this PR reduces the bandwidth used by gossip, all things remaining equal (even if the number of `channel_update`s remained the same). @n1bor seems to have a...

There is actually a catch, as c848cfe shows. `getSimpleClassName` actually returns the full or simple class name depending on whether it is applied to an object or a class!