> Is it still verboten to acknowledge that RBF is normal behavior and disallowing it is the feature, and that feature is mostly there to appease some people's delusions that zeroconf is a thing? It seems a bit overdue to disrespect the RBF flag in the direction of always assuming it's on.
If you're thinking about the opt-in flag, not the RBF rules, please see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html The latest state of the discussion is here : https://gnusha.org/bitcoin-core-dev/2021-10-21.log A gradual, multi-year deprecation sounds to be preferred to ease adaptation of the affected Bitcoin applications. Ultimately, I think it might not be the last time we have to change high-impact tx-relay/mempool rules and a more formalized Core policy deprecation process would be good. Le lun. 31 janv. 2022 à 18:15, Bram Cohen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > Gloria Zhao wrote: > >> >> This post discusses limitations of current Bitcoin Core RBF policy and >> attempts to start a conversation about how we can improve it, >> summarizing some ideas that have been discussed. Please reply if you >> have any new input on issues to be solved and ideas for improvement! >> > > Is it still verboten to acknowledge that RBF is normal behavior and > disallowing it is the feature, and that feature is mostly there to appease > some people's delusions that zeroconf is a thing? It seems a bit overdue to > disrespect the RBF flag in the direction of always assuming it's on. > > >> - **Incentive Compatibility**: Ensure that our RBF policy would not >> accept replacement transactions which would decrease fee profits >> of a miner. In general, if our mempool policy deviates from what is >> economically rational, it's likely that the transactions in our >> mempool will not match the ones in miners' mempools, making our >> fee estimation, compact block relay, and other mempool-dependent >> functions unreliable. Incentive-incompatible policy may also >> encourage transaction submission through routes other than the p2p >> network, harming censorship-resistance and privacy of Bitcoin payments. >> > > There are two different common regimes which result in different > incentivized behavior. One of them is that there's more than a block's > backlog in the mempool in which case between two conflicting transactions > the one with the higher fee rate should win. In the other case where there > isn't a whole block's worth of transactions the one with higher total value > should win. It would be nice to have consolidated logic which handles both, > it seems the issue has to do with the slope of the supply/demand curve > which in the first case is gentle enough to keep the one transaction from > hitting the rate but in the second one is basically infinite. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
