path: root/4a/ed4b809b1fccfff32522267751927b80c88907

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4C581C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  5 Mar 2023 22:04:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 133EC60AA5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  5 Mar 2023 22:04:08 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 133EC60AA5
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
 header.a=rsa-sha256 header.s=2013 header.b=znjl+pdF
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id xfJPxI-OCP-a
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  5 Mar 2023 22:04:07 +0000 (UTC)
X-Greylist: delayed 00:05:03 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6D024606EC
Received: from o229.poczta.onet.pl (o229.poczta.onet.pl [213.180.142.229])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 6D024606EC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  5 Mar 2023 22:04:06 +0000 (UTC)
Received: from pmq1v.m5r2.onet (pmq1v.m5r2.onet [10.174.32.67])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4PVFwH0JGszmJn;
 Sun,  5 Mar 2023 22:58:55 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1678053535; bh=6Qfp4I2ncwyrLFuYAphXXEJbdtATS4ZI3UFhVv0VZRQ=;
 h=From:To:Date:Subject:From;
 b=znjl+pdFZGGS80XjM/pEYa4+uof6wjRFIICbOOyloKYS97377/gCFeTZ3R5U9K7IG
 63d3S5W3DbIrZj5QqDVllw56EqR8rvIZfv+v5tHYpAt3UgpUw1FFKOL4XOyBAb4a5L
 P7EiY45SfF/HTKHnJfhl/9lsZwhZdrcL4ovtF0OM=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.232.93] by pmq1v.m5r2.onet via HTTP id ;
 Sun, 05 Mar 2023 22:58:55 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: Andrew Melnychuk Oseen <amo.personal@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Giuseppe B <beppeben2030@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Sun, 05 Mar 2023 22:58:51 +0100
Message-Id: <179086234-135a72949cf38fda9b4e75be5889fe02@pmq1v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.232.93;PL;3
X-Mailman-Approved-At: Wed, 08 Mar 2023 13:18:38 +0000
Subject: Re: [bitcoin-dev] Minimum fees
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Mar 2023 22:04:08 -0000

> I don't know of any data of what happens at the point where the coinbase =
drops to below the fees on any chain. I don't think there has been one wher=
e that has happened. Perhaps there is a chain out there where it is fee's o=
nly? Perhaps that can provide insight.

I think federations like RSK or additional layers like LN can be a good exa=
mple of what happens if there are no additional coins. In RSK, all coins ar=
e backed by BTC, so all you have is what users deposited, or what was Merge=
 Mined, there are no more coins than that. In LN, there are nodes, and chan=
nels are formed only with existing coins, by default there is no mining, so=
 all fees collected by nodes are based only on LN transaction fees (there a=
re ways to reward small miners with LN coins, for example by enabling free =
LN transactions for those miners, or create channels directly by using outp=
uts of the coinbase transaction, but it is not widely used).

Also note that when it comes to other chains, we still have testnet3, where=
 there were more halvings than on the mainnet, because of blockstorms. So, =
if that network will not be resetted, then I guess we will see, how that ne=
twork will behave, when there will be no other coins. For now, you can see =
some users complaining that it is hard to get enough test coins, and with e=
ach halving you can see, how that network is getting closer and closer to t=
he case you want to observe. So, if we want to check, how potential solutio=
ns can solve that problem, using testnet3 will give better results than sig=
net, simply because of more halvings. Also, as testnet3 has blockstorms, it=
 is possible to also test extreme cases with huge reorgs, and see if taking=
 fees from other blocks will still be profitable after introducing proposed=
 changes.

Another important thing to note is that even if coins are worthless, then s=
till, if there are some minimal fees (like one satoshi per virtual byte), t=
hen on-chain amounts simply represents, how many data can be sent by each u=
ser. It means that users can simply send zero satoshis (if there is a need =
to create any additional UTXOs), and place as many coins as they can in the=
ir change addresses, and then the whole game is about having any coins, to =
have the right to broadcast any transaction to the network. Because then, a=
n interesting thing to note is that if there is no coins, then the chain is=
 not going to be halted. It is still possible to create a coinbase transact=
ion with zero coins, and it is still used in all block-based calculations, =
so mining such blocks can prevent other miners from reorging older blocks, =
and taking those fees. And then, if you look at the last miners that had so=
me blocks with fees, then you notice that reaching 100 confirmations can en=
courage them to mine blocks with zero coinbase amount, just to spend their =
rewards.

On 2023-03-04 18:32:01 user Andrew Melnychuk Oseen via bitcoin-dev <bitcoin=
-dev@lists.linuxfoundation.org> wrote:
From my limited knowledge in the space, and I've taken opinions of people =
I respect that are far more knowledgeable than me.


I don't know of any data of what happens at the point where the coinbase dr=
ops to below the fees on any chain. I don't think there has been one where =
that has happened. Perhaps there is a chain out there where it is fee's onl=
y? Perhaps that can provide insight.


Opinion: I think as bitcoin's capabilities grow, demand for it will as well=
. There are a lot of efforts to increase the amount of transactions that ca=
n fit into a block. I think the combination of limited block space and a re=
duced amount of bitcoin's entering the market is the right combination for =
the system to self sustain. I'm looking forward to seeing the result!
=C2=A0
=C2=A0




Sent with Proton Mail secure email.


------- Original Message -------
On Wednesday, March 1st, 2023 at 12:18 PM, Giuseppe B via bitcoin-dev <bitc=
oin-dev@lists.linuxfoundation.org> wrote:


Hello everyone,


I'm relatively new here so what I'm proposing could have already been discu=
ssed, or may be flawed or inapplicable. I apologize for that.


I was picturing a situation where block rewards are almost zero, and the ba=
se layer is mainly used as a settlement layer for relatively few large tran=
sactions, since the majority of smaller ones goes through LN.


In such a case it may very well be that even if transaction amounts are ver=
y consistent, transaction fees end up being very small since there is enoug=
h space for everyone in a block. Users wouldn't mind paying higher fees as =
they know that that would increase the network security, however nobody wan=
ts to be the only one doing that. Miners would of course like being paid mo=
re. So everyone involved would prefer higher fees but they just stay low be=
cause that's the only rational individual choice.


Therefore I was imagining the introduction of a new protocol rule, min_fees=
, that would work like this:
- the miner that gets to mine a block appends a min_fee field to the block,=
 specifying the minimum fees that need to be contained in the following blo=
ck in order for it to be valid.
- one can also mine an empty block and reset the min_fee, to avoid the chai=
n getting stuck.


min_fees could either represent the total fees of the following block, or t=
he minimal fee for each single transaction, as a percentage of the value tr=
ansacted. Both seem to have some merits and some potential drawbacks. Of co=
urse min_fees=3D0 would correspond to the current situation.


It looks to me that this could have the potential to bring the equilibrium =
closer to a socially optimal one (as opposed to individually optimal), and =
to benefit the network security in the long term. Of course it's just a rou=
gh sketch and it would deserve a much deeper analysis. I was just intereste=
d in knowing if you think that the principle has some merit or if it's not =
even worth discussing it for some reason that I'm not considering.


Cheers,


Giuseppe.