{"type":"rich","version":"1.0","author_name":"npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","author_url":"https://nostr.ae/npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-01-04\n🗒️ Summary of this message: tionary Bitcoin relies heavily on coinbase rewards for security, with fees making up only a small portion. The cost of a 50% attack is currently less than $7 billion, but if Bitcoin's security needs increase to $2 trillion, a price of $4.3 million/bitcoin would be required. The fee market may grow superlinearly as Bitcoin adoption increases, making high levels of security more realistic.\n📝 Original message:\u003e In Bitcoin \"the show must go on\" and someone must pay for it. Active\n[and/or] passive users\n\nI certainly agree.\n\n\u003e or more precisely: tiny inflation\n\n👍\n\n\u003e Right now security comes from almost fully from ~1.8% inflation.\n\nBest I could find, fees make up about 13% of miner revenue\n\u003chttps://decrypt.co/57740/bitcoin-miners-now-earn-1-btc-in-fees-per-block\u003e.\nSo yes, the vast majority of security comes from coinbase rewards. I assume\nyou're implying that ~13% of today's security is not enough? I would love\nto see any quantitative thoughts you have on how one might determine that.\n\nHave there been any thoughts put out in the community as to what size of\nthreat is unlikely enough to arise that we don't need to worry about it?\nMaybe 1% of the yearly government budgets\n\u003chttps://en.wikipedia.org/wiki/List_of_countries_by_government_budget\u003e of\nthe world would be an upper bound on how much anyone would expect could\nrealistically be brought to bear? Today that would be maybe around $350\nbillion.\n\nOr perhaps a better way to estimate would be calculating the size of the\nmotivation of an attacker. For example, this paper\n\u003chttps://files.stlouisfed.org/files/htdocs/publications/review/92/03/Seigniorage_Mar_Apr1992.pdf\u003e\nseems\nto conclude that the US government was extracting a maximum of ~$20\nbillion/year in 1982 dollars (so maybe $60 billion/year in 2022 dollars if\nyou go by CPI). If we scale this up to the entire world of governments,\nthis seems like it would place an upper bound of $180 billion/year of\nseigniorage extraction that would be at risk if bitcoin might put the\ncurrencies they gain seigniorage from out of business. Over 10 years (about\nas far as we can expect any government to think), that's almost $2\ntrillion.\n\nWhereas it would currently cost probably less than $7 billion to purchase a\n50% share of bitcoin miners. To eventually reach a level of $350 billion,\nbitcoin's price would need to reach about $800,000 / bitcoin. That seems\nwithin the realm of possibility. To reach a level of $2 trillion, you'd\nneed a price of $4.3 million/bitcoin. That's still probably within the\nrealm of possibility, but certainly not as likely.  If you then assume we\nwon't have significant coinbase rewards by that point, and only 13% of the\nequivalent revenue (from fees) would be earned, then a price of ~$6 million\nwould be needed to support a $350 billion and $34 million to support a $2\ntrillion security. I think that second one is getting up towards the realm\nof impossibility, so if we think that much security is necessary, we might\nhave to rethink things. Its also quite possible, as the network of people\nwho accept and use bitcoin as payment grows, that the fee market will grow\nsuperlinearly in comparison to market cap, which would make these kind of\nhigh levels of security more realistic.\n\nAnyways if it turns out that fees alone don't look like they're supporting\nenough security, we have a good amount of time to come to that conclusion\nand do something about it.\n\n\u003e Deflation in Bitcoin is not 1:1 matter like in gold, for example...\nDeflation in Bitcoin is more complex issue\n\nIt's helpful to keep our language precise here. Price inflation and\ndeflation act identically in bitcoin and gold and anything else. What you\nseem to be talking about at this point is monetary inflation (specifically,\na reduction in it) which of course operates differently on the machinery of\nbitcoin than it does in the machinery of gold or other things. Whereas my\ncomment about you mentioning Gresham's law was specifically talking about\nprice inflation, not the effects of the coin emission machinery in bitcoin.\n\nOn Mon, Jan 2, 2023 at 5:02 PM \u003cjk_14 at op.pl\u003e wrote:\n\n\u003e\n\u003e\n\u003e Right now security comes from almost fully from ~1.8% inflation.\n\u003e In November mempool was inflated to ~150MB and people were rather waiting\n\u003e for cheap transactions back.\n\u003e Instead of being happy that system is closer for a while to default\n\u003e working area.\n\u003e\n\u003e Deflation in Bitcoin is not 1:1 matter like in gold, for example.\n\u003e If all plain gold available to mine would be finished - gold mines as\n\u003e unprofitable enterprices are immediately closed.\n\u003e And it doesn't affect security of gold already in circulation.\n\u003e In Bitcoin \"the show must go on\" and someone must pay for it.\n\u003e Active and passive users together (balanced by market play) or: only\n\u003e active users (in current scenario, long-term).\n\u003e\n\u003e Deflation (or more precisely: tiny inflation) in Bitcoin is more complex\n\u003e issue with more repercussions than in gold.\n\u003e In case of drop of network security - the tax will be paid anyway, in\n\u003e Bitcoin price.\n\u003e So, there is an self-regulating mechanism here. The harsh one, but still.\n\u003e\n\u003e\n\u003e\n\u003e W dniu 2023-01-02 05:53:57 użytkownik Billy Tetrud \u003cbilly.tetrud at gmail.com\u003e\n\u003e napisał:\n\u003e \u003e is surely better than not delaying it.\n\u003e\n\u003e I might agree, but I don't think it really solves the problem well enough\n\u003e to be worth it. Any solution that would solve the problem better would make\n\u003e delaying halvings unnecessary.\n\u003e\n\u003e \u003e there is non-zero risk that people will hoard it more and more,\n\u003e according to old Gresham's law\n\u003e\n\u003e\n\u003e Gresham's law doesn't apply here. Gresham's law is about the interaction\n\u003e between two currencies with a fixed, usually government-enforced exchange\n\u003e rate. You seem to be saying that Bitcoin will be hoarded because Bitcoin\n\u003e inflation reduces every halving. But even with 0 inflation, it certainly\n\u003e won't cause all Bitcoin to be hoarded. Also, \"hoarding\" is also known as\n\u003e \"saving\", and there's nothing wrong with saving. The spectre of deflation\n\u003e comes from a misunderstanding of deflation and why it happens during bad\n\u003e economic times. It is an effect, not a cause.\n\u003e\n\u003e\n\u003e On Sun, Jan 1, 2023, 15:23 \u003cjk_14 at op.pl\u003e wrote:\n\u003e\n\u003e Yes, the idea is:\n\u003e if mining activity is growing - let's execute consecutive halvings\n\u003e but if miner exodus has happened - let's delay next halving until mining\n\u003e activity is recovered to previous levels\n\u003e\n\u003e If it gets to the point where a sudden drop in mining difficulty happens -\n\u003e delaying the next halving may be not sufficient to correct, but is surely\n\u003e better than not delaying it.\n\u003e\n\u003e While Bitcoin is better and better money with every halving in comparision\n\u003e to other types of money - there is non-zero risk that people will hoard it\n\u003e more and more, according to old Gresham's law (\"HODL\"). And this way\n\u003e decreasing liquidity / transactions volume. The positive feedback loop - is\n\u003e my real concern here.\n\u003e\n\u003e Regarding the relationship between difficulty and security - I fully agree.\n\u003e But ASIC technology is already matured. And also any technology\n\u003e breakthrough is a short event within 4 years period.\n\u003e So growth of difficulty could be gained by technology breakthrough, but\n\u003e any sudden drop of difficulty would be always an issue, while there is no\n\u003e such thing as: ASIC technology regression.\n\u003e\n\u003e Obviously, not complicated solution would be better than complicated one.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e W dniu 2022-12-30 19:21:10 użytkownik Billy Tetrud \u003cbilly.tetrud at gmail.com\u003e\n\u003e napisał:\n\u003e If the idea is to ensure that a catastrophic miner exodus doesn't happen,\n\u003e the \"difference\" you're calculating should only care about downward\n\u003e differences. Upward differences indicate more mining activity and so\n\u003e shouldn't cause a halving skip.\n\u003e\n\u003e\n\u003e But I don't think any scheme like this that only acts on the basis of\n\u003e difficulty will be sufficient. If it gets to the point where a sudden drop\n\u003e in mining difficulty happens, it is very likely that simply delaying the\n\u003e next halving or even ending halving all together will not be sufficient to\n\u003e correct for whatever is causing hashrate to tank. There is also the danger\n\u003e of simple difficulty stagnation, which this mechanism wouldn't detect.\n\u003e\n\u003e\n\u003e The relationship between difficulty and security becomes less and less\n\u003e predictable the longer you want to look ahead. There's no long term\n\u003e relation between difficulty and any reasonable security target. A security\n\u003e target might be something like \"no colluding group with less than $1\n\u003e trillion dollars at their disposal could successfully 51% attack the\n\u003e network (with a probability of blah blah)\". There is no way to today\n\u003e program in any code that detects based on difficult alone when that\n\u003e criteria is violated. You would have to program in assumptions about the\n\u003e cost of hashrate projected into the future.\n\u003e\n\u003e\n\u003e I can't think of any robust automatic way to do this. I think to a certain\n\u003e degree, it will have to be a change that happens in a fork of some kind\n\u003e (soft or hard) periodically (every 10 years? 30 years?). The basic\n\u003e relations needed is really the cost in Bitcoin of the security target (ie\n\u003e the minimum number of Bitcoin it should take to 51% attack the system) and\n\u003e the cost in Bitcoin of acquiring a unit of hashrate. This could be simply\n\u003e input into the code, or could use some complicated oracle system. But with\n\u003e that relation, the system could be programmed to calculate the difficulty\n\u003e necessary to keep the system secure.\n\u003e\n\u003e\n\u003e Once that is in place, the system could automatically adjust the subsidy\n\u003e up or down to attract more or less miners, or it could adjust the block\n\u003e size up or down to change the fee market such that more or less total fees\n\u003e are collected each block to attract more or less miners.\n\u003e\n\u003e\n\u003e On Tue, Dec 27, 2022, 09:41 Jaroslaw via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e It seems like the more elegant solution could be by using a chainwork\n\u003e parameter instead.\n\u003e i.e. comparison just before halving - if the last 210,000 block interval\n\u003e has a higher chainwork difference between the begining and the end of\n\u003e interval\n\u003e than any other such inter-halving interval before.\n\u003e\n\u003e LIttle digression yet:\n\u003e A system in which all users participate in ensuring its security looks\n\u003e better than one in which only some (i.e. active) of them participate (and\n\u003e passive stakeholders are de facto free riders)\n\u003e In my opinion this concept above is only the complement of currently\n\u003e missing mechanism: achieving equilibrium regarding costs of security\n\u003e between two parties with opposing interests.\n\u003e It's easy to understand and - most important - it has no hardcoded value\n\u003e of tail emission - what is the clear proof it is based on a free market.\n\u003e And last but not least, if someone is 100% sure that income from\n\u003e transactions will takeover security support from block subsidy - accepting\n\u003e such proposal is like putting the money where the mouth is: this safety\n\u003e measure will never be triggered, then (no risk of fork)\n\u003e\n\u003e\n\u003e Best Regards\n\u003e Jaroslaw\n\u003e\n\u003e\n\u003e\n\u003e W dniu 2022-12-23 20:29:20 użytkownik Jaroslaw via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e napisał:\n\u003e \u003e\n\u003e Necessary or not - it doesn't hurt to plan the robust model, just in case.\n\u003e The proposal is:\n\u003e\n\u003e Let every 210,000 the code calculate the average difficulty of 100 last\n\u003e retargets (100 fit well in 210,000 / 2016 = 104.166)\n\u003e and compare with the maximum of all such values calculated before, every\n\u003e 210,000 blocks:\n\u003e\n\u003e\n\u003e if average_diff_of_last_100_retargets \u003e\n\u003e maximum_of_all_previous_average_diffs\n\u003e         do halving\n\u003e else\n\u003e         do nothing\n\u003e\n\u003e\n\u003e This way:\n\u003e\n\u003e 1. system cannot be played\n\u003e 2. only in case of destructive halving: system waits for the recovery of\n\u003e network security\n\u003e\n\u003e\n\u003e Best Regards\n\u003e Jaroslaw\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\u003e\n\u003e\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\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230104/dfb173d9/attachment-0001.html\u003e"}