Hello AC, Yes that's a real issue. In the context of multi-party protocols, you may pre-signed transactions with the feerate of _today_ and then only going to be broadcast later with a feerate of _tomorrow_. In that case the pre-signed feerate may be so low that the transaction won't even propagate across network mempools with a local minimal feerate higher.
That's why you want to be sure that the feerate of your package of transactions (either sponsor+sponsoree or parent+CPFP) is going to be evaluated as a whole to decide acceptance of each element of the package. Antoine Le mar. 22 sept. 2020 à 03:28, ArmchairCryptologist via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > Not sure if I'm missing something, but I'm curious if (how) this will work > if the sponsored transaction's feerate is so low that it has been largely > evicted from mempools due to fee pressure, and is too low to be widely > accepted when re-broadcast? It seems to me that the following requirement > > >1. The Sponsor Vector's entry must be present in the mempool > > means that you enter a catch-22 where the sponsor transaction cannot be > broadcast because the sponsored transaction is not in the mempool, and the > sponsored transaction cannot be (re-)broadcast because the fee is too low. > This requirement might therefore need to be revised. > > There is of course no global mempool, but RBF by its nature would still > work in this case, by replacing the transaction if it exists and inserting > it if it does not. > > --AC > _______________________________________________ > 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
