is FSS RBF really solving what it suppose to solve?

[jiri]

I follow this spec Peter created (really nicely written btw) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html

TX1 - original transaction
TX2 - added later to replace TX1

I understand the rationale behind FSS RBF and to some degree why F2pool implemented it, but it seems to me it allows not only to add fees and thus making the TX1 (using terminology from link above) to be confirmed faster, but also it also allows the TX1 confirmation to be delayed further and opens a door two new double-spend attacks

Why can the input prev-output of TX2 be almost anything? Meaning why it can have age=0, less than minimum relay fee, ... I even think it can have lock_time set. If we really want the original transaction TX1 to be pushed and confirmed faster, I would expect the transaction TX2 to have properties to help it go through only faster.

same logic applies to mining pools like F2Pool. It makes not much sense for them to add TX2 to TX1 if TX2 input pre-out is not confirmed and has 0fee (thus will take long time to confirm and even if they add this TX to the same block, at the extra fees they make on TX2, they actually loose on the parent of TX2)


Am I missing something?

[gmaxwell]

The requirement is that it meets all the prior validity criteria (e.g. is locked) and that it is more preferred (plus some additional requirements on what its permitted to conflict with)-- at least thats the intent; you'll need to analyze the implementation, not a forum post, to determine if it accomplishes that.