[Feature]: Locktime Request Management on Emily

[Jiloc]

Feature: Locktime Request Management

1. Description

Requests that are not fulfilled remain in a pending state indefinitely, potentially causing system bloat.

This feature aims to address this issue by:

1. Designing a long-term sustainable solution to maintain request history while ensuring system cleanliness.

1.1 Context & Purpose

Pending requests without resolution can accumulate, leading to performance issues and bloated data. By introducing mechanisms to handle expired or invalid transactions, we can ensure Emily's state remains manageable and efficient.

2. Technical Details:

Short-term:

• Automatically mark deposits as FAILED if they exceed the locktime without being fulfilled.

Long-term:

• Develop a "cron-job" process for the sidecar to periodically clean up Emily's state:
  • Mark transactions as FAILED based on the following conditions:
    • Invalid or non-existent transactions that are not received in the mempool. (Define criteria for transaction validity.)
    • Transactions that remain unconfirmed in the blockchain after a specified duration.
    • Transactions included in the blockchain but where the locktime has expired without being processed by the signers.
• Ensure the sidecar, which already has access to a Bitcoin node, manages this periodic cleanup.
• Investigate the possibility of having signers update the deposit status to FAILED if validation fails.

Challenges:

• Emily lacks the ability to detect whether a transaction has passed its locktime without a Bitcoin node. This limitation requires the sidecar to handle such checks.
• Determine reasonable durations for marking transactions as failed if unconfirmed.
• Ensure efficient handling of request history to maintain a clean and usable system state.

2.1 Acceptance Criteria:

• Deposits exceeding the locktime are automatically marked as FAILED.
• Sidecar "cron-job" process is implemented to clean up Emily's state based on transaction validity, confirmation status, and locktime expiration.
• The system ensures that history is preserved for requests while preventing unnecessary system bloat.
• Optional: Signers update deposit status to FAILED for invalid transactions.