I wonder if there's much point in trying to be accurate. You could simply count them sure. Be 100% accurate. But what does that number tell you? I'm pretty sure the average size has changed over the years. Compressed addresses. Multi sig addresses. P2SH. OP_RETURN. More spam? Less spam? Any average you determine now will be different next year. Maybe you don't want one number but a graph of the the average per month? Per week? What's your purpose for this? – Jannes – 2014-10-15T22:53:41.687

I don't need to know it perfectly, but +98% accurate would be great. – RLH – 2014-10-16T00:41:53.910

98% sounds pretty random again. But total blockchain size / number transactions would probably get you there already. Especially if you correct that using a minus constant blockheader size. (Yeah I know it's not really constant) – Jannes – 2014-10-16T08:06:36.013

Obviously, the correct way to get this answer to to calculate the size of these transactions and divide by the number of transactions executed and processed thus far. My margin of error, however, is because I'd be willing to accept this metric, even if it was calculated 2 years ago. The immediate average is certainly different than what is was a year or two ago. However, that difference is within my personal margin of error, thus the 2%. – RLH – 2014-10-16T11:23:45.240

I doubt that. I wouldn't be surprised if transactions are getting bigger. Because of growing use of mulitisig and op_return and more. How can you want something almost 100% accurate but then say you don't mind a difference because you estimate that diff to be max 2% ? I – Jannes – 2014-10-16T12:38:58.957

If you want a current answer take the avg size in the last 3 months. If you want more insight into what that number would even mean, make a graph of the avg size for each month since genesis (that will show you if your 2% is realistic). If you don't care about that much detail, look at a few random samples of what you think are typical transactions (not too many txins or txouts, not too many signatures) and just go with that. – Jannes – 2014-10-16T12:39:23.080

Yes, I understand how to do this but I don't have a client installed for me to run this operation against. I ask in case someone else has the answer and they could provide the answer. If I get around to it (could take a while) I'll figure this out on my own and update the question with an appropriate answer. – RLH – 2014-10-16T12:51:54.787

I understand, that's why I'm making comments, not answers. Also: I'm a bit surprised existing statistics and graphing sites don't include a graph for this. It is an fun/interesting statistic. For example when thinking about the scalability of the blockchain in 10 years, it's not just the number of transactions that's important, but also the change in their avg size. (For that purpose you probably do want to include the header overhead into the avg size.) – Jannes – 2014-10-16T14:14:13.620

I think an economically more meaningful estimate is the average value of transactions (in BTC denomination, less tx fees). – user10405 – 2015-12-16T01:26:34.857

Not if you're trying to calculate the growth in disk space used, year-over-year. – RLH – 2015-12-16T01:28:44.390

You can always find (not the average, but the) median transaction size from the last 24 hours on the bitcointfees.21.co page. Scroll down a bit to the "Which fees should I use" section.