{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-09\n📝 Original message:On Sat, May 9, 2015 at 12:58 PM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e\nwrote:\n\n\u003e RE: fixing sigop counting, and building in UTXO cost: great idea! One of\n\u003e the problems with this debate is it is easy for great ideas get lost in all\n\u003e the noise.\n\u003e\n\nIf the UTXO set cost is built in, UTXO database entries suddenly are worth\nsomething, in addition to the bitcoin held in that entry.\n\nA user's client might display how many they own.  When sending money to a\nmerchant, the user might demand the merchant indicate a slot to pay to.\n\nThe user could send an ANYONE_CAN_PAY partial transaction.  The transaction\nwould guarantee that the user has at least as many UTXOs as before.\n\nDiscussing the possibility of doing this creates an incentive to bloat the\nUTXO set right now, since UTXOs would be valuable in the future.\n\nThe objective would be to make them valuable enough to encourage\nconservation, but not so valuable that the UTXO contains more value than\nthe bitcoins in the output.\n\nGmaxwell's suggested \"tx_size = MAX( real_size \u003e\u003e 1,  real_size +\n4*utxo_created_size - 3*utxo_consumed_size)\" for a 250 byte transaction\nwith 1 input and 2 outputs has very little effect.\n\nreal_size + 4 * (2) - 3 * 1 = 255\n\nThat gives a 2% size penalty for adding an extra UTXO.  I doubt that is\nenough to change behavior.\n\nThe UTXO set growth could be limited directly.  A block would be invalid if\nit increases the number of UTXO entries above the charted path.\n\nRE: a hard upper limit, with a dynamic limit under it:\n\u003e\n\nIf the block is greater than 32MB, then it means an update to how blocks\nare broadcast, so that could be a reasonable hard upper limit (or maybe\n31MB, or just the 20MB already suggested).\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150509/ffd834c1/attachment.html\u003e"}