Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu@gazeta.pl
To: "aaradhya@technovanti.co.in, Aaradhya Chauhan <chauhanansh.me@gmail.com>, 
 Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>,
 Peter Todd <pete@petertodd.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAGHFe1BsDnxn6nuoMwCtt56YjaXmT0mPZ6XnMJZpyC2Fa7e9aQ@mail.gmail.com>
Date: Wed, 03 Aug 2022 19:07:08 +0200
Message-Id: <166123291-fe0f05975e84c5e295606d87fdddcd64@pmq3v.m5r2.onet>
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
Precedence: list

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 <bitcoin-dev@l=
ists.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@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 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.