...
...
Do you have numbers to compare - coz that's really the point here.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).How is the block compression compared to the current (old) relay?
...
I of course have the old compression numbers for every block since the beginning of time since I've used your relay
If the new one is better compression (= faster block transmission) then you can say that if you have numbers
Post a run of any 100 blocks and I'll get the same blocks and see (like my 50 block post above) - that's really what I want to see.
Edit: well to make it simpler - all blocks 439000 to whenever you can find the stats (currently 439277)
Edit2: there's also another question in the interface design - what's the comparison of the 2 for back and forward communication?
e.g. comparing the two (I don't know what that are)
1) 'send block'-> (finished)
2) 'message'-> 'reply'<- 'block'-> (finished)
0r
3) something else added to handle the txns
Or
4) ...
etc.
My main concern is that bitcoind sux.
It's hopeless at keeping connections and has too much overhead.
The relay seemed to be able to keep the connection for a long time (I have counters that display in a different colour when it loses/regains the connections) so I've seen how reliable that can be.
(I don't "watch" the old relay log, I instead have a script run a simple analysis of the last 9999 lines in the log every 10 seconds)
I suspect that the relay was pretty minimal in back and forth communication and data size vs bitcoind.