path: root/5e/e076ccbc0d5babf4a72c7a38b3fd614b3dbfbe

Return-Path: <chauhanansh.me@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1857BC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Aug 2022 18:22:44 +0000 (UTC)
Received: by mail-io1-xd34.google.com with SMTP id l24so13495374ion.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAGHFe1BsDnxn6nuoMwCtt56YjaXmT0mPZ6XnMJZpyC2Fa7e9aQ@mail.gmail.com>
 <166123291-fe0f05975e84c5e295606d87fdddcd64@pmq3v.m5r2.onet>
In-Reply-To: <166123291-fe0f05975e84c5e295606d87fdddcd64@pmq3v.m5r2.onet>
Reply-To: aaradhya@technovanti.co.in
From: Aaradhya Chauhan <chauhanansh.me@gmail.com>
Date: Wed, 3 Aug 2022 23:52:32 +0530
Message-ID: <CAGHFe1BYPhewOH6o+EMuWFhkFsn4DUYtc9ziFinVw8PHVR9tJg@mail.gmail.com>
To: vjudeu@gazeta.pl, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr">Thank you for answering. I&#39;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</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, 3 Aug 2022 at 23:02, vjudeu via bitco=
in-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">It =
is possible, because you can find nodes that accept low-fee transactions. A=
nd on some statistics, for example <a href=3D"https://jochen-hoenicke.de/qu=
eue/#BTC,24h,weight,0" rel=3D"noreferrer" target=3D"_blank">https://jochen-=
hoenicke.de/queue/#BTC,24h,weight,0</a> 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&#39;=
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&#39;t have=
 to accept such low fee transactions, because they can wait instead, to rec=
eive them in some batched form.<br>
<br>
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:<br>
<br>
1) it is only declared, so you can rely only on declarations, not on hard c=
onsensus rules<br>
2) there is no way to make sure if some transaction was truly rejected by s=
ome miner, or maybe it was saved somewhere<br>
3) you can never be sure if some node is a miner and can enforce those diff=
erent fee rules or not<br>
<br>
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.<br>
<br>
<br>
<br>
On 2022-08-03 18:19:12 user Aaradhya Chauhan via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt; wrote:<br>
So, can we conclude by something, whether or not it would be possible and f=
easible in the future?<br>
<br>
<br>
On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt; wrote:<br>
<br>
On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail wrote=
:<br>
&gt; &gt; On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-de=
v wrote:<br>
&gt; &gt; like a hashcash-based alternative broadcast scheme.<br>
&gt; Hi Peter,<br>
&gt; I&#39;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:<br>
&gt; 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.<br>
&gt; The compensation scenario is pretty off-topic, still, interesting enou=
gh for 1 min read:<br>
&gt; Wallets commit to the latest blockchain state in the transaction AND a=
ttach work.<br>
&gt; It is considered contribution to the security (illegitimate chains can=
&#39;t include the txn), hence isrewarded by fee discount/exemption dependi=
ng on the offset of the state they&#39;ve committed to (the closer, the bet=
ter) and the amount of work attached.<br>
&gt; 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.<br>
&gt;<br>
&gt; Unfortunately, this scheme is hard to balance with ASICs in the scene =
too, for instance, you can&#39;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.<br>
<br>
We&#39;re not talking about a consensus system here. Just a way to rate-lim=
it<br>
access to a broadcast network used by a small minority of nodes. It&#39;s<b=
r>
completely ok to simply change the PoW algorithm in the _highly_ unlikely e=
vent<br>
someone bothers to build an ASIC for it. Since this isn&#39;t a consensu sy=
stem,<br>
it&#39;s totally ok if multiple versions of the scheme run in parallel.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000a7bcb005e55a514e--