Quote from: kano on November 01, 2016, 09:47:09 PM

So correct me if I'm wrong but ...

Old network
'Relay' to 'local' using TCP but only a small 'compressed' block and that passes it to the local bitcoind for full verification

New network
'Relay' to 'remote' using UDP, full size 'compressed' block?, full verification?, then pass to 'local' bitrcoind for full verification again

Really not sure what you're trying to say here, but - New network is UDP between its own servers (dedicated 1Gbps on every link except the Beijing one, but its fast enough, too), but then Bitcoin-P2P protocol between the servers and clients. Hopefully you're using Bitcoin 0.13+ so you'll be using compact blocks, which are generally more effecient than the old relay network protocol by a decent margin (plus I have some hacks to force compact block clients into low-latency mode). If you have a server which is particularly far from the nearest relay network server I'm happy to talk about setting up something that isnt Bitcoin-P2P, and am thinking about doing FIBRE-based peering (so UDP floods for block announce).

Quote from: kano on November 01, 2016, 09:47:09 PM

... and also I must run segwit ... which I don't want to do.

Nope, see https://github.com/bitcoinfibre/bitcoinfibre/commit/335f87424a60af1fc02bffb7c84e90b8e2eadeca which will fast-relay compact blocks out to peers within a few ms of receiving the block if either a) you're a segwit peer or b) segwit has not activated.

Quote from: kano on November 01, 2016, 09:47:09 PM

... and of course any pool that would open their main bitcoind to UDP traffic (to remove the extra step) clearly has never considered the risks of doing that or has no idea about how UDP works ... as I brought up before ...

Ahh, I see the misunderstanding - nope, its only Bitcoin-P2P publicly for now.