Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu@gazeta.pl
To: Peter Todd <pete@petertodd.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 vjudeu via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
 Peter Todd <pete@petertodd.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 aaradhya@technovanti.co.in, Aaradhya Chauhan <chauhanansh.me@gmail.com>
In-Reply-To: <BFCDB019-B2D3-4EBF-B31A-FDF6FEAFDFDE@petertodd.org>
Date: Wed, 27 Jul 2022 14:18:56 +0200
Message-Id: <72842561-5e8fd1668dcef89a8b26cb355de840df@pmq6v.m5r2.onet>
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
Precedence: list

> It's pointless for individual nodes to make changes like this on their ow=
n.

It's pointless only if you assume that mining is centralized. And it's poin=
tless if you also assume that there is no batching. By using different sigh=
ashes, batching is definitely possible. In case of one-input-one-output tra=
nsactions, they should use SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, then it is =
possible to grab a lot of such transactions, and combine them all into a si=
ngle transaction, saving some bytes, so fees for each user can be lower tha=
n one satoshi per virtual byte, when it is counted in non-batched version. =
In general, it should be possible to use SIGHASH_ANYONECANPAY by default, a=
nd use SIGHASH_PREVOUT_SOMETHING to make signatures from next transactions =
resistant to changes like adding more inputs and outputs.

> The only time those settings are useful is special situations like miners=
 who want to push txs to their own memlools.

So they could be more useful, if it would be possible to mine a block with =
lower than required difficulty (a share), and be rewarded for that in P2P w=
ay. So, if some miner collected 7 BTC as a reward (6.25 BTC plus 0.75 BTC i=
n fees), then if that miner created 100 times easier block than needed, it =
should be rewarded with 0.07 BTC in a P2P way. And if block rewards are bas=
ed on fees, then it makes perfect sense to collect for example 0.07 BTC in =
transaction fees, and mine it, leaving the rest for other miners, then they=
 will have an incentive to build on top of that.


On 2022-07-27 14:18:21 user Peter Todd <pete@petertodd.org> wrote:
> =


On July 27, 2022 6:10:00 AM GMT+02:00, vjudeu via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
>> So I'd suggest removing the fixed dust limit entirely and relying purely=
 on the mempool size limit to determine what is or is not dust.
>
>Just use those settings in your node:
>
>minrelaytxfee=3D0.00000000
>blockmintxfee=3D0.00000000
>dustrelayfee=3D0.00000000
>
>No changes in source code are needed, nodes can change their limits withou=
t asking anyone. And if some node is a miner, then it can be enforced. But =
if not, then still, free transactions are useful for communication (if more=
 of them will be accepted, then we will switch to negative fee transactions=
 with proper sighashes, then it will be very unlikely that miners will volu=
ntarily add coins, so it will remain useful for communication).

It's pointless for individual nodes to make changes like this on their own.=
 Without like-minded peers this achieves nothing. What is relevant is netwo=
rk wide defaults.

The only time those settings are useful is special situations like miners w=
ho want to push txs to their own memlools. For the _vast_ majority of users=
 changing defaults achieves absolutely nothing.