{"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-13\n📝 Original message:On Sat, May 9, 2015 at 4:36 AM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\n\u003e An example would\n\u003e be tx_size = MAX( real_size \u003e\u003e 1,  real_size + 4*utxo_created_size -\n\u003e 3*utxo_consumed_size).\n\n\nThis could be implemented as a soft fork too.\n\n* 1MB hard size limit\n* 900kB soft limit\n\nS = block size\nU = UTXO_adjusted_size = S + 4 * outputs - 3 * inputs\n\nA block is valid if S \u003c 1MB and U \u003c 1MB\n\nA 250 byte transaction with 2 inputs and 2 outputs would have an adjusted\nsize of 252 bytes.\n\nThe memory pool could be sorted by fee per adjusted_size.\n\n Coin selection could be adjusted so it tries to have at least 2 inputs\nwhen creating transactions, unless the input is worth more than a threshold\n(say 0.001 BTC).\n\nThis is a pretty weak incentive, especially if the block size is\nincreased.  Maybe it will cause a \"nudge\"\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/0e8a97f2/attachment.html\u003e"}