In this commit, we update the `btcwallet` dep to the latest version that
includes a fix related to zero conf spends. Before this new version, if
a single output was spent multiple time by conflicting transactions,
then upon removing them all after a new transaction confirms, a number
of zero conf UTXOs could be left over.
Bumps the default read and write handlers to be well
above the average number of peers a node has. Since
the worker counts specify only a maximum number of
concurrent read/write workers, it is expected that
the actual usage would converge to the requirements
of the node anyway. However, in preparation for a
major release, this is a conservative measure to
ensure that the default values aren't too low and
improve network instability.
In this commit, we add a 5 minute idle timer to
the write handler. After catching the write
timeouts, it's been observed that some connections
have trouble reading a message for several hours.
This typically points to a deeper issue w/ the peer
or, e.g. the remote peer switched networks. This now
mirrors the idle timeout used in the read handler,
such that we will disconnect a peer if we are unable
to send or receive a message from the peer after 5
minutes.
We also modify the readHandler to drain its
idleTimer's channel in the even that the timer had
already fired, but we successfully sent the message.
This commit reduces the peer's write timeout to 5s.
Now that the peer catches write timeouts and doesn't
disconnect, this will ensure we spend less time blocking
in the write pool in case others also need to access the
workers concurrently. Slower peers will now only block
for 5s, after every reattempt w/ exponential backoff.
This commit modifies the writeHandler to catch timeout
errors, and retry writes to the socket after a small
backoff, which increases exponentially from 5s to 1m.
With the growing channel graph size, some lower-powered
devices can be slow to pull messages off the wire during
validation. The current behavior will cause us to
disconnect the peer, and resend all of the messages that
the remote peer is slow to validate. Catching the timeout
helps in preventing such expensive reconnection cycles,
especially as the network continues to grow.
This is also a preliminary step to reducing the
write timeout constant. This will allow concurrent usage
of the write pools w/out devoting excessive amounts of
time blocking the pool for slow peers.
- Remove TOC entries of removed docs sections
- Add hint about complete inbound connection docs section after command
examples for inbound connections to prevent people from overseeing the
listen=localhost flag
This commit increase the expiry grace delta to a value above the
broadcast delta. This prevents htlcs from being accepted that would
immediately trigger a channel force close.
A correct delta is generated in server.go where there is access to
the broadcast delta and passed via the peer to the links.
Co-authored-by: Jim Posen <jim.posen@gmail.com>
Previously there was no minimum remaining blocks requirement on
forwarded htlcs, which may cause channel arbitrator to force
close the channel directly after forwarding the htlc.
Co-authored-by: Jim Posen <jim.posen@gmail.com>
The multiplier doesn't make sense because funds may be equally at risk
by failing to broadcast to chain regardless of whether the HTLC is a
redeem or a timeout.
Commit ca28c0b removed the dep section,
so it shouldn't be mentioned as a target in other targets.
Also, Glide doesn't seem to be used anymore as well.
- Update Go version 1.11 to 1.12
- Fix broken link in GitHub PR template
- Fix inconsistent number of spaces after checkbox
- Add proper link to "Ideal Git Commit structure"
This is a better alternative than retrieving it from the graph as it's
possible that the channel is pruned from it doing to not having any
updates within the past two weeks.
