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