Antioch Peverell
Antioch Peverell
The initial sync _feels_ slow. We request headers in chunks of 512 from random connected peer. Sometimes we hit a slow peer and the latency introduced in even a few...
## Problem We track `height` and `total_difficulty` for all our connected peers on the `PeerLiveInfo` struct. These are updated when we handle `Ping` and `Pong` messages. These are the *only*...
The library we use for zip/unzip functionality is currently unmaintained. > Unfortunately, due to a lack of time and loss of interest, this project will no longer be actively maintained....
Related - #3082 (initial header sync) If we track "fast" peers during the initial header sync it might make sense to use this information when deciding which peer to request...
@lehnberg's recent work on documenting our Dandelion++ impl #2723 got me thinking about some ways we could potentially simplify the timers and scheduling inherent in the "Dandelion Monitor" in Grin/MW...
For relative lock height kernels I think there is pretty nice optimization that we can make once txs are confirmed and on-chain. Relative kernels - k2 references k1 with a...
We still have scenarios and edge cases where we see the dreaded "Already Spent" error in the logs and a node fails to accept new blocks. Related #3016. Assuming this...
Not super high priority but something we probably want to think about over the next few months. We broadcast txs "header first", followed by "compact blocks". A compact blocks consists...
There is a relatively minor change that we can make to our internal MMR implementation that would reduce the storage requirements significantly. Currently we maintain a data file and a...
This is a bit of a weird edge case and needs thinking through. Putting it here so we don't forget. It is possible to "spend" an unconfirmed output in the...