MIME-Version: 1.0
References: <CAGHFe1BXdTkPZn4r_KTxYoz0sqcMsV830dm5JTTFURxDezBnDQ@mail.gmail.com>
 <Yt/h2Jv3m8ZsfZ8v@petertodd.org> <f889c7fc9db56ed448237c8a4091abaa@dtrt.org>
 <CAGHFe1C-u7DbTtg0dz+p8Moh=FbFN5dKZow5HgtMpxcVyS2ZdA@mail.gmail.com>
 <JMG4yhnQ2xL1Pq51Jnyk37c6-Ip8zHuCjmPWc6AYJ0LxlhO7enV9xdr4YGkGbn_J-ecpueZsB-mIjowyVDyMINme1bXJk4BYYP7lBxR4Kfg=@protonmail.com>
 <YuerLzSvdJ8ZcqrR@petertodd.org>
 <bKNhJ_ASFgsOslPnOxW-ps5h2OUbHbVQfOelaLPey8lxezLEuevkua1WpAtVRNPRmCtj0fRAeOSe5OHWYOSafczcBuGzhRDqbVjGctAUdBI=@protonmail.com>
 <YufXK6ayn8ZcBzYN@petertodd.org>
In-Reply-To: <YufXK6ayn8ZcBzYN@petertodd.org>
Reply-To: aaradhya@technovanti.co.in
From: Aaradhya Chauhan <chauhanansh.me@gmail.com>
Date: Wed, 3 Aug 2022 21:10:34 +0530
Message-ID: <CAGHFe1BsDnxn6nuoMwCtt56YjaXmT0mPZ6XnMJZpyC2Fa7e9aQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006d6fea05e5580ee7"
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
Precedence: list

--0000000000006d6fea05e5580ee7
Content-Type: text/plain; charset="UTF-8"

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.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000006d6fea05e5580ee7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">So, can we conclude by something, whether or not it would =
be possible and feasible in the future?</div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 1 Aug 2022 at 19:08, Peter T=
odd via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex">On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At proton=
mail 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>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><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>

--0000000000006d6fea05e5580ee7--