There's been much talk about fee-bumping lately, and for good reason -
dynamic fee management is going to be a central part of bitcoin use as
the mempool fills up (lord willing) and right now fee-bumping is
fraught with difficulty and pinning peril.
Gloria's recent post on the topic[0] was very lu
One quick thought to the proposal and perhaps to sponsors in general(didn't
have time to go over original proposal again):
Since sponsors can come from anywhere, the wallet application must have
access to the mempool to know what inputs must be double spent to RBF the
sponsor transaction.
Seems l
> 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
10sats by a 100sats/vb transaction paying only 1sats.
I don't understand why the "<1vMB in the mempool" case is even worth
consideration because the miner
This is great in theory, but I think it kinda misses *why* the complexity keeps creeping in. We
agree on (most of) the goals here, but the problem is the goals explicitly lead to the complexity,
its not some software engineering failure or imagination failure that leads to the complexity.
On 2/
(I have not yet read the recent posts on RBF but i wanted to react on the
"additive feerate".)
> # Purely additive feerate bumps should never be impossible
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 1
Hi James,
I fully agree on the need to reframe the conversation around
mempools/fee-bumping/L2s though please see my following comments, it's far
from simple!
> Layering on special cases, more carve-outs, and X and Y percentage
> thresholds is going to make reasoning about the mempool harder than
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
With respect to the disagreement/misunderstanding about the "<1vMB in the
mempool" case, I think it's important to be clear about what the goals of
relay policy are. Should the goal be to only relay transactions that
increase miner revenue? Sure ideally, because we want to minimize load on
the net
> This entirely misses the network cost. Yes, sure, we can send
> "diffs", but if you send enough diffs eventually you send a lot of data.
The whole point of that section of the email was to consider the
network cost. There are many cases for which transmitting a
supplementary 1-in-1-out transacti
Thanks for your thoughtful reply Antoine.
> In a distributed system such as the Bitcoin p2p network, you might
> have transaction A and transaction B broadcast at the same time and
> your peer topology might fluctuate between original send and
> broadcast of the diff, you don't know who's seen wh
> In the context of fee bumping, I don't see how this is a criticism
> unique to transaction sponsors, since it also applies to CPFP: if you
> tried to bump fees for transaction A with child txn B, if some mempool
> hasn't seen parent A, it will reject B.
Agree, it's a comment raising the shenanig
> If you wish to fee-bump transaction X with sponsor, how can you be sure
that transaction isn't present in the majority of network nodes, and X has
_not_ been dropped since your last broadcast ?
You're right that you can't assume your target transaction hasn't been
dropped. However, I assume wh
> >> 2. (from Suhas) "once a valid transaction is created, it should not
> become invalid later on unless the inputs are double-spent."
> > This doesn't seem like a huge concern to me
>
> I agree that this shouldn't be a concern. In fact, I've asked numerous
> people in numerous places what practic
> The downside is that in a 6 block reorg any transaction that is moved
> past its expiration date becomes invalid and all its descendants
> become invalid too.
Worth noting that the transaction sponsors design is no worse an
offender on this count than, say, CPFP is, provided we adopt the change
James,
Unfortunately, there are technical reasons for sponsors to not be monotone.
Mostly that it requires the maintenance of an additional permanent
TX-Index, making Bitcoin's state grow at a much worse rate. Instead, you
could introduce a time-bound for inclusion, e.g. 100 blocks. However, this
The difference between sponsors and this issue is more subtle. The issue
Suhas raised was with a variant of sponsors trying to address a second
criticism, not sponsors itself, which is secure against this.
I think I can make this clear by defining a few different properties:
Strong Reorgability:
@Jeremy
> there are technical reasons for sponsors to not be monotone. Mostly that
it requires the maintenance of an additional permanent TX-Index, making
Bitcoin's state grow at a much worse rate
What do you mean by monotone in the context of sponsor transactions? And when
you say tx-index, do
> What do you mean by monotone in the context of sponsor transactions?
I take this to mean that the validity of a sponsor txn is
"monotonically" true at any point after the inclusion of the sponsored
txn in a block.
> And when you say tx-index, do you mean an index for looking up a
> transaction
> the validity of a sponsor txn is "monotonically" true at any point after
the inclusion of the sponsored txn in a block.
Oh I see his point now. If sponsors were valid at any point in the future,
not only would a utxo index be needed but an index of all transactions.
Yeah, that wouldn't be good.
On Thu, Feb 10, 2022 at 07:12:16PM -0500, Matt Corallo via bitcoin-dev wrote:
> This is where *all* the complexity comes from. If our goal is to "ensure a
> bump increases a miner's overall revenue" (thus not wasting relay for
> everyone else), then we precisely *do* need
> > Special consideration
> Is it really true that miners do/should care about that?
De facto, any miner running an unmodified version of bitcoind doesn't
care about anything aside from ancestor fee rate, given that the
BlockAssembler as-written orders transactions for inclusion by
descending ancestor fee-rate and then gre
> I suspect the "economically rational" choice would be to happily trade off
> that immediate loss against even a small chance of a simpler policy
> encouraging higher adoption of bitcoin, _or_ a small chance of more on-chain
> activity due to higher adoption of bitcoin protocols like lightning
While I roughly agree with the thesis that different replacement policies
offer marginal block reward gains _in the current state_ of the ecosystem,
I would be more conservative about extending the conclusions to the
medium/long-term future.
> I suspect the "economically rational" choice would be
> If anyone has any indication that there are miners running forks of bitcoind
> that change this behavior, I'd be curious to know it.
It is possible because some mining pools use bitcoind with custom patches.
Example: https://twitter.com/0xB10C/status/1461392912600776707 (f2pool)
--
Prayank
James,
You seem to imply that the scenario described isn't prevented today. It is. The
mempool acceptance for a replacement not only
depend on the transaction feerate but also the transaction fee [0]. That's why
i raised it in the first place...
Antoine
[0]
https://github.com/bitcoin/bitcoin/
25 matches
Mail list logo
