Alexey Osipov
Alexey Osipov
Might be better to store both ports. There is no agreement about having same ports; same ports may be easier to detect by ISP/bad actors
Some useful links: - protocol examples https://github.com/NethermindEth/dotnet-libp2p/blob/main/src/libp2p/Libp2p.Protocols.Pubsub/PubsubProtocol.cs https://github.com/NethermindEth/dotnet-libp2p/blob/main/src/libp2p/Libp2p.Protocols.PubsubPeerDiscovery/PubsubPeerDiscoveryProtocol.cs - https://github.com/libp2p/py-libp2p/issues/540 - Kad-dht Implementing KAD-DHT in Py-libp2p: https://docs.google.com/document/u/8/d/1ZtHUR6PTSPuaUPVtGM9hwaMS4gG4o86NyLUiCBLPNn0/edit
> We only prune blocks older than 82125 epochs, outside the weak subjectivity period so it shouldn't affect anything We sync old blocks, so I suppose such pruning will prune...
@lucafabbri hello, nop, feel free to pick it
> I'm trying with a different approach - to use head block minus 64 instead of finalized block. It will not be 100% safe, but in e.g. optimism there is...
> Hi [@flcl42](https://github.com/flcl42), could you explain a little about what needs to be done? I would love to pick this up. I've improved the description a bit. Feel free to...
Hello @lucafabbri ! The code looks great, just few notes: Could you check `src\libp2p\Libp2p.Core\Stream.cs`? It contains some logic that may be useful for your implementation, it has more detailed handling...
> Maybe we should add new method for that? We already have a lot of compatibility issues when different clients have extra features on the same methods When called in...
> > > Maybe we should add new method for that? We already have a lot of compatibility issues when different clients have extra features on the same methods >...
It's critical to increment EnrSequence also with every update