{"type":"rich","version":"1.0","author_name":"npub16wtdr5grjycaw37553u5vvlfq09rwxhzz4kler6pz952a7ny6mtqslgem7","author_url":"https://nostr.ae/npub16wtdr5grjycaw37553u5vvlfq09rwxhzz4kler6pz952a7ny6mtqslgem7","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-12\n📝 Original message:On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Tue, Aug 11, 2015 at 11:35 PM, Michael Naber \u003cmickeybob at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Bitcoin would be better money than current money even if it were a bit\n\u003e\u003e more expensive to transact, simply because of its other great\n\u003e\u003e characteristics (trustlessness, limited supply, etc). However... it is not\n\u003e\u003e better than something else sharing all those same characteristics but which\n\u003e\u003e is also less expensive. The best money will win, and if Bitcoin doesn't\n\u003e\u003e increase capacity then it won't remain the best.\n\u003e\u003e\n\u003e\n\u003e If it is less expensive, it is harder to be reliable (because it's easier\n\u003e for a sudden new use case to outbid the available space), which is less\n\u003e useful for a payment mechanism.\n\u003e\n\nIt depends on which use case's reliability that you focus on. For any\nspecific use case of Bitcoin, that use case will be more reliable with a\nlarger block size (ignoring centralization effects).\n\nThe effect that I think you're talking about is that with lower fees, some\nuse cases will exist that otherwise wouldn't have been possible with higher\nfees / smaller blocks, and these \"low fee only\" use cases will not be as\nreliable as the use cases you'd see with high fees. But that puts you in a\nposition or arguing that it's better that low fee use cases never exist at\nall, than existing at some high risk of being priced out eventually. Do we\nknow with high confidence how high tx fees will be in the future? Should it\nbe up to us discourage low fee use cases from being tried, because we think\nthe risk that they'll later be priced out is too great? Shouldn't we let\nthe people developing those use cases make that call? Maybe they don't mind\nthe unreliability. Maybe it's worth it to them if their use case only lasts\nfor a few months.\n\nThe important point to note is that the reliability of a use case is\ndetermined by the fees that people are willing to pay for that use case,\nnot the fees that are actually paid. If big banks are willing to pay $1 /\ntx for some use case right now, but they only need 200 of these txns per\nblock, then they might be paying only 5 cents / tx because no one is\nforcing them to pay more. The fact that they're only paying 5 cents / tx\nnow doesn't make them any more vulnerable to new use cases than if they\nwere paying $1 / tx now. If a new use case started bidding up tx fees, the\nbanks would just increase their tx fees as high as they needed to (up to\n$1).\n\nThe reason that larger block sizes increase reliability for any given use\ncase is that (a) You will never be priced out of blocks by a use case that\nis only willing to pay lower fees than you. This is true regardless of the\nblock size. At worst they'll just force you to pay more in fees and lose\nsome of your consumer surplus. (b) If a use case is willing to pay higher\nfees than you, then they're basically stepping ahead of you in line for\nblock space and pushing you closer to the edge of not being included in\nblocks. The more space that exists between your use case and the marginal\nuse cases that are just barely getting included in blocks, the less\nvulnerable you are to getting pushed out of blocks by new use cases.\n\nIf this is tricky to understand, here's an example that will make it clear:\n\nAssume blocks can hold 2000 txns per MB. Before the new use case is\ndiscovered, demand looks like this:\n\n500 txns will pay $1 fees\n1000 txns will pay 50 cent fees\n2000 txns will pay 5 cent fees\n8000 txns will pay 2 cent fees\n15,000 txns will pay 1 cent fees.\n100,000 txns will pay 0.01 cent fees.\n\nSo at a block size of 1MB, fees are 5 cents and user surplus is $925 per\nblock ($0.95 * 500 + 0.45 * 1000).\nAt a block size of 8 MB, fees are 1 cent and user surplus is $1,145 per\nblock ($0.99 * 500 + 0.49 * 1000 + $0.04 * 2000 + $0.01 * 8000).\n\nNow a new use case comes into play and this is added to demand:\n\n3000 txns will pay $5 / tx\n\nThat demand changes the scenarios like such:\n\nAt 1 MB fees jump to $5, user surplus is $0, and the $925 of value the\nprevious users were getting is lost. All existing use cases are priced out,\nbecause there wasn't enough room in the blocks to accommodate them plus\nthis new use case.\n\nAt 8 MB, fees would stay at 1 cent, user surplus would be $16,115, and $0\nin value would be lost (3000 users who were paying 1 cent for txns that\nthey valued only at 1 cent would stop making txns). All use cases\ncorresponding to the txns that were willing to pay at least 2 cents are\nstill viable, because there was enough space in blocks to accommodate them\nplus the 3000 new high fee txns.\n\nLet's say you're running the service that represents the 2000 txns willing\nto pay 5 cents each on the demand curve specified above. Let's say you're\nworried about being priced out of blocks. Which situation do you want to be\nin, the one with 1 MB blocks or 8 MB blocks? It's pretty clear that your\nbest chance to remain viable is with larger blocks.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/7e2e6848/attachment-0001.html\u003e"}