1) Why do miners not like to fill blocks up to the absolute cap? Is there more work for them to do if they have lots of transactions in the block? I notice lots of blocks are only about 150KB large, when the protocol allows up to 500KB/1MB (Not sure, it's one of the two), while, there are lots of unconfirmed transactions in the mempool. Why not just include those? Even if they have super low transactions fees and/or low priority. I completely understand why a miner would ignore them if the block was filled up (And thus order by "How much profit can I get?"), but, that's not the case currently.
2) Am I correct in thinking, in theory, with the current "standard" settings (Obviously miners can change this), it only takes 58 confirmations on a 0.01 transaction for it to have a high enough priority to be free? That seems inaccurate, but, I can't work out what's wrong with my calculations.
Sorry for the newbie question, but, we all have to learn, eh?
2) Am I correct in thinking, in theory, with the current "standard" settings (Obviously miners can change this), it only takes 58 confirmations on a 0.01 transaction for it to have a high enough priority to be free? That seems inaccurate, but, I can't work out what's wrong with my calculations.
Sorry for the newbie question, but, we all have to learn, eh?
1) With a larger block, it will take longer time to be relayed, and it will slightly increase the orphan rate.
The miner may get a little more tx fee, but compared with the 25btc block reward, it is pretty much nothing.
2) To be qualified to be a high-priority tx, you need to have priority > 57,600,000.
For a tx with 1 input and 2 outputs (1 as change), the tx size should be ~230 Bytes.
Code:
priority = sum(input_value_in_base_units * input_age)/size_in_bytes
Thus, if you have a piece of 0.01btc input, you will need it to have at least 13248 confirmations lol.