search

stacks-network / sbtc

Repo containing sbtc
GNU General Public License v3.0
297 stars 9 forks source link

[Feature]: (Partial) Reorganized deposit transactions will be lost #984

Open technovision99 opened 3 days ago

technovision99 commented 3 days ago

1. Description

Currently, the block observer's store_deposit_requests function, calls db.write_bitcoin_transactions and db.write_deposit_requests. https://github.com/stacks-network/sbtc/blob/c658f0680fe55a42146f78e8eb3f5fe8b658edc7/signer/src/block_observer.rs#L319-L321 However, both of those writes will only store the txid associated with a deposit request one time due to the use of ON CONFLICT DO NOTHING in the SQL statement: https://github.com/stacks-network/sbtc/blob/c658f0680fe55a42146f78e8eb3f5fe8b658edc7/signer/src/storage/postgres.rs#L2179-L2196 This implies that if the block hash for the txid changes due to a reorg, it will be unable to be picked up as the txid's block hash can never be updated to reflect the reorg.

djordon commented 3 days ago

The bitcoin_transactions table has a compound primary key on txid and block_hash so if the transaction gets confirmed on another block_hash then we will get another row written to that table in the second call to the write_bitcoin_transactions function. And I believe that we attempt to write the deposit transaction into the database until it gets to some other status besides Pending.

In the event that the signers sweep the deposited funds and update the status to Accepted, reorgs should be detected by the Emily API and revert a deposit's status to Pending (I should double check that). The signers will then try to write the transaction into the database and we should get one more row in the bitcoin_transactions table when it gets reconfirmed.