Quote from: kano on November 16, 2016, 05:49:32 AM

OK, so correct me if I'm wrong, but why is a slower relay considered better?

If I understand the limitations you've added correctly, all you have done is speed up your internal UDP relay, but replaced the external connections to it with a slower relay and added excessive burden on the bitcoind.

Not sure what "excessive burden" you're referring to here - replacing one P2P connection with another shouldn't change the load on your bitcoind, even if one is remote...If you really want to split hairs you should see less load on your bitcoind because the message hashing for an entire block no longer happens.

Quote from: kano on November 16, 2016, 05:49:32 AM

The current (old) relay means there's a program (normally) local to the bitcoind that's hit with transactions at whatever rate is happening with the relay, then when a block is found, the traffic from your service is minimal, usually just a small compressed block, and then the local relay pushes a whole block to the local bitcoind that happens to (normally) be 0ms away, so no network issue at all.

Not quite...the old relay network protocol is bandwidth-limited to only send out a certain number of transactions per second (I think its like 5Mbps, so it shouldnt ever really hit that, but it does means that if you get a burst it could get behind.

Quote from: kano on November 16, 2016, 05:49:32 AM

With this new 'connect a bitcoind' directly to your network, all traffic from your network comes and goes directly to the main bitcoind.
How is the block compression compared to the current (old) relay?

Compact Blocks get much better compression than the old relay network in real-world testing. There are a few minor tweaks that need to happen that will take them from reasonably-often-missing-transactions to rarely-missing-transactions (including orphan pool, recent-replacements, etc).

Quote from: kano on November 16, 2016, 05:49:32 AM

Do you send transactions from your new relay to the bitcoind? Coz that will also be an unwanted thing to happen.

This isnt a change from the old behavior - the old client used to send transactions it received to bitcoind locally ((re-)starting a relay network client remains one of the easiest ways to get your mempool filled after restart a node, at least until 0.14).

Quote from: kano on November 16, 2016, 05:49:32 AM

Basically it sounds like the new relay is really a transaction improvement relay, not a block relay improvement, so an improvement for payment sources, but a slower block relay for pools.

Your internal network may be faster, but the external network seems slower by design.

Compact Blocks is a far, far superior protocol to use on the wire vs the old realy network protocol, and the fact that its in bitcoind directly instead of via an external daemon means the latency of it can be much lower (it can skip, for example, the hash-message-check-message-hash stuff that happens now). Indeed, there is a drawback of occasionally having an extra round-trip from clients to relay network servers, but current testing shows that a) the improvement in average latency between the servers far outweighs most RTTs to clients (eg within a continent you shouldn't see more than 50-100ms RTT), b) its relatively easy to shave another 10-30ms (yes, really, its that bad) off the total receive->ProcessNewBlock time, which should all happen in 0.14, in compact blocks, whereas for the RN code its really not so trivial, and c) we can hopefully make the RTTs much less common with some simple fixes which the compact blocks protocol already supports, just aren't yet implemented.