From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7F65EC002D for ; Mon, 1 Aug 2022 13:19:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 4C8E260B54 for ; Mon, 1 Aug 2022 13:19:14 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4C8E260B54 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=Mu8K83V1 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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_PASS=-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 PqjQ0_uI-H0j for ; Mon, 1 Aug 2022 13:19:13 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2E99B60B53 Received: from mail-4027.protonmail.ch (mail-4027.protonmail.ch [185.70.40.27]) by smtp3.osuosl.org (Postfix) with ESMTPS id 2E99B60B53 for ; Mon, 1 Aug 2022 13:19:13 +0000 (UTC) Date: Mon, 01 Aug 2022 13:19:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1659359949; x=1659619149; bh=wJJh1R8oFvMtvnb+zh3tPKA1jS4cG8xoqw0u7ar96T0=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=Mu8K83V1/OSqn0sJPxIY4/B2OSjy4wtbGGfmdKCqXWQi6yKnkGFrsNgPBlP6Kb0Tg QftcJX6pFS0aeRHtB/Tq45ng8Tn7yNFoRJoZbf7E1t1AwC95Q16+QifbAOTMmnaUJG f0x4JINZqLH+Rw5DRLObnIAoB+6Szc+46AhyoILos8UYS2A22JQrH9BM9lA1EBaDPX zvE9Pt14ZKApWBbeeiVMBs4jH226rNPSUi8PP2ae0oCWUNYue7CAZBBQo20JpM4U6Z 8l98F+XiPox4ZAkd9ojcDpf4VmcZL+pHL8OYHb2mpDXwgYdJN8I0rYbWwABJwwlSfm SCmhjfGl2HVdA== To: Peter Todd , Bitcoin Protocol Discussion From: "aliashraf.btc At protonmail" Reply-To: "aliashraf.btc At protonmail" Message-ID: In-Reply-To: References: Feedback-ID: 52379920:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 01 Aug 2022 13:23:03 +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: Mon, 01 Aug 2022 13:19:14 -0000 > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev wrote: > 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 com= pensation (e.g., in a sidechain, or an alt), and/or as a spam proof. Unfort= unately, 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 fo= r 1 min read: Wallets commit to the latest blockchain state in the transaction AND attach= work. It is considered contribution to the security (illegitimate chains can't in= clude the txn), hence isrewarded by fee discount/exemption depending on the= offset of the state they've committed to (the closer, the better) and the = amount of work attached. For this to work, block difficulty is calculated inclusive with the work em= bedded in the txns, it contains. Sophisticated and consequential, yet not i= nfeasible 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 leverg= e, because miners can easily do it locally, seizing the subsidies for thems= elves, long story, not relevant just ignore it. Cheers, Ali ------- Original Message ------- On Monday, August 1st, 2022 at 3:00 PM, Peter Todd via bitcoin-dev wrote: > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev wrote: > > > However, I think developers should not make any changes in the default = minimum fee rate required for relay. If there are incentives for users and = miners to change it, they should use non-default value. In case, miners wan= t to experiment with lower fee rate and see if this increases revenue they = could try using it on odd dates (even dates remain default) for a month. We= all could analyze how this worked for different mining pools and non-defau= lt value (lower or higher) could become normal in the future. > > > Without a way for lower-fee-rate transactions to get to those miners, > experiments like that are pointless. > > If you want to propose things like this, propose a way to get non-standar= d txs > to miners, like a hashcash-based alternative broadcast scheme. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev