From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3CD9BC002D for ; Wed, 27 Jul 2022 12:19:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 1792E40424 for ; Wed, 27 Jul 2022 12:19:06 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1792E40424 Authentication-Results: smtp2.osuosl.org; dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl header.a=rsa-sha256 header.s=2013 header.b=dLHozaD1 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtNKHDjQi-mY for ; Wed, 27 Jul 2022 12:19:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 937EB40165 Received: from smtpo53.poczta.onet.pl (smtpo53.poczta.onet.pl [213.180.142.184]) by smtp2.osuosl.org (Postfix) with ESMTPS id 937EB40165 for ; Wed, 27 Jul 2022 12:19:04 +0000 (UTC) Received: from pmq6v.m5r2.onet (pmq6v.m5r2.onet [10.174.33.77]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4LtCW42CzgzmKJ; Wed, 27 Jul 2022 14:18:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1658924336; bh=KsVcyj7pwBNudwV/ztokfnhARCPBO17AojfxWDZSDiE=; h=From:To:In-Reply-To:Date:Subject:From; b=dLHozaD1E2ARgq8K4FaiVICvRMlTzdwdlA5D0ecs75qmLW7YmL5xRY8YEqoURtA8t QGzf8iQgqsnQmrIUIg+/HHvN6JhEsmFa6kpCHOdKE0qKfyjAuIVuEMDKv9ElFxthSj AX5bcqj4txfwYLCARLwyY7GLZ3d+CU38LdixUpqk= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [82.177.167.2] by pmq6v.m5r2.onet via HTTP id ; Wed, 27 Jul 2022 14:18:56 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: Peter Todd , Bitcoin Protocol Discussion , vjudeu via bitcoin-dev , Peter Todd , Bitcoin Protocol Discussion , aaradhya@technovanti.co.in, Aaradhya Chauhan In-Reply-To: Date: Wed, 27 Jul 2022 14:18:56 +0200 Message-Id: <72842561-5e8fd1668dcef89a8b26cb355de840df@pmq6v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;82.177.167.2;PL;4 X-Mailman-Approved-At: Wed, 27 Jul 2022 14:28:14 +0000 Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee 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: Wed, 27 Jul 2022 12:19:06 -0000 > 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 wrote: > = On July 27, 2022 6:10:00 AM GMT+02:00, vjudeu via bitcoin-dev 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.