Jeremy Rand

Also see https://github.com/namecoin/ncdns/pull/174

> and not detrimental to performance Based on https://github.com/brianolson/cbor_py , it looks like CBOR is expected to be quite a bit faster than JSON if both libraries are equally well...

> If you could send me (either a link, or send to my email) some examples of typical JSON messages you get (one large, perhaps one or two medium ones)...

@SomberNight Yes, the idea of excluding the previous block hash occurred to me, and I think it's worth trying (orthogonally to the other ideas discussed here). I wasn't aware of...

> Here are two JSON messages I'm observing in Electrum-NMC: http://3q4jhw6htdrfftl3.onion/mastiff-shrug > [snip] > Let me know once you've downloaded the files so I can shut off the onion service...

@kyuupichan here are the chunks that were available previously on the onion service. [nmc_chunks.zip](https://github.com/kyuupichan/aiorpcX/files/2893947/nmc_chunks.zip)

Based on my testing with real-world dumps of Namecoin ElectrumX traffic (I'll upload my data and code shortly), it looks like compressing CBOR with DEFLATE (i.e. the compression algorithm of...

> OK, what about the various compressed sizes vs original JSON? Here's the data I have so far: https://github.com/namecoin/electrum-nmc-compression-test Using chunk 80 as an example (it's the largest chunk in...

> I haven't yet tried ascii85, I'll see if I can get some data on that shortly. Updated the aforementioned repo with analysis on ascii85; the tl;dr is that ascii85...

> Do you want to suggest protocol and code changes to enable this feature? @kyuupichan Should I submit the protocol changes as a PR to the ElectrumX repo, or is...