From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 23DE9C002D for ; Wed, 3 Aug 2022 17:07:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id E0310828DE for ; Wed, 3 Aug 2022 17:07:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E0310828DE Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl header.a=rsa-sha256 header.s=2013 header.b=qmBxFLmS X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsJD1btUp6p4 for ; Wed, 3 Aug 2022 17:07:19 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5FFA1828DD Received: from smtpo115.poczta.onet.pl (smtpo115.poczta.onet.pl [213.180.149.168]) by smtp1.osuosl.org (Postfix) with ESMTPS id 5FFA1828DD for ; Wed, 3 Aug 2022 17:07:17 +0000 (UTC) Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4LydZQ1kjHzlj670; Wed, 3 Aug 2022 19:07:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1659546430; bh=qUSOTSEz3ZewDSJeWtCZ34Iq5tNq2K9kscLJx5wBjaw=; h=From:To:In-Reply-To:Date:Subject:From; b=qmBxFLmSY/12J/I50U5FdNgGUlaFbu1rwAEkFGQRQQfRJPqqmkBxe7UFgFQCmOohm dVcjndLss4zCXOLhe73QstStT3hUfXcOtFlzsm0O9Q18hakjQqIyM4QoeoFABVzMUL 89ceWg+tdkMBaiWXxqbJ6BsxaZS3ZtyIfozd1sgo= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.240.229] by pmq3v.m5r2.onet via HTTP id ; Wed, 03 Aug 2022 19:07:10 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: "aaradhya@technovanti.co.in, Aaradhya Chauhan , Bitcoin Protocol Discussion" , Peter Todd , Bitcoin Protocol Discussion In-Reply-To: Date: Wed, 03 Aug 2022 19:07:08 +0200 Message-Id: <166123291-fe0f05975e84c5e295606d87fdddcd64@pmq3v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.240.229;PL;2 X-Mailman-Approved-At: Wed, 03 Aug 2022 17:31:53 +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, 03 Aug 2022 17:07:20 -0000 It is possible, because you can find nodes that accept low-fee transactions= . And on some statistics, for example https://jochen-hoenicke.de/queue/#BTC= ,24h,weight,0 you can see that zero to one satoshi per virtual byte transac= tions could take more space than other transactions. You can be convinced t= hat those charts are not fake by running a full node and reaching some node= s with different fee settings. If miners don't want to accept them, well, i= t is their choice to leave that money on the table. As long as the basic bl= ock reward is sufficient, they don't have to accept such low fee transactio= ns, because they can wait instead, to receive them in some batched form. Also, some miners could accept only 10 sats/vB or higher, because why not. = As long as your transaction will reach enough nodes to be confirmed, you ca= n safely pick lower fees. For now, de-facto standard is one satoshi per vir= tual byte, but: 1) it is only declared, so you can rely only on declarations, not on hard c= onsensus rules 2) there is no way to make sure if some transaction was truly rejected by s= ome miner, or maybe it was saved somewhere 3) you can never be sure if some node is a miner and can enforce those diff= erent fee rules or not So, you can really judge only by how nodes behave, you cannot make sure in = any way if anyone is running some additional rules. And fees are not a part= of the consensus, so they can be freely adjusted by each node, and there i= s no way to make sure, what rules are really executed, you can only assume = that, based on what transactions are included in blocks. On 2022-08-03 18:19:12 user Aaradhya Chauhan via bitcoin-dev wrote: So, can we conclude by something, whether or not it would be possible and f= easible in the future? On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev wrote: On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail wrote: > > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev wrot= e: > > like a hashcash-based alternative broadcast scheme. > Hi Peter, > I've been mulling the idea of attaching work to low fee txns, both as a c= ompensation (e.g., in a sidechain, or an alt), and/or as a spam proof. Unfo= rtunately, both suffer from ASICs: > For spam proof case, the adversary can easily buy a used/obsolete device = to produce lots of spam txns very cheaply, unless you put the bar very high= , making it almost impossible for average users to even try. > The compensation scenario is pretty off-topic, still, interesting enough = for 1 min read: > Wallets commit to the latest blockchain state in the transaction AND atta= ch work. > It is considered contribution to the security (illegitimate chains can't = include the txn), hence isrewarded by fee discount/exemption depending on t= he offset of the state they've committed to (the closer, the better) and th= e amount of work attached. > For this to work, block difficulty is calculated inclusive with the work = embedded in the txns, it contains. Sophisticated and consequential, yet not= infeasible per se. > > Unfortunately, this scheme is hard to balance with ASICs in the scene too= , for instance, you can't subsidize wallets for their work like with a leve= rge, because miners can easily do it locally, seizing the subsidies for the= mselves, long story, not relevant just ignore it. We're not talking about a consensus system here. Just a way to rate-limit access to a broadcast network used by a small minority of nodes. It's completely ok to simply change the PoW algorithm in the _highly_ unlikely e= vent someone bothers to build an ASIC for it. Since this isn't a consensu system, it's totally ok if multiple versions of the scheme run in parallel.