-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLI command to list tBTC deposits #3545
Conversation
We added a CLI command to list the tBTC deposits. The command queries the chain for revealed deposits and outputs their details to stdout. To list all deposits run: ``` keep-client wallet deposits ``` Following flags can be used with the command: - `--wallet <address>` - filter deposits only for given wallet - `--hide-swept` - doesn't show deposits that were already swept - `--sort-amount` - sort output by the deposit amount The command requires `ethereum` node details to be provided in the config.
go scan was complaining about unhandled error
cmd/wallet/deposits.go
Outdated
filter.WalletPublicKeyHash = [][20]byte{walletPublicKeyHash} | ||
} | ||
|
||
depositRevealedEvent, err := tbtcChain.PastDepositRevealedEvents(filter) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you manage to test it on mainnet with the oldest wallet? Did you try calling it against geth server which is not Infura/Alchemy? If not, can you please perform such a test? We had a discussion with @lukasz-zimnoch on how long it takes to retrieve old events without passing a block range. I expect Alchemy and Infura may have some fancier cache/indexing but does it work fast enough with a standard geth? Knowing this would help us determine how fancy we need to be with calls like that and this simple CLI command is a perfect opportunity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Get All Deposits (no filter):
Mainnet:
Alchemy: 0.205702 seconds
Infura: 0.523039 seconds
Geth: 265.665695 seconds
Get Wallet's Deposits (with wallet filter):
Mainnet:
Alchemy: 0.186728 seconds
Infura: 0.271587 seconds
Geth: 114.994290 seconds
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As expected but reassuring our design decisions were correct. Thanks.
cmd/wallet.go
Outdated
} | ||
|
||
var depositsCommand = cobra.Command{ | ||
Use: "deposits", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we rename this command to list-wallet-deposits
? This will make it more specific.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to keep the command name as short and simple as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant something similar to what I mentioned in #3545 (comment). In this case, deposits
are also ubiquitous, and making it at least list-deposits
would make the command clear at first sight, even without referring to its description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There will be just two commands: one to list the deposits and another to submit a deposit sweep proposal. The commands will be used by a handful of development team members, so I don't think there will be any ambiguity in the property naming, compared to the fact that the right transactions and fees will have to be determined by the caller of the sweep proposal command.
The reason why I want to keep all the commands and flags short is that if we combine them with arguments we will get long lines to handle in the CLI, e.g.:
keep-client wallet-coordinator propose-deposit-sweep --wallet-pkh 0x03b74d6893ad46dfdd01b9e0e3b3385f4fce2d1e --fee 12 bd99d1d0a61fd104925d9b7ac997958aa8af570418b3fde091f7bfc561608865:1 178628f0fd77ca04a31e771805277405288404da38eb86a0e369f2b26d45fe97:1 b71c0bbe43f23e162739b80b7bae9f0fb650e90e56fea0b92f169553505c398d:1 8356227b87fb191d61cff2455cd3f8c33ae208c69a7698b5baf1a331db6d4d8f:1 63cb18fdbe4ceb8b0747dbfcb11989605f78cffbe4379b9047124118cfc20aef:0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eventually, the wallet coordinator will manage redemptions, moving funds, and sweeps of moved funds. Most likely, the CLI will have to handle them as well. This is why I'm flagging the need to establish a clear and consistent API of the CLI from the beginning. I'm afraid that we won't be able to keep them short in the long term so it seems that it's better to use a predictable pattern from the beginning. For example, sweeping refers to both deposits and moved funds so we can't just have a single 'sweep' command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also vote for list-deposits
. We will have more actions in the coordinator soon and list-deposits
is in my opinion short enough and unique to not confuse it with anything else.
The actions we'll have to implement in the coordinator:
- list deposits (this PR)
- sweep (CLI command to submit a deposit sweep proposal #3549)
- increase sweep fee
- list redemptions (will also have to be automated)
- redeem (will also have to be automated)
- increase redemption fee
... then all the actions related to moving funds. I think it would also be nice to allow submitting heartbeat requests via the coordinator CLI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussion continued in #3549 (comment)
Get number of bitcoin confirmations for the given transaction and output it in the table.
The flags can be used to query specific number of top or bottom deposits. By default deposits are sorted by the creation block, so with `--head X` user can select X oldest deposits and with `--tail Y` get Y newest deposits. When `--sort-amount --head X` flags are used only X smalest deposits are returned and with `--sort-amount --tail Y` only Y biggest deposits are returned.
The function can be used externally to build the deposit key based on the rules specific for the given chain implementation.
We define hexutils pacakge with Decode and Encode functions that are based on https://pkg.go.dev/github.com/ethereum/go-ethereum/common/hexutil package.
) | ||
|
||
// Decode decodes a hex string with 0x prefix. | ||
func Decode(input string) ([]byte, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-blocking of course but just noting we could move this code to keep-common
at some point and use it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side note: we can use strings.TrimPrefix to do prefix removal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would need to trim 0x
and 0X
, so I'm not sure which approach would be better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally and works as expected. There are some ongoing discussions but I find them non-blocking, so let's address them in #3549.
if !reflect.DeepEqual(err, test.wantErr) { | ||
t.Fatalf("unexpected error\nexpected: %v\nactual: %v", test.wantErr, err) | ||
} | ||
if !bytes.Equal(test.want, dec) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could use testutils.AssertBytesEqual
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cmd/wallet.go
Outdated
} | ||
|
||
var depositsCommand = cobra.Command{ | ||
Use: "deposits", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also vote for list-deposits
. We will have more actions in the coordinator soon and list-deposits
is in my opinion short enough and unique to not confuse it with anything else.
The actions we'll have to implement in the coordinator:
- list deposits (this PR)
- sweep (CLI command to submit a deposit sweep proposal #3549)
- increase sweep fee
- list redemptions (will also have to be automated)
- redeem (will also have to be automated)
- increase redemption fee
... then all the actions related to moving funds. I think it would also be nice to allow submitting heartbeat requests via the coordinator CLI.
We added a CLI command to submit a deposit sweep proposal. The command verifies the proposal with the same rules as nodes will do and submits the proposal to the chain. To submit a deposit sweep proposal run: ``` keep-client coordinator propose-deposits-sweep --wallet <wallet_address> --fee <fee> <deposit_1> <deposit_2> ... ``` Following flags can be used with the command: - `--wallet <address>` - wallet to sweep - `--fee` - fee to use for the sweep transaction The command requires `ethereum` and `bitcoin.electrum` node details to be provided in the config. ### Deposits The command requires the deposits details to be provided as variadic arguments in a specific format: `<unprefixed bitcoin transaction hash>:<bitcoin transaction output index>:<ethereum reveal block number>` e.g. `bd99d1d0a61fd104925d9b7ac997958aa8af570418b3fde091f7bfc561608865:1:8392394` ## Sample command ``` keep-client --config ./configs/forked/config.toml \ --goerli \ coordinator \ propose-deposits-sweep \ --wallet 0x03b74d6893ad46dfdd01b9e0e3b3385f4fce2d1e \ --fee 12 \ da3ec4f5620f686d5013c37d49a411fa49daac5077c98809402572f481c6ea0:0:8502238 \ 214a85db0871b537d4cd649a8d74aecdbee112919983ad22fb85cfa2704a3593:0:8502224 \ 3704d01b48212ddacc77e613be0491978a8c19ad11af6b8536eacf9e9953eb13:0:8502070 ``` ## Testing ~To test this feature `WalletCoordinator` contract is required to be deployed. It is not yet available on Goerli or Mainnet. To have the contract available you can run a hardhat node as Goerli fork (https://github.com/nkuba/hardhat-forked-node) and deploy the `WalletCoordinator` contract there.~ Depends on: #3545
We added a CLI command to list the tBTC deposits. The command queries the chain for revealed deposits and outputs their details to stdout.
To list all deposits run:
Following flags can be used with the command:
--wallet <address>
- filter deposits only for a given wallet--hide-swept
- doesn't show deposits that were already swept--sort-amount
- sort output by the deposit amount--head <number>
- show<number>
first deposits--tail <number>
- show<number>
last depositsThe command requires
ethereum
andbitcoin
node details to be provided in the config.Funding Transaction
The command outputs the Bitcoin funding transaction details in a specific format:
<transaction hash>:<output index>
(e.g.a3d1781b59d5e8680772a8bb7f897c4ff0459d3465d7fa678f80a4f0ec900574:1
). The same format will be required by another CLI command to propose deposits sweep.Example
Sample execution of the command for Goerli network:
Output: