From: darosior <darosior@protonmail•com>
To: james.obeirne@gmail•com
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
Date: Fri, 11 Feb 2022 06:51:34 +0000 [thread overview]
Message-ID: <4D4Un0WaQ8pA19HVFy_xtBTQhItDVIPWPLwuS7Hv8RBxvHpV05dyWPeoveTTefc3cG6S7IOhuxnH5n2HnFbTpF9UszuuAygnOEVz9g6JOKA=@protonmail.com> (raw)
In-Reply-To: <CAPfvXfJ6dE2JycEdsK-gimyFwf64RfOen0maRq4LLg5R8RFEbQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
Well because in the example i gave you this decreases the miner's reward. The rule of increasing feerate you stated isn't always economically rationale.
Note how it can also be extended, for instance if the miner only has 1.5vMB of txs and is not assured to receive enough transactions to fill 2 blocks he might be interested in maximizing absolute fees, not feerate.
Sure, we could make the argument that long term we need a large backlog of transactions anyways.. But that'd be unfortunately not in phase with today's reality.
-------- Original Message --------
On Feb 11, 2022, 00:51, James O'Beirne wrote:
>> It's not that simple. As a miner, if i have less than 1vMB of transactions in my mempool. I don't want a 10sats/vb transaction paying 100000sats by a 100sats/vb transaction paying only 10000sats.
>
> I don't understand why the "<1vMB in the mempool" case is even worth consideration because the miner will just include the entire mempool in the next block regardless of feerate.
[-- Attachment #2: Type: text/html, Size: 1230 bytes --]
next prev parent reply other threads:[~2022-02-11 6:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-10 19:40 James O'Beirne
2022-02-10 23:09 ` Greg Sanders
2022-02-10 23:44 ` darosior
2022-02-10 23:51 ` James O'Beirne
2022-02-11 6:51 ` darosior [this message]
2022-02-12 19:44 ` Billy Tetrud
2022-02-11 0:12 ` Matt Corallo
2022-02-14 19:51 ` James O'Beirne
2022-02-17 14:32 ` Anthony Towns
2022-02-17 18:18 ` James O'Beirne
2022-02-18 9:01 ` darosior
2022-02-18 0:35 ` Antoine Riard
2022-02-11 5:26 ` Antoine Riard
2022-02-14 20:28 ` James O'Beirne
2022-02-15 0:43 ` Antoine Riard
2022-02-15 17:09 ` Billy Tetrud
2022-02-15 20:24 ` Russell O'Connor
2022-02-15 20:53 ` James O'Beirne
2022-02-15 21:37 ` Jeremy Rubin
2022-02-18 21:09 ` [bitcoin-dev] Sponsor transaction engineering, was " David A. Harding
2022-02-15 21:38 ` [bitcoin-dev] " Jeremy Rubin
2022-02-16 2:54 ` Billy Tetrud
2022-02-16 19:18 ` James O'Beirne
2022-02-16 20:36 ` Billy Tetrud
2022-02-18 0:54 Prayank
2022-02-18 2:08 Prayank
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='4D4Un0WaQ8pA19HVFy_xtBTQhItDVIPWPLwuS7Hv8RBxvHpV05dyWPeoveTTefc3cG6S7IOhuxnH5n2HnFbTpF9UszuuAygnOEVz9g6JOKA=@protonmail.com' \
--to=darosior@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=james.obeirne@gmail$(echo .)com \
/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