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>
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
Date: Wed, 27 Jul 2022 14:18:56 +0200 [thread overview]
Message-ID: <72842561-5e8fd1668dcef89a8b26cb355de840df@pmq6v.m5r2.onet> (raw)
In-Reply-To: <BFCDB019-B2D3-4EBF-B31A-FDF6FEAFDFDE@petertodd.org>
> It's pointless for individual nodes to make changes like this on their own.
It's pointless only if you assume that mining is centralized. And it's pointless if you also assume that there is no batching. By using different sighashes, batching is definitely possible. In case of one-input-one-output transactions, they should use SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, then it is possible to grab a lot of such transactions, and combine them all into a single transaction, saving some bytes, so fees for each user can be lower than 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, and 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 way. So, if some miner collected 7 BTC as a reward (6.25 BTC plus 0.75 BTC in 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 based 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=0.00000000
>blockmintxfee=0.00000000
>dustrelayfee=0.00000000
>
>No changes in source code are needed, nodes can change their limits without 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 voluntarily 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 network wide defaults.
The only time those settings are useful is special situations like miners who want to push txs to their own memlools. For the _vast_ majority of users changing defaults achieves absolutely nothing.
next prev parent reply other threads:[~2022-07-27 12:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-26 8:26 Aaradhya Chauhan
2022-07-26 12:19 ` alicexbt
2022-07-26 14:27 ` Peter Todd
2022-07-26 19:14 ` alicexbt
2022-07-26 12:45 ` Peter Todd
2022-07-27 4:10 ` vjudeu
2022-07-27 11:50 ` Peter Todd
2022-07-27 12:18 ` vjudeu [this message]
2022-07-29 3:38 ` David A. Harding
2022-07-29 18:59 ` Aaradhya Chauhan
2022-07-30 7:55 ` Aaradhya Chauhan
2022-07-30 17:24 ` alicexbt
2022-08-01 10:30 ` Peter Todd
2022-08-01 13:19 ` aliashraf.btc At protonmail
2022-08-01 13:37 ` Peter Todd
2022-08-03 15:40 ` Aaradhya Chauhan
2022-08-03 17:07 ` vjudeu
2022-08-03 18:22 ` Aaradhya Chauhan
2022-08-04 1:21 ` Billy Tetrud
2022-07-30 10:20 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=72842561-5e8fd1668dcef89a8b26cb355de840df@pmq6v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=aaradhya@technovanti$(echo .)co.in \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=chauhanansh.me@gmail$(echo .)com \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox