Hey John
There was a discussion [0] started by Lisa on the mailing list last year on
whether there is any point to a full node maintaining a mempool last year which
you may find interesting. I also recommend Gloria's presentation [1] from
Adopting Bitcoin last year on transaction relay policy.
I think those are better resources than anything I could write. But I guess I'd
summarize it like this. The job of the P2P/mempool/policy protocol devs in
setting defaults is to ensure anyone can effectively propagate a consensus
valid transaction across the network ultimately making its way into miners'
mempools without harming network health (full node uptime, DoS attacks etc) and
to give higher layers built on top of the Bitcoin network the best chance to
succeed. If they totally screwed up that job with the defaults or they were
unable to cater for a particular use case within default policy then there is
always the alternative of submitting consensus valid transactions directly to
miners bypassing the P2P network entirely. But clearly it is much better if the
P2P network functions smoothly and every transaction isn't forced to be
directly submitted to a miner. It is policy too of course rather than consensus
so if the full node operator wants to change from the defaults they are free to
do so without risking being forked off the network or risking a chain split.
> I know some of you may scoff at my bias for use cases like zero-conf, but
> what I am trying to convey is a possible folly in active management,
> speculation, and misapplied game theory that may permeate many Bitcoin Core
> decisions and designs, even beyond the mempoolrbf / zero-conf debate.
This stuff is difficult to follow and understand especially for people who
haven't been into Bitcoin for long or are trying to build Bitcoin businesses
full time, there are lots of subtleties. I've certainly struggled at many
points in my learning journey and I'm sure I will continue to do so in future.
So there is no scoffing (from me at least) at individuals trying to learn and
businesses trying to thrive and provide services to their customers.
Unfortunately there are occasionally scenarios where trade-offs have to be
weighed up and decisions have to be made where some people aren't happy. You
may disagree but I'm a lot more comfortable delegating responsibility for
policy defaults to those who have worked full time in this area for years than
say consensus changes where I think we all have a responsibility to ensure
suboptimal or worse harmful changes aren't made to the consensus rules. I
thought your input on the CTV discussion earlier in the year was really
positive for example. On this topic though I think you could do with doing some
more reading as there is a lot of past discussion. I'm sure those who work in
this area full time would be happy to answer any questions you have if you do.
Thanks
Michael
[0]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019572.html
[1]:
https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Saturday, December 10th, 2022 at 14:10, John Carvalho via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> As we debate mempoolfullrbf, and I familiarize myself with related PRs from
> engineers trying to reign in all of the possible behaviors that make it
> inconsistent, I can’t help but think about how I see people using the term
> “incentive-compatible” and how it seems to be awfully presumptive.
>
> The idea that a single Bitcoin transaction can be “incentive-compatible” by
> simply restricting it to having a higher fee or fee rate is theoretical,
> likely narrow, and not totally objective. RBF is inherently a
> fee-minimization tool, which as a concept, as I understand
> “incentive-compatibility” to be about miners in this context, makes RBF to be
> anti-incentives; miners are fee maximizers.
>
> Miners want the most fees per block, and per lifetime, do they not? If
> miners, and the mempool, are prioritizing for the smallest txns with the
> highest fees, over the longest acceptable amount of time, this may conflict
> with extra-mempool behaviors that result in more txns per block / per
> lifetime.
>
> If this isn’t making sense yet, let me summarize by how such a problem would
> express: a per-transaction fee-minimized, fully replaceable mempool as
> policy, that appears to always require the highest fee per txn, but
> ultimately includes less txns per block and less fees per lifetime.
> Basically, less use cases, less users, less txns — all to enforce a
> misunderstood theory and predictive speculation of what people want out of
> the system and what miners will do about it.
>
> Simply, we probably want designs that fill blocks, and we don’t need to do
> anything at all to facilitate bidding on a use case like replacement.
>
> Bidding does not require protocol enforcement, it is miner-subjective. So why
> are we pursuing it? Why do we even have RBF? Why are we trying to clean up
> all of the mess RBF creates with more and more code? If bidding is already
> accepted as incentive-compatible, and Bitcoin already allows setting a fee,
> then replacement requires no special code at all.
>
> I would think a holistic definition of what is incentive-compatible would be
> something more like what is “market compatible” and enables the complementary
> goals & incentives of every user in the system to make it thrive.
>
> It has been shown that users control Bitcoin (UASF) and thus ultimately
> miners would be incentivized to do what users want, up to the point of
> inability or loss. Correct?
>
> So, in contrast, how would the opposite, a user-compatible design, express?
> Well, I think the idea of txns being able to signal intent and desired
> behavior is more interesting (more useful) than a mempool that overrides all
> intent with RBF, and possibly more incentive-compatible than mempoolfullrbf
> as concept.
>
> Since we can’t be sure what the market wants, but we can be sure that the
> more users we have, making the most possible txns, at the highest possible
> prices, will yield the most valuable Bitcoin, and thus the most hashpower, we
> could entertain giving users the most ways to express their intent, the most
> flexibility.
>
> The most basic design would be to simply have no mempool policy at all, and
> let market incentives emerge on their own, but we have a status quo to
> consider, and most users do not have the technical expertise to express their
> own policies with misc patches and hacks of their Bitcoin Core software.
>
> I know this is a bit of a high-level abstract perspective, but I think it is
> important to respect such dynamics when making smaller decisions. It
> certainly is not our charge to prioritize what miners want any more than any
> other user type, nor is it within our ability to predict the future or fully
> model incentives of all players across all use cases.
>
> I know some of you may scoff at my bias for use cases like zero-conf, but
> what I am trying to convey is a possible folly in active management,
> speculation, and misapplied game theory that may permeate many Bitcoin Core
> decisions and designs, even beyond the mempoolrbf / zero-conf debate.
>
> So, what to do?
>
> —
>
> John Carvalho
> CEO, Synonym.to
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
