Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1857BC002D for ; Wed, 3 Aug 2022 18:22:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id D1789607D0 for ; Wed, 3 Aug 2022 18:22:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D1789607D0 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=dcRFatW5 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 HnIsxjxZ-As1 for ; Wed, 3 Aug 2022 18:22:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 63826600B3 Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by smtp3.osuosl.org (Postfix) with ESMTPS id 63826600B3 for ; Wed, 3 Aug 2022 18:22:44 +0000 (UTC) Received: by mail-io1-xd34.google.com with SMTP id l24so13495374ion.13 for ; Wed, 03 Aug 2022 11:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=QMbVT2tpK+e/Q40kd9MvD+PWU1ijasNj5JE80aleb3U=; b=dcRFatW5onBBD4nvRA9zK5HSR/iYlJdTWq8O1FzneUhfuLyIh5dQ/FNU1DQpfccYs9 5WZyVQg6Fu0Z8wRVlDq9Q4Hebh5MhCiCIpB2HWdRuNtHinoiuOYP8C9UUjbbnhkDs0tg M7cUHO++bajT1ZUQRkEsqn2TzYYcmJ5zwgzQkcqn8uUgQDN4C4COA7ltv9N8rYfzI4/C lzqUV8+5FruPPcYJY/MqdCHLLkOoxAVtFCRaya5PZ+XQlurYmgZCF79aYjsunG46UMaC tJMZUH97coJeiWKQ8Flqq+XjPK0zbxyoxhiDdU4LfW1NhWB9JSWBE2NcswIFajUoPtE2 zIKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=QMbVT2tpK+e/Q40kd9MvD+PWU1ijasNj5JE80aleb3U=; b=AfReHHJ2tygpYThvnRG40ITQwe+DTt1kACAMyMmPeSrLaKji4Rot52WGAwewM+Nuiv p1jteyOfrgHEy/+O+OQXsROKrv3BMuzhFciEsphdXXyjqvsCYIca2Lif3nbqZ1DEdKnp i9TKFYeSfzzLVpC5WK0IbwCOIQ/z6dMf+R+OdN7ObAIIuPlyiXzqiOkoTIlsMBujAwlm vFGPJAUaai7OeDWwxPYX/4lWcQTv1zhSXEokPc8dKKL0+SNo9JzWDkezQ1PJF7royMnW ZEim7z35egsnXoPqBAJYqo3SOn8nx1ZI8n/dExcAxprSFcKce3/Ud18U/3zEMvSUfiVG TXBw== X-Gm-Message-State: ACgBeo2ZpMHPsDPNkkpMgEAqHLS7k1i3AI4Go3dh9kYCyFdRYycZ82Pr Yre2zryWXTXFMgOVFTAwy+qoIHOb8ADyfzqWdtljNJ8= X-Google-Smtp-Source: AA6agR4xiNaE0gbWKurzf9SbNrwMWxRnGClxmoJXSLbAliqu3WtlH02Jj3+uA9BSCV6tFXE8aWMh+EBg/evSoxvY4Rk= X-Received: by 2002:a6b:3f0a:0:b0:680:c373:fdae with SMTP id m10-20020a6b3f0a000000b00680c373fdaemr311766ioa.48.1659550963316; Wed, 03 Aug 2022 11:22:43 -0700 (PDT) MIME-Version: 1.0 References: <166123291-fe0f05975e84c5e295606d87fdddcd64@pmq3v.m5r2.onet> In-Reply-To: <166123291-fe0f05975e84c5e295606d87fdddcd64@pmq3v.m5r2.onet> Reply-To: aaradhya@technovanti.co.in From: Aaradhya Chauhan Date: Wed, 3 Aug 2022 23:52:32 +0530 Message-ID: To: vjudeu@gazeta.pl, Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a7bcb005e55a514e" X-Mailman-Approved-At: Wed, 03 Aug 2022 22:34:31 +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 18:22:46 -0000 --000000000000a7bcb005e55a514e Content-Type: text/plain; charset="UTF-8" Thank you for answering. I'll check out the link you provided, while also playing around with the fee settings for my own full node, at my home server. On Wed, 3 Aug 2022 at 23:02, vjudeu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 transactions could take more space than > other transactions. You can be convinced that those charts are not fake by > running a full node and reaching some nodes with different fee settings. If > miners don't want to accept them, well, it is their choice to leave that > money on the table. As long as the basic block reward is sufficient, they > don't have to accept such low fee transactions, 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 > can safely pick lower fees. For now, de-facto standard is one satoshi per > virtual byte, but: > > 1) it is only declared, so you can rely only on declarations, not on hard > consensus rules > 2) there is no way to make sure if some transaction was truly rejected by > some miner, or maybe it was saved somewhere > 3) you can never be sure if some node is a miner and can enforce those > different 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 is > 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 < > bitcoin-dev@lists.linuxfoundation.org> wrote: > So, can we conclude by something, whether or not it would be possible and > feasible in the future? > > > On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> 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 > 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 > compensation (e.g., in a sidechain, or an alt), and/or as a spam proof. > Unfortunately, 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 > attach work. > > It is considered contribution to the security (illegitimate chains can't > include 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 > 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 > leverge, because miners can easily do it locally, seizing the subsidies for > themselves, 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 > event > 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000a7bcb005e55a514e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for answering. I'll check out the link you p= rovided, while also playing around with the fee settings for my own full no= de, at my home server.=C2=A0

On Wed, 3 Aug 2022 at 23:02, vjudeu via bitco= in-dev <bitcoin= -dev@lists.linuxfoundation.org> wrote:
It = is possible, because you can find nodes that accept low-fee transactions. A= nd on some statistics, for example https://jochen-= hoenicke.de/queue/#BTC,24h,weight,0 you can see that zero to one satosh= i per virtual byte transactions could take more space than other transactio= ns. You can be convinced that those charts are not fake by running a full n= ode and reaching some nodes with different fee settings. If miners don'= t want to accept them, well, it is their choice to leave that money on the = table. As long as the basic block reward is sufficient, they don't have= to accept such low fee transactions, because they can wait instead, to rec= eive 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 <bitcoin-de= v@lists.linuxfoundation.org> 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 <bitcoin-dev@lis= ts.linuxfoundation.org> 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-de= v 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 compensation (e.g., in a sidechain, or an alt), and/or as a spam proo= f. Unfortunately, both suffer from ASICs:
> For spam proof case, the adversary can easily buy a used/obsolete devi= ce to produce lots of spam txns very cheaply, unless you put the bar very h= igh, making it almost impossible for average users to even try.
> The compensation scenario is pretty off-topic, still, interesting enou= gh for 1 min read:
> Wallets commit to the latest blockchain state in the transaction AND a= ttach work.
> It is considered contribution to the security (illegitimate chains can= 't include the txn), hence isrewarded by fee discount/exemption dependi= ng on the offset of the state they've committed to (the closer, the bet= ter) and the amount of work attached.
> For this to work, block difficulty is calculated inclusive with the wo= rk 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 leverge, because miners can easily do it locally, seizing the subsidies = for themselves, long story, not relevant just ignore it.

We're not talking about a consensus system here. Just a way to rate-lim= it
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 sy= stem,
it's totally ok if multiple versions of the scheme run in parallel.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000a7bcb005e55a514e--