{"type":"rich","version":"1.0","author_name":"npub1lupuse8cysuanxcpq8h4d32359xxzedzjj83rmwv4yr9qxfmhtzqghjqch","author_url":"https://nostr.ae/npub1lupuse8cysuanxcpq8h4d32359xxzedzjj83rmwv4yr9qxfmhtzqghjqch","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-12-11\n📝 Original message:The assumption you're making is incorrect. There is not an infinite number\nof low-fee transactions.\n\nYes, the average fee will go down compared to today with Block75, but this\nwill balance itself between demand and the minimum fee miners are willing\nto accept (not zero).\n\nFor example, add 200kb to today's max block size. How does that affect fees?\n(200kb would likely be the first increase if Block75 activated today)\n\n-t.k.\n\nOn Sun, Dec 11, 2016 at 4:55 PM, James Hilliard \u003cjames.hilliard1 at gmail.com\u003e\nwrote:\n\n\u003e I think the main thing you're missing is that there will always be\n\u003e transactions available to mine simply because demand for blockspace is\n\u003e effectively unbounded as fees approach 0. Nodes generally have a\n\u003e static mempool size and dynamic minrelaytxfee nowadays so as\n\u003e transactions get mined lower fee transactions get accepted into the\n\u003e mempool. An individual opting to not send a transaction would not make\n\u003e the blocks smaller simply because there will always be other\n\u003e transactions available(it would really only have an effect on the\n\u003e transaction fees needed to get mined).\n\u003e\n\u003e On Sun, Dec 11, 2016 at 3:40 PM, t. khan \u003cteekhan42 at gmail.com\u003e wrote:\n\u003e \u003e\n\u003e \u003e On Sun, Dec 11, 2016 at 3:31 PM, James Hilliard \u003c\n\u003e james.hilliard1 at gmail.com\u003e\n\u003e \u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e What's most likely to happen is miners will max out the blocks they\n\u003e \u003e\u003e mine simply to try and get as many transaction fees as possible like\n\u003e \u003e\u003e they are doing right now(there will be a backlog of transactions at\n\u003e \u003e\u003e any block size). Having the block size double every year would likely\n\u003e \u003e\u003e cause major problems and this proposal allows over a 7x increase it\n\u003e \u003e\u003e seems.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Block75 is not exponential scaling. It's true the max theoretical\n\u003e increase\n\u003e \u003e in the first year would be 7x, but the next year would be a max of 2x,\n\u003e and\n\u003e \u003e the next could only increase by 50% and so on.\n\u003e \u003e\n\u003e \u003e However, to reach the max in the first year: 1) ALL blocks would have to\n\u003e be\n\u003e \u003e 100% full and 2) transactions would have to increase at the same rate.\n\u003e We'd\n\u003e \u003e have to be doing 2.1 million transactions a day within a year to make\n\u003e that\n\u003e \u003e happen, and would therefore need blocks to be that big.\n\u003e \u003e\n\u003e \u003e Realistically, max block size will grow (and shrink) at a much slower\n\u003e rate\n\u003e \u003e ... even more so with SegWit.\n\u003e \u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e  The main problem with this proposal I think is that users effectively\n\u003e \u003e\u003e\n\u003e \u003e\u003e have no way to stop the miners from increasing block size\n\u003e \u003e\u003e continuously.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Yes they could, simply by not sending transactions. Users don't care at\n\u003e all\n\u003e \u003e about block size. They just want their transactions to be fast and\n\u003e \u003e relatively cheap.\n\u003e \u003e\n\u003e \u003e -t.k.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161211/8822ce40/attachment-0001.html\u003e"}