Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-05-25 📝 Original message:> > There > is no need to ...
📅 Original date posted:2014-05-25
📝 Original message:>
> There
> is no need to have Bitcoin transport all using a single protocol, and
> we can get better robustness and feature velocity if there are a
> couple protocols in use (you could just run a block-transport-protocol
> daemon that connects to your local node via the classic protocol).
Although this is a somewhat appealing notion, would it really improve
feature velocity? I don't think the current p2p protocol is holding
anything back, and having to implement features twice in two protocols
would slow things down quite a bit.
Probably the lowest hanging fruit now is fixing the 100msec sleep and just
generally having tools to measure latency and queuing inside the code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140525/61868344/attachment.html>;
📝 Original message:>
> There
> is no need to have Bitcoin transport all using a single protocol, and
> we can get better robustness and feature velocity if there are a
> couple protocols in use (you could just run a block-transport-protocol
> daemon that connects to your local node via the classic protocol).
Although this is a somewhat appealing notion, would it really improve
feature velocity? I don't think the current p2p protocol is holding
anything back, and having to implement features twice in two protocols
would slow things down quite a bit.
Probably the lowest hanging fruit now is fixing the 100msec sleep and just
generally having tools to measure latency and queuing inside the code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140525/61868344/attachment.html>;