Author: Antoine Riard 2020-09-22 13:52:55
Published on: 2020-09-22T13:52:55+00:00
The issue being discussed in this context is related to pre-signed transactions and their feerate. In multi-party protocols, pre-signed transactions may have a feerate of today but are broadcasted later with a feerate of tomorrow, which can cause problems if the feerate is too low for the transaction to propagate across network mempools. The author suggests that the feerate of the package of transactions should be evaluated as a whole in order to ensure acceptance of each element of the package by the network.One participant in the discussion raises a concern about sponsored transactions with low fees being evicted from mempools due to fee pressure and not being widely accepted when rebroadcasted. They point out that the requirement that the sponsor's entry must be present in the mempool can create a catch-22 situation where the sponsor transaction cannot be broadcast because the sponsored transaction is not in the mempool, and the sponsored transaction cannot be rebroadcast because the fee is too low. The participant suggests that this requirement may need to be revised and notes that RBF can still work in this case by replacing or inserting the transaction. Overall, the discussion highlights the importance of considering the feerate of pre-signed transactions in multi-party protocols and ensuring that transactions are evaluated as a package rather than individually. It also identifies potential issues with low fee sponsored transactions and the need to revise certain requirements in order to avoid catch-22 situations.
Updated on: 2023-06-14T15:26:32.342521+00:00