<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, May 9, 2015 at 12:58 PM, Gavin Andresen <span dir="ltr">&lt;<a href="mailto:gavinandresen@gmail.com" target="_blank">gavinandresen@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">RE: fixing sigop counting, and building in UTXO cost: great idea! One of the problems with this debate is it is easy for great ideas get lost in all the noise.</div></blockquote><div><br></div><div>If the UTXO set cost is built in, UTXO database entries suddenly are worth something, in addition to the bitcoin held in that entry.<br><br></div><div>A user&#39;s client might display how many they own.  When sending money to a merchant, the user might demand the merchant indicate a slot to pay to.<br><br></div><div>The user could send an ANYONE_CAN_PAY partial transaction.  The transaction would guarantee that the user has at least as many UTXOs as before.<br><br></div><div>Discussing the possibility of doing this creates an incentive to bloat the UTXO set right now, since UTXOs would be valuable in the future.  <br><br></div><div>The objective would be to make them valuable enough to encourage conservation, but not so valuable that the UTXO contains more value than the bitcoins in the output.<br><br></div><div>Gmaxwell&#39;s suggested &quot;tx_size = MAX( real_size &gt;&gt; 1,  real_size + 4*utxo_created_size - 3*utxo_consumed_size)&quot; for a 250 byte transaction with 1 input and 2 outputs has very little effect.<br><br></div><div></div><div>real_size + 4 * (2) - 3 * 1 = 255<br><br></div><div>That gives a 2% size penalty for adding an extra UTXO.  I doubt that is enough to change behavior.<br><br></div><div>The UTXO set growth could be limited directly.  A block would be invalid if it increases the number of UTXO entries above the charted path.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>RE: a hard upper limit, with a dynamic limit under it:</div></div></blockquote><div><br></div><div>If the block is greater than 32MB, then it means an update to how blocks are broadcast, so that could be a reasonable hard upper limit (or maybe 31MB, or just the 20MB already suggested).<br></div></div></div></div>