If only, OP_RETURN only takes 40 bytes. So if you made a smallish transaction it would be 10% of it. So something like 50 MB to do it.
If you did it 3 times a day you have consumed the more than entire block bandwidth.
It could also be encoded in addresses AFAIK which takes less space. I was assuming perfect use of block space, which of course is not realistic and an actual solution would waste even more space. The white paper by satoshi is said to be in this transaction[1] which has only ~7% overhead.
[1] https://www.blocktrail.com/BTC/tx/54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713
Yes.
The problem for any of these solutions is that then the reassembly and decompression algorithm has to be stored somewhere. Eg. Which blocks? Or at minimum, which op_returns to combine in which order.
At 40 bytes each, that is 125,000 transaction - ordered, one per block. Then you'd just need to know the address to reassemble. It might take 250,000-500,000 blocks since you wouldn't want to do them out of order, so they'd have to be spaced out to avoid orphan out of order issues. And you run the risk of op_return going away later. edit: If you waited every 6 blocks to submit a transaction (even assuming it is mined in the next block) that is 24 per day or 5000 days total to encode it, about 13.6 years.