public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Aaradhya Chauhan <chauhanansh.me@gmail.com>
To: vjudeu@gazeta.pl,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
Date: Wed, 3 Aug 2022 23:52:32 +0530	[thread overview]
Message-ID: <CAGHFe1BYPhewOH6o+EMuWFhkFsn4DUYtc9ziFinVw8PHVR9tJg@mail.gmail.com> (raw)
In-Reply-To: <166123291-fe0f05975e84c5e295606d87fdddcd64@pmq3v.m5r2.onet>

[-- Attachment #1: Type: text/plain, Size: 4340 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5254 bytes --]

  reply	other threads:[~2022-08-03 18:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-26  8:26 [bitcoin-dev] Regarding setting a lower minrelaytxfee Aaradhya Chauhan
2022-07-26 12:19 ` alicexbt
2022-07-26 14:27   ` Peter Todd
2022-07-26 19:14     ` alicexbt
2022-07-26 12:45 ` Peter Todd
2022-07-27  4:10   ` vjudeu
2022-07-27 11:50     ` Peter Todd
2022-07-27 12:18       ` vjudeu
2022-07-29  3:38   ` David A. Harding
2022-07-29 18:59     ` Aaradhya Chauhan
2022-07-30  7:55     ` Aaradhya Chauhan
2022-07-30 17:24       ` alicexbt
2022-08-01 10:30         ` Peter Todd
2022-08-01 13:19           ` aliashraf.btc At protonmail
2022-08-01 13:37             ` Peter Todd
2022-08-03 15:40               ` Aaradhya Chauhan
2022-08-03 17:07                 ` vjudeu
2022-08-03 18:22                   ` Aaradhya Chauhan [this message]
2022-08-04  1:21                     ` Billy Tetrud
2022-07-30 10:20     ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGHFe1BYPhewOH6o+EMuWFhkFsn4DUYtc9ziFinVw8PHVR9tJg@mail.gmail.com \
    --to=chauhanansh.me@gmail.com \
    --cc=aaradhya@technovanti.co.in \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=vjudeu@gazeta.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox