Quote from: goatpig on September 02, 2015, 10:40:42 PM

As long as you have a Tx size you can guesstimate the top boundary for TxOut count per Tx. Short of that, block size could give you a broader range, but then you would have to resolve tx hashes to block height.

Not sure how much of that data is available through the RPC in pruned mode. I'm very familiar with block chain analysis but I work directly with raw block data, never through the RPC. Maybe you are better off using the P2P layer in an attempt to query more relevant data.

Unfortunately looks like you can't get the tx size while in pruning mode (or even in normal mode, in general you need -txindex=1)
Also I'm pretty sure that in pruning mode you actually cant use getblock and similar calls.

Yeah using the p2p layer could be used, with those bloom filters. The BitcoinJ implementation is bugged and doesnt provide privacy and reading through the documents it's not clear to me how that could be fixed.

Quote from: 2112 on September 02, 2015, 10:47:48 PM

It is my understanding that removing this restriction is a high priority task item for the Bitcoin Core developers. I don't exactly follow their progress, but many people expressed interest in having both pruning and wallet working at the same time.

Presumably I should read through the bitcoin dev mailing list to figure out how the developers imagined using a pruned node would work.
I don't see a way around requiring a pruning node to redownload the entire blockchain whenever a wallet is imported. Presumably this might end up as the accepted way of doing things, users should recover or import new wallets rarely.