<div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">Den 30 mars 2017 12:04 skrev &quot;Luke Dashjr&quot; &lt;<a href="mailto:luke@dashjr.org">luke@dashjr.org</a>&gt;:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text"><br></div>
I don&#39;t see a purpose to this proposal. Miners always mine as if it&#39;s their<br>
*only* chance to get the fee, because if they don&#39;t, another miner will. Ie,<br>
after 1 block, the fee effectively drops to 0 already.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">I believe that with correctly configured incentives, you can make it more profitable to delay some transactions with lower fees but still include them in the next block then to include them all at once. This would smooth out the inclusion of transactions. </div><div dir="auto"><br></div><div dir="auto">This may require changing the difficulty scaling from using a simple logarithm to a function that first behaves like a logarithm up to some multiple of the standard block size, after which difficulty starts increasing faster and reaches a greater-than-linear ratio in expected required hash per mined bit. Perhaps tipping over at around a blocksize 3x the standard blocksize. Since the standard blocksize increases with continous load after retargeting, the blocksize at which this happens also increases. </div><div dir="auto"><br></div><div dir="auto">Also, together with the above the fee pool does slightly counteract what you say, as they&#39;ll get a share via the pool when there&#39;s less transactions available the next time they create a block (like insurance). </div><div dir="auto"><br></div><div dir="auto">For a user, what&#39;s the incentive to pay an individual miner the fee directly? </div><div class="gmail_extra" dir="auto"></div></div>