Sweeping prototype #3512
Assignees
Milestone
Comments
lukasz-zimnoch
added a commit
to keep-network/tbtc-v2
that referenced
this issue
Mar 9, 2023
Refs keep-network/keep-core#3512 No changes to the mechanism. Updated some parameter values based on the current state of the code. Some changes to the client were applied when this PR was in progress.
pdyraga
added a commit
to keep-network/tbtc-v2
that referenced
this issue
Apr 7, 2023
Refs: keep-network/keep-core#3512 Here we present the `WalletCoordinator` contract. This contract aims to facilitate the coordination of the off-chain wallet members during complex multi-chain wallet operations like deposit sweeping, redemptions, or moving funds. Such processes involve various moving parts and many steps that each individual wallet member must do. Given the distributed nature of the off-chain wallet software, full off-chain implementation is challenging and prone to errors, especially byzantine faults. This contract provides a single and trusted on-chain coordination point thus taking the riskiest part out of the off-chain software. The off-chain wallet members can focus on the core tasks and do not bother about electing a trusted coordinator or aligning internal states using complex consensus algorithms. As mentioned above, the `WalletCoordinator` contract is designed to handle not only deposit sweeps but also future redemptions and moving funds actions. The contract is upgradeable so adding new features should be straightforward. ### The flow In the first iteration, the deposit sweep process will look as follows: 1. An outside proposal submitter or designated wallet member submits a deposit sweep proposal using `submitDepositSweepProposal` function. A `DepositSweepProposalSubmitted` event holding the proposal is emitted. 2. Off-chain wallet members handle the `DepositSweepProposalSubmitted` event and confirm it. 3. Off-chain wallet members fetch necessary data and validate the proposal using a read-only call to the `validateDepositSweepProposal` function. 4. Off-chain wallet members do an additional off-chain validation. 5. Off-chain wallet members produce a proper sweep transaction and broadcast it over the Bitcoin network. 6. Once the time lock for the wallet expires, a new proposal can be submitted. ### Potential problems The presented approach brings some problems that must be addressed in the next iterations: - Invalid proposals hold the wallet locked and idle for a certain period. For now, this can be mitigated with a manual `unlockWallet` call done by the `WalletCoordinator` owner but we probably need a more robust solution eventually. - A specific variant of the above: a malicious wallet member can DoS the wallet with invalid proposals ### Remaining work - Off-chain part of the deposit sweep feature - Coordinator role check
This was referenced Apr 11, 2023
lukasz-zimnoch
added a commit
that referenced
this issue
Apr 26, 2023
Refs #3512 With the existing, pretty computationally-expensive tECDSA signing algorithm, [we would prefer](#3521 (comment)) not to execute heartbeats at the same time as other wallet actions (sweeping, redemptions, moving funds). Moreover, we would prefer not to execute heartbeats from multiple wallets at the same time. Such coordination is complicated off-chain for the same reason as the coordination of sweeps and redemptions. We could - as we do now - execute heartbeats at fixed hours but it does not help with coordination between heartbeats and sweeps. Also, it does not solve the problem of multiple heartbeats simultaneously. For this reason, in keep-network/tbtc-v2#609, the heartbeat has been made a first-class wallet action coordinated in the on-chain contract just like the rest of the wallet actions. In this PR we regenerate `WalletRegistry` contract bindings after the changes from keep-network/tbtc-v2#607 and keep-network/tbtc-v2#609. We add the `OnHeartbeatRequestSubmitted` event listener and remove the old, stubbed `OnHeartbeatRequested` implementation. In the next PRs, we will implement event deduplication and the off-chain action for heartbeats.
lukasz-zimnoch
added a commit
that referenced
this issue
Apr 27, 2023
Refs #3512 See #3539 This changeset adds the event deduplication for on-chain heartbeat requests. We consider the given event as a duplicate if the heartbeat request to the same wallet with the same message has been emitted in the last 24 hours. Additionally, we regenerate `WalletCoordinator` contract bindings and add the coordinator field to the Go version of the `HeartbeatRequestSubmitted` event after the changes from keep-network/tbtc-v2#611 have been merged.
This was referenced May 4, 2023
lukasz-zimnoch
added a commit
that referenced
this issue
May 9, 2023
…3541) Refs #3512 See keep-network/tbtc-v2#609 See #3539 See #3540 To make sure that older wallets are still accessible for redemption, we need to perform heartbeats. With the existing, pretty computationally-expensive tECDSA signing algorithm, we would prefer not to execute heartbeats at the same time as other wallet actions (sweeping, redemptions, moving funds). Moreover, we would prefer not to execute heartbeats from multiple wallets at the same time. Such coordination is complicated off-chain for the same reason as the coordination of sweeps and redemptions. We could - as we used to - execute heartbeats at fixed hours but it does not help with coordination between heartbeats and sweeps. Also, it does not solve the problem of multiple heartbeats simultaneously. For this reason, the heartbeat has been made a first-class wallet action coordinated in the on-chain contract just like the rest of the wallet actions. This changeset removes the fixed schedule for heartbeats and uses the `WalletCoordinator` contract as a trigger. ## Testing I tested this change by requesting heartbeats from two wallets I had in my local dev setup. Heartbeats were requested when all nodes were active and when the majority of nodes were offline. In all cases, the heartbeat eventually succeeded. Heartbeat can be requested with: ``` ❯ KEEP_ETHEREUM_PASSWORD="password" ./keep-client ethereum tbtc wallet-coordinator request-heartbeat \ 0x3805eed0bb0792eff8815addedb36add2c7257e5 \ 0xFFFFFFFFFFFFFFFF0000000000000001 \ --config configs/config.deployer.toml --submit ``` Keep in mind deployment scripts do not register coordinator address and it has to be done from the deployer account manually: ``` ❯ KEEP_ETHEREUM_PASSWORD="password" ./keep-client ethereum tbtc wallet-coordinator add-coordinator \ 0x524f2E0176350d950fA630D9A5a59A0a190DAf48 \ --config configs/config.deployer.toml --submit ```
This was referenced May 9, 2023
|
SPV proof submission is handled in a separate issue: #3563 so I am closing this one. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The first implementation of the sweeping mechanism should skip the risky coordination part and be triggered manually. All security guarantees should still hold.
Selected addresses will be able to trigger sweeping from a smart contract specifying how many inputs should be swept. The inputs will be swept from the oldest to the newest. The current group coordinator will receive an event from a contract, select inputs to be swept, and send a sweeping command to the group's broadcast channel. Every signing group member will validate the command and if everything checks, begin sweeping.
This plan requires:
WalletCoordinatorcontract tbtc-v2#589)tbtc-v2.tslibrary to submit an SPV proof manually, given the action is triggered manually anyway. (Sweep proof SPV maintainer (manual version) #3563)The text was updated successfully, but these errors were encountered: