Hi Daniel, >From my understanding of GAP600, you're operating a zero-conf risk analysis business, which is integrated and leveraged by payment processors/liquidity providers and merchants. A deployment of fullrbf by enough full-node operators and a subset of the mining hashrate would lower the cost of double-spend attack by lamda users, therefore increasing the risk exposure of your users. This increased risk exposure could lead you to alter the acceptance of incoming zero-conf transactions, AFAICT in a similar reasoning as exposed by Bitrefill earlier this year [0].
About the statistics you're asking for considerations, few further questions, on those 1.5M transactions per month, a) how many are Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many are excluded from zeroconf due to factors like RBF, long-chain of unconfirmed ancestors or too high-value and c) what has been the average feerate (assuming a standard size of 200 bytes) ? My personal position on fullrbf is still the same as expressed in #26525 [1]. As a community, I think we still don't have conceptual consensus on deploying full-rbf, nor to remove it. In the direction of removing the current option from Bitcoin Core, I think the prerequisite to address are the qualification of enough economic flows at risk and the presence of a sizable loss in miners income. Beyond that, I think there is still the open question if we (we, as the Bitcoin protocol development community, with all its stakeholders) should restrain user choice in policy settings in the name of preserving mining income and established use-case stability. To recall, the original technical motivation of this option, and the wider smoother deployment was to address a DoS vector affecting another class of use-case: multi-party transactions like coinjoin and contracting protocols like Lightning [2] [3]. All of them expect to generate economic flows and corresponding mining income. Since then, alternative paths to solve this DoS vector have been devised, all with their own trade-offs and conceptual issues [4] [5]. Best, Antoine [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021070.html [1] https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319499006 [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html [4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html [5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
