Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id EEE67C002D for ; Sat, 7 Jan 2023 18:53:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id CBED481E60 for ; Sat, 7 Jan 2023 18:53:00 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org CBED481E60 Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256 header.s=2011 header.b=sthc7DBo X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 2.309 X-Spam-Level: ** X-Spam-Status: No, score=2.309 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LOTS_OF_MONEY=0.001, MONEY_NOHTML=2.499, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MONEY_PERCENT=0.01] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czX4bZxlNzp1 for ; Sat, 7 Jan 2023 18:52:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E069981E21 Received: from smtpa34.poczta.onet.pl (smtpa34.poczta.onet.pl [213.180.142.34]) by smtp1.osuosl.org (Postfix) with ESMTPS id E069981E21 for ; Sat, 7 Jan 2023 18:52:58 +0000 (UTC) Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4Nq8Tt3YTDzlgDBP; Sat, 7 Jan 2023 19:52:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011; t=1673117570; bh=POk0nm+JNV3h+WqlooB2X+5j9g/d0LoJy0JDqNRNt70=; h=From:Cc:To:Date:Subject:From; b=sthc7DBo4oCSzvRTJXptwuoDovG7Tcj/O5sW9lfBk2U1ABQv+9L0Bk1JQpb+beWhI ii44QjGfZI6d90FsBqCrEGjgGS4XDjH/MjBESOzhQQJLMj+XrpQZ58IiJMQ1oqTi06 ssFKA7hCkb5h1l0MNJbqL3DD6kLgtYUheXX3e3vk= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [89.64.64.219] by pmq3v.m5r2.onet via HTTP id ; Sat, 07 Jan 2023 19:52:50 +0100 From: jk_14@op.pl X-Priority: 3 To: Billy Tetrud Date: Sat, 07 Jan 2023 19:52:47 +0100 Message-Id: <174889786-7eefd505bbf223af3d3a1101c7c3044d@pmq3v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;89.64.64.219;PL;2 X-ONET_PL-MDA-SEGREGATION: 0 X-Mailman-Approved-At: Sat, 07 Jan 2023 19:13:02 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2023 18:53:01 -0000 > Anyways if it turns out that fees alone don't look like they're supportin= g enough security, we have a good amount of time to come to that conclusion= and do something about it.=C2=A0 The worst-case scenario is that the first global hashrate regression may ta= ke place in 2028. Instead of the average price increase at least x2 every halving - the globa= l hashrate may gradually decrease from that point. Again, it would be the w= orst-case scenario. In my proposal you don't need to think about any calculations - just simple= logic which we have right now. No hardcoded values and the free market in = its finest - self-regulating the level of taxation of parties involved, but= with opposite interests. And the mechanism would try to fix a global hashr= ate regression if appear. In other words: let's be optimistic regarding fees, but with emergency mech= anism built-in just in case. The only drawback here is that the system is already running. In my personal opinion avoiding long-term global hashrate regression is mor= e important for store of value feature than the 21M schelling point (or tra= p...) W dniu 2023-01-04 17:03:33 u=C5=BCytkownik Billy Tetrud napisa=C5=82: > In Bitcoin "the show must go on" and someone must pay for it. Active [and= /or] passive users=C2=A0 I certainly=C2=A0agree.=C2=A0 > or more precisely: tiny inflation =F0=9F=91=8D > Right now security comes from almost fully from ~1.8% inflation. Best I could find, fees make up about 13% of miner revenue. So yes, the vas= t majority of security comes from coinbase rewards. I assume you're implyin= g that ~13% of today's security is not enough? I would love to see any quan= titative=C2=A0thoughts you have on how one might determine that.=C2=A0 Have there been any thoughts put out in the community as to what size of th= reat is unlikely enough to arise=C2=A0that we don't need to worry about it?= Maybe 1% of the yearly=C2=A0government budgets=C2=A0of the world=C2=A0woul= d be an upper bound on how much anyone would expect could realistically be = brought to bear? Today that would be maybe around $350 billion.=C2=A0 Or perhaps a better way to estimate would be calculating the size of the mo= tivation of an attacker. For example, this paper=C2=A0seems to conclude tha= t the US government was extracting a maximum of ~$20 billion/year in 1982 d= ollars (so maybe $60 billion/year in 2022 dollars if you go by CPI). If we = scale this up to the entire world of governments, this seems like it would = place an upper bound of $180 billion/year of seigniorage extraction that wo= uld be at risk if bitcoin might put the currencies they gain seigniorage fr= om out of business. Over 10 years (about as far as we can expect any govern= ment to think), that's almost $2 trillion.=C2=A0 Whereas it would currently cost probably less than $7 billion=C2=A0to purch= ase a 50% share of bitcoin miners. To eventually reach a level of $350 bill= ion, bitcoin's price would need to reach about $800,000 / bitcoin. That see= ms within the realm of possibility. To reach a level of $2 trillion, you'd = need a price of $4.3 million/bitcoin. That's still probably within the real= m of possibility, but certainly not as likely.=C2=A0 If you then assume we = won't have significant coinbase rewards by that point, and only 13% of the = equivalent revenue (from fees) would be earned, then a price of ~$6 million= would be needed to support a $350 billion and $34 million to support a $2 = trillion security. I think that second one is getting up towards the realm = of impossibility, so if we think that much security is necessary, we might = have to rethink things. Its also quite possible, as the network of people w= ho accept and use bitcoin as payment grows, that the fee market will grow s= uperlinearly in comparison to market cap, which would make these kind of hi= gh levels of security more realistic.=C2=A0 Anyways if it turns out that fees alone don't look like they're supporting = enough security, we have a good amount of time to come to that conclusion a= nd do something about it.=C2=A0 > Deflation in Bitcoin is not 1:1 matter like in gold, for example...=C2=A0= Deflation in Bitcoin is more complex issue It's helpful to keep our language precise here. Price inflation and deflati= on act identically in bitcoin and gold and anything else. What you seem to = be talking about at this point is monetary inflation (specifically, a reduc= tion in it) which of course operates differently on the machinery of bitcoi= n than it does in the machinery of gold or other things. Whereas my comment= about you mentioning Gresham's law was specifically talking about price in= flation, not the effects of the coin emission machinery in bitcoin.=C2=A0 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev