{"type":"rich","version":"1.0","author_name":"npub149tvqh6gesh22h60jrehl5clrxscx6q65wznq9ty6pae8sxq00esg5vasy","author_url":"https://nostr.ae/npub149tvqh6gesh22h60jrehl5clrxscx6q65wznq9ty6pae8sxq00esg5vasy","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-03-30\n📝 Original message:\u003e The block size itself should be set based on the amount of fees being\npaid to miners to make a block.\n\nThere's a formula to this as well, though going from that to a blocksize\nnumber will be very difficult.  Miner fees need to be sufficient to\nmaintain economic protection against attackers.  There is no reason that\nminer fees need to be any higher than \"sufficient.\"  I believe that\n\"sufficient\" value can be estimated by considering a potential attacker\nseeking to profit from short-selling Bitcoin after causing a panic crash.\nIf they can earn more profit from shorting Bitcoin than it costs to buy,\nbuild/deploy, and perform a 51% attack to shut down the network, then we\nare clearly vulnerable.  The equation for the profit side of the equation\ncan be worked out as:\n\n(bitcoin_price * num_coins_shortable * panic_price_drop_percentage)\n\nThe equation for the cost side of the equation depends on the total amount\nof miner hardware that the network is sustainably paying to operate,\nfactoring in all costs of the entire bitcoin mining lifecycle(HW cost,\ndeployment cost, maintenance cost, electricity, amortized facilities cost,\nbusiness overheads, orphan losses, etc) except chip design, which the\nattacker may be able to take advantage of for free.  For convenience I'm\nsimplifying that complicated cost down to a single number I'm calling\n\"hardware_lifespan\" although the concept is slightly more involved than\nthat.\n\n(total_miner_payouts * bitcoin_price * hardware_lifespan)\n\nBitcoin_price is on boths ides of the equation and so can be divided out,\ngiving:\n\nUnsafe point = (num_coins_shortable * panic_price_drop_percentage) \u003c\n(total_miner_payouts\n* hardware_lifespan)\n\nEstimating the total number of shortable coins an attacker of nearly\nunlimited funds is tricky, especially when things like high leverage levels\nor naked short selling may be offered by exchanges.  The percent of damage\nthe resulting panic would cause is also tricky to estimate, but on both\nnumbers we can make some rough guesses and see how they play out.  With\nmore conservative numbers like say, 2 year hardware lifespan, 10% short,\n70% panic drop you get: 1,300k coins profit, 1800 BTC/day in fees minimum\nneeded to make the attack cost more than it profits.\n\nUsing various inputs and erring on the side of caution, I get a minimum\nBTC/day fee range of 500-2000.  Unfortunately if the blocksize isn't\nincreased, a relatively small number of transactions/users have to bear the\nfull cost of the minimum fees, over time increasing the minimum \"safe\"\naverage fee paid to 0.008 BTC, 30x the fees people are complaining about\ntoday, and increasing in real-world terms as price increases.  All that\nsaid, I believe the costs for node operation are the number that gets hit\nfirst as blocksizes are increased, at least past 2020.  I don't think\nblocksizes could be increased to such a size that the insufficient-fee\nvulnerability would be a bigger concern than high node operational costs.\nThe main thing I don't have a good grasp on at the moment is any math to\nestimate how many nodes we need to protect against the attacks that can\ncome from having few nodes, or even a clear understanding of what those\nattacks are.\n\n\u003e A block so big that 100% of the transactions will always be mined in the\n\u003e next block will just cause a large section of people to no longer feel the\n\u003e need to pay fees.\n\nThis is also totally true.  A system that tried to eliminate the fee\nmarkets would be flawed, and fortunately miners have significant reasons to\noppose such a system.\n\nThe reverse is also a problem - If miners as a large group sought to lower\nblocksizes to force fee markets higher, that could be a problem.  I don't\nhave solutions for the issue at this time, but something I've turned over\nin my mind.\n\nOn Thu, Mar 30, 2017 at 3:30 AM, Tom Zander via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Thursday, 30 March 2017 07:23:31 CEST Ryan J Martin via bitcoin-dev\n\u003e wrote:\n\u003e \u003e      The original post and the assorted limit proposals---lead me to\n\u003e \u003e something I think is worth reiterating: assuming Bitcoin adoption\n\u003e \u003e continues to grow at similar or accelerating rates, then eventually the\n\u003e \u003e mempool is going to be filled with thousands of txs at all times whether\n\u003e \u003e block limits are 1MB or 16MB\n\u003e\n\u003e This is hopefully true. :)\n\u003e\n\u003e There is an unbounded amount of demand for block space, and as such it\n\u003e doesn’t benefit anyone if the amount of free transactions get out of hand.\n\u003e Because freeloaders would definitely be able to completely suffocate\n\u003e Bitcoin.\n\u003e\n\u003e In the mail posted by OP he makes clear that this is a proposal for a hard\n\u003e fork to change the block size *limit*. The actual block size would not be\n\u003e changed at the same time, it will continue being set based on market values\n\u003e or whatever we decide between now and then.\n\u003e\n\u003e The block size itself should be set based on the amount of fees being paid\n\u003e to miners to make a block.\n\u003e\n\u003e What we want is a true fee-market where the miner can decide to make a\n\u003e block\n\u003e smaller to get people to pay more fees, because if we were to go to 16MB\n\u003e blocks in one go, the cost of the miner would go up, but his reward based\n\u003e on\n\u003e fees will go down!\n\u003e A block so big that 100% of the transactions will always be mined in the\n\u003e next block will just cause a large section of people to no longer feel the\n\u003e need to pay fees.\n\u003e\n\u003e As such I don’t fear the situation where the block size limit goes up a lot\n\u003e in one go, because it is not in anyone’s interest to make the actual block\n\u003e size follow.\n\u003e --\n\u003e Tom Zander\n\u003e Blog: https://zander.github.io\n\u003e Vlog: https://vimeo.com/channels/tomscryptochannel\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/dd71b786/attachment-0001.html\u003e"}