Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1D6A0C002D for ; Thu, 14 Jul 2022 04:55:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id E59C14249C for ; Thu, 14 Jul 2022 04:55:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E59C14249C Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=EKnCL3NS X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qlVISI3qAod for ; Thu, 14 Jul 2022 04:55:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9F991422EA Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by smtp4.osuosl.org (Postfix) with ESMTPS id 9F991422EA for ; Thu, 14 Jul 2022 04:55:53 +0000 (UTC) Received: by mail-pf1-x435.google.com with SMTP id d10so834242pfd.9 for ; Wed, 13 Jul 2022 21:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jKeW4/53BiCzNGc/e4qKnNznsWhcng+nTWILwX5lkss=; b=EKnCL3NS4cR9b08hVibX8XNRDo4sLoLtQcHpvADrt/T6YrQP1dK3BYAM1nPFLjfsT4 y/aISU6NBe4nx1SmakyZjVJALuhA79wwMVa1vKhiaeaHKh8GREmgKtBjxPofrqq9MuoS Xq2O9TqdtH1chfODPMwtQY/SSSOyX2Pygrx7dii8P+0wG8RC9WyM8Qtrgn/r09WHOK3m WdosBpdW5VFEGAKhGL+ICKlkMWytpawE8AIIvtqgR+l8dnrKnWBp/0ofMOElcdXbjqCq HaTG/2Z8fXTHNUiD5La0uNwiOf30A2m+gkggNLasyrEPof0i0q9MYoahykgxa7P9HmnM adDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jKeW4/53BiCzNGc/e4qKnNznsWhcng+nTWILwX5lkss=; b=uYdFfybFvKE+SG3ptKe3btxeBHAGc6jmUlfDjeL4JE4ntlO7wdUeZxKNEeVeqvcQG7 BSbsaxPJ/TIzuzLGNgXkOTHx/Cdrv9w0syRWxKqjmRw954L147jlVNafO4zmH8jNfvZQ BlxoJLqXAgZELHYfOOHDMLILlFsgtk69dSC+w8LkPIvNy1BeYoH7/o4GzAYpw0iJJ44x cBGhlbANoba+tp781+73lMTPf8Hx5n2Dgr6C7WKwJz3/iPhjm4AFHaJ6ss1MfnpUlR9R oSRCEESTNXbhpfwH5qJsxjuGE19RRvRBVLu9O+QuHAz3RdkQl9oPgMpX4skNbUfMYRSH 0ohQ== X-Gm-Message-State: AJIora9xEmeuPMNNC46nPYiTk6C50CtguGsxZXMPyMnO9Czcn7tFCunv d99i6P+yCijdq5yJTJprJmYyFVelrhrk55i3gHwlvD6Fkts= X-Google-Smtp-Source: AGRyM1utCas+kyaFykeUZYrEBbHYuknOkpY6Tf/ucv6DbQ7vy2aCr6ViIeBnwuybfAZfFvwP9UPt1TDK4YbOD+QLmRA= X-Received: by 2002:a65:6bcb:0:b0:412:a68d:1083 with SMTP id e11-20020a656bcb000000b00412a68d1083mr6117769pgw.456.1657774551863; Wed, 13 Jul 2022 21:55:51 -0700 (PDT) MIME-Version: 1.0 References: <96371DBA-F484-4538-9E12-9D6AB90AF22C@voskuil.org> In-Reply-To: From: Billy Tetrud Date: Wed, 13 Jul 2022 23:55:35 -0500 Message-ID: To: Erik Aronesty , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000048163c05e3bcb7a6" X-Mailman-Approved-At: Thu, 14 Jul 2022 09:31:49 +0000 Cc: John Carvalho Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable 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: Thu, 14 Jul 2022 04:55:56 -0000 --00000000000048163c05e3bcb7a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Peter Todd > The fact of the matter is that the present amount of security is about 1.7% of the total coin supply/year That's on the order of what I calculated : ~0.5%. I'm curious where the 1.7% number comes from. Perhaps much of the difference in our two numbers likely comes from me incorporating what I call the "Economic Mining Monopoly Attack" which effectively cuts the security in half. > There's zero reason to stress about finding an "optimal" amount. An amount low enough to be easily affordable, but non-zero, is fine. That's fair. What I mean is that we should estimate an optimal value to some degree of accuracy. It doesn't have to be super accurate. But too low and we could have a bad time. Too high and its a deadweight cost forever (which increases fees, slows adoption, and causes an inflation-like devaluation force on bitcoin, which has all the familiar market distorting effects, albeit to a much smaller degree than we're used to). In any case, we need to come to an accurate enough estimate of how much is enough security so that we ensure we're above that amount. > These are all amounts that are likely to be dwarfed by economic shifts. Perhaps you're right. Regardless, its certainly an improvement to what we've had the last 100 years. @Erik Voskuil > You cannot support the blanket statement (and absent any assumption) that lower confirmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or =E2= =80=9Cbetter security=E2=80=9D. I can in fact support it. The theory of supply and demand supports it. Well, depending on what you mean by "fees". Reducing the block size will certainly increase average fees/vbyte. Whether it increases total fees collected by miners (and thus lead to "better security") is another story - a story that depends on the demand dynamics in the market. It could very well be that reducing the blocksize reduces the number of transactions by a higher proportion than fees go up. As we have seen in past periods of high traffic tho, total fees go up *quite* a lot. So it seems pretty clear to me that constraining the block size would very likely increase total fees collected by miners, at least for the near future. @Carvalho > I will reiterate. Proof of work and the difficulty adjustment scheme already solve all of these issues You haven't addressed any of the comments that disagree with you above. You didn't address any of my comments originally. You are simply claiming things without any logical support. If you want to be a respectable part of this conversation, I'd recommend explaining yourself much more thoroughly. > That restaurant is too popular, nobody goes there anymore. If you could feed 100,000 people with 1 entire from a restaurant, your restaurant might not make enough money to survive despite feeding the entire country. That's what the lightning network does for/to bitcoin. We need to make sure the restaurant can afford to staff itself despite massive increases in food-use efficiency. On Fri, Jul 8, 2022 at 12:32 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil wrote: > >> Value is subjective, though a constraint of 1tx per 10 minutes seems >> unlikey to create a fee of 5000x that of 5000tx. This is of course why I >> stated my assumption. Yet this simple example should make clear that at >> some point a reduction in confirmation rate reduces reward. Otherwise a >> rate of zero implies infinite reward. >> > > Like i said, it's not linear. So no, a rate of 0 does not imply an > infinite reward. A number of papers on the Nash equilibrium of mining > rewards and block size have been written. There are block sizes tha= t > are optimal for fees, and they obviously not zero, where the system > collapses, and they are obviously not infinite... where all bidders pay 1 > sat/byte. > > >> >> You cannot support the blanket statement (and absent any assumption) tha= t >> lower confirmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or = =E2=80=9Cbetter security=E2=80=9D. >> > > You can look at the research and the history of zero-size block impact on > fees and see that this is true. > > > >> >> What you call a =E2=80=9Cbidding war=E2=80=9D is merely market pricing, = as it occurs with >> any good. People *always* will pay as much as they will pay. This is >> tautological. What you cannot say is how much more someone will pay at a= ny >> given time for any given good, until they have done it. And I=E2=80=99m = pretty sure >> Bitcoin hasn=E2=80=99t done it. >> > > If there is infinite supply, then there is zero value. Infinite blocks > have lower fees. This is impossible to argue against. > > >> You cannot prove what the price of anything will be, nor can any >> =E2=80=9Cpapers=E2=80=9D. The absurdity of S2F should have clearly demon= strated that by >> now. Value is an individual human preference. >> > > A trivial example: block sizeof 10, and 10 people want to transact, all > can bid 1 SAT/byte, 2 tx are moving 100 mil sats, the other 8 are moving = 10 > mil sats. Block size of 2. Now the two transactions moving 100 mil sat= s > will bid, they can easily pay 400 sats/byte. > > You can show, from history, that when block sizes are more constrained, > due to the mining of zero byte blocks, total fees were higher. People > will always pay for "next confirm" if the cost of that is very reasonable > (less than 0.1%). > >> >> If everyone pays 1 sat, then either miners are profitable at 1 sat, or >> these people are not getting confirmed (economic rationality always >> assumed). >> > > Yes, and if miners are not profitable at 1 sat, then they will not mine, > and the hash rate will drop. And this reduces the security of the coin. > Hashrate is an index of security. > > But there is of course no real issue here. Simply fork off an inflation >> coin and test your theory. I mean, that=E2=80=99s the only way it can ha= ppen anyway. >> > > I would argue inflation is not a good solution. Instead, being cautious > about block-compressing tech, like mweb, and being more aggressive about > fee-driving tech, makes more sense . > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000048163c05e3bcb7a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Peter Todd

> The fact of the ma= tter is that the present amount of security is about 1.7% of
the total c= oin supply/year

That's on the order of what I calculated: ~0.5%. I= 'm curious where the 1.7% number comes from.=C2=A0 Perhaps much of the = difference in our two numbers likely comes from me incorporating what I cal= l the "Economic Mining Monop= oly Attack" which effectively=C2=A0cuts the security in half.=C2= =A0

> There's zero reason to stress about finding an "op= timal" amount. An amount low enough to be easily affordable, but non-z= ero, is fine.=C2=A0

That's fair. What I mean i= s that we should estimate an optimal value to some degree of accuracy. It d= oesn't have to be super accurate. But too low and we could have a bad t= ime. Too high and its=C2=A0a deadweight cost forever (which increases fees,= slows adoption, and causes an inflation-like devaluation force on bitcoin,= which has all the familiar=C2=A0market distorting effects, albeit to a muc= h smaller degree than we're used to).=C2=A0 In any case, we need to com= e to an accurate enough estimate of how much is enough security so that we = ensure we're above that amount.=C2=A0

> These are all amounts= that are likely to be dwarfed by economic shifts.

=
Perhaps you're right. Regardless, its certainly an improvement to = what we've had the last 100 years.=C2=A0

@Erik= Voskuil
>=C2=A0You canno= t support the blanket statement (and absent any assumption) that lower conf= irmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or =E2=80=9Cbette= r security=E2=80=9D.

=
I can in fact support it= . The theory of supply and demand supports it. Well, depending on what you = mean by "fees". Reducing the block size will certainly increase a= verage fees/vbyte. Whether it increases total fees collected by miners (and= thus lead to "better security") is another story - a story that = depends on the demand dynamics in the market. It could very well be that re= ducing the blocksize reduces the number of transactions by a higher proport= ion than fees go up. As we have seen in past periods of high traffic tho, t= otal fees go up *quite* a lot. So it seems pretty clear to me that constrai= ning the block size would very likely increase total fees collected by mine= rs,=C2=A0at least for the near future.

@Carva= lho
>=C2=A0=C2=A0I w= ill reiterate. Proof of work and the difficulty adjustment scheme already s= olve all of these issues

You haven't addressed= any of the comments that disagree with you above. You didn't address a= ny of my comments originally. You are simply claiming things without any lo= gical support. If you want to be a respectable part of this conversation, I= 'd recommend explaining yourself much more thoroughly.

> That restaurant is too popular, nobody goes there anymore.

If you could feed 100,000 people with 1 entire from = a restaurant, your restaurant might not make enough money to survive despit= e feeding the entire country. That's what the lightning network does fo= r/to bitcoin. We need to make sure the restaurant can afford to staff itsel= f despite massive increases in food-use efficiency.=C2=A0

On Fri, Jul = 8, 2022 at 12:32 PM Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Value is subjective, though a con= straint of 1tx per 10 minutes seems unlikey to create a fee of 5000x that o= f 5000tx. This is of course why I stated my assumption. Yet this simple exa= mple should make clear that at some point a reduction in confirmation rate = reduces reward. Otherwise a rate of zero implies infinite reward.=C2=A0

Like i said, it's not li= near.=C2=A0 =C2=A0So no, a rate of 0 does not imply an infinite reward.=C2= =A0 A number of papers on the Nash equilibrium of mining rewards and block = size have been written.=C2=A0 =C2=A0 =C2=A0 =C2=A0There are block sizes tha= t are optimal for fees,=C2=A0and they obviously not zero, where the system = collapses, and they are obviously not infinite... where all bidders pay 1 s= at/byte.
=C2=A0

You cannot support the blan= ket statement (and absent any assumption) that lower confirmation rates pro= duce =E2=80=9Cmuch higher fees=E2=80=9D or =E2=80=9Cbetter security=E2=80= =9D.

You can look at the = research and the history of zero-size block impact on fees and see that thi= s is true.

=C2=A0

What you call a = =E2=80=9Cbidding war=E2=80=9D is merely market pricing, as it occurs with a= ny good. People *always* will pay as much as they will pay. This is tautolo= gical. What you cannot say is how much more someone will pay at any given t= ime for any given good, until they have done it. And I=E2=80=99m pretty sur= e Bitcoin hasn=E2=80=99t done it.

If there is infinite supply, then there is zero value.=C2=A0 =C2= =A0Infinite blocks have lower fees.=C2=A0 This is impossible to argue again= st.

<= div dir=3D"auto">

You cannot prove what the price of anythin= g will be, nor can any =E2=80=9Cpapers=E2=80=9D. The absurdity of S2F shoul= d have clearly demonstrated that by now. Value is an individual human prefe= rence.

A trivial exa= mple: block sizeof 10, and 10 people want to transact, all can bid 1 SAT/by= te, 2 tx are moving 100 mil sats, the other 8 are moving 10 mil sats.=C2=A0= =C2=A0Block size of 2.=C2=A0 Now the two transactions moving=C2=A0100 mil = sats will bid,=C2=A0they can easily pay 400 sats/byte.=C2=A0 =C2=A0

You can show, from history, that when block siz= es are more constrained, due to the mining of zero byte blocks, total fees = were higher.=C2=A0 =C2=A0People will always pay for "next confirm"= ; if the cost of that is very reasonable (less than 0.1%).=C2=A0

If everyone pays 1 sat, then either miners are profitable at 1 sat, or = these people are not getting confirmed (economic rationality always assumed= ).

Yes, and if miners are= not profitable at 1 sat, then they will not mine, and the hash rate will d= rop.=C2=A0 =C2=A0And this reduces the security of the coin.=C2=A0 =C2=A0Has= hrate is an index of security.

But there is of course no real issue here. Simply fork of= f an inflation coin and test your theory. I mean, that=E2=80=99s the only w= ay it can happen anyway.

<= div>I would argue inflation is not a good solution.=C2=A0 =C2=A0Instead, be= ing cautious about block-compressing tech, like mweb, and being more aggres= sive about fee-driving tech, makes more sense .

<= /div> _______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000048163c05e3bcb7a6--