<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, May 9, 2015 at 4:36 AM, Gregory Maxwell <span dir="ltr">&lt;<a href="mailto:gmaxwell@gmail.com" target="_blank">gmaxwell@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">An example would<br>
be tx_size = MAX( real_size &gt;&gt; 1,  real_size + 4*utxo_created_size -<br>
3*utxo_consumed_size). </blockquote><div><br></div><div>This could be implemented as a soft fork too.<br><br></div><div>* 1MB hard size limit<br></div><div>* 900kB soft limit<br><br></div><div>S = block size<br></div><div>U = UTXO_adjusted_size = S + 4 * outputs - 3 * inputs<br><br></div><div></div><div>A block is valid if S &lt; 1MB and U &lt; 1MB<br><br>A 250 byte transaction with 2 inputs and 2 outputs would have an adjusted size of 252 bytes.<br></div><div><br></div><div>The memory pool could be sorted by fee per adjusted_size.  <br></div><div><br></div><div> Coin selection could be adjusted so it tries to have at least 2 inputs when creating transactions, unless the input is worth more than a threshold (say 0.001 BTC).<br><br></div><div>This is a pretty weak incentive, especially if the block size is increased.  Maybe it will cause a &quot;nudge&quot;<br></div></div></div></div>