[Feature]: RBF Deposits Management

[Jiloc]

1. Description

Currently, Emily does not track RBF transactions. When an RBF transaction occurs, the Bridge sends a new create_deposit request while the previous deposit request remains indefinitely in a PENDING state.

This feature aims to address the issue by enabling Emily to handle RBF transactions more effectively, minimizing system bloat and mitigating potential security risks.

1.1 Context & Purpose

Without proper RBF handling, Emily accumulates duplicate or stale deposit requests, leading to inefficiencies and potential data integrity issues. Properly managing RBF transactions will ensure accurate state tracking while preventing malicious exploits.

2. Technical Details:

Proposed Solution:

• Add a parameter to the create_deposit endpoint to link the new deposit to an existing deposit in Emily.
  • The linked deposit must be in the PENDING state when the request is made.
  • If the parameter is provided, update the existing deposit rather than creating a new one.
• Use the full TX_HEX of the new transaction to determine if it is a RBF of an existing deposit?

Challenges:

• Data Authenticity: Emily cannot independently verify the authenticity of the data in create_deposit requests. This introduces the risk of malicious actors linking legitimate user requests to fake RBF transactions, invalidating them.
  • Investigate ways to validate the authenticity of the TX_HEX data to mitigate this risk.

2.1 Acceptance Criteria:

• A parameter is added to the create_deposit endpoint to link a new deposit to an existing one in PENDING status.
• Duplicate deposits are avoided, and the original deposit state is updated instead.
• Validation mechanisms are implemented to minimize the risk of malicious linking of deposits.
• Ensure proper logging and monitoring for all RBF-related actions for future auditing.

[djordon]

• Investigate ways to validate the authenticity of the TX_HEX data to mitigate this risk.

One way would be to look at the signature of the inputs of both transactions. If both transactions were have inputs that are signed with the same key then it's probably authentic. Also, we could figure out the logic implemented in bitcoin core to identify RBF transactions and use that or something similar.