On Sun, May 25, 2014 at 2:36 AM, Mike Hearn <m...@plan99.net> wrote: > 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.
If someone wanted to implement swanky UDP non-blocking transports or complex network coding schemes I'd probably want to see the proven in actual use before sticking them in the reference code, so yes. It's also the case that the ~last addition we made to the P2P code added a remotely exploitable crash bug. There are some pretty distinct use cases out there— fast block relaying, supporting thin clients, minimizing bandwidth (e.g. via compression and tx/block redundancy elimination), etc. Some of them may not be well handled by an external gateway, some of them (e.g. block relaying) very much could be. The nice thing with alternative protocols and gatewaying is that it can proceed completely asynchronously with implementation development, e.g. revving versions as fast as the users of the protocol care, and could potentially be used immediately with other bitcoin implementations... and if its buggy it doesn't break the nodes using it: I'd be much more likely to run an experimental gateway in another process on a node than experimental p2p code inside my production bitcoinds themselves. ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
