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>
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
Date: Wed, 03 Aug 2022 19:07:08 +0200 [thread overview]
Message-ID: <166123291-fe0f05975e84c5e295606d87fdddcd64@pmq3v.m5r2.onet> (raw)
In-Reply-To: <CAGHFe1BsDnxn6nuoMwCtt56YjaXmT0mPZ6XnMJZpyC2Fa7e9aQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2022-08-03 17:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-26 8:26 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 [this message]
2022-08-03 18:22 ` Aaradhya Chauhan
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=166123291-fe0f05975e84c5e295606d87fdddcd64@pmq3v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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