-
Notifications
You must be signed in to change notification settings - Fork 94
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
feat(tendermint): pubkey-only activation and unsigned tx #2088
Conversation
Signed-off-by: onur-ozkan <work@onurozkan.dev>
f014bcd
to
c1428fe
Compare
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
696181e
to
f833b52
Compare
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
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.
Great work! This is an initial review since the PR is only in progress but I wanted to start reviewing it early due to the high priority of this PR.
#[cfg(target_arch = "wasm32")] | ||
PrivKeyPolicy::Metamask(_) => unreachable!(), |
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.
Metamask was supposed to be for any similar wallet once we start integrating others, you can see that it uses EthMetamaskPolicy
which includes the public key
komodo-defi-framework/mm2src/coins/lp_coins.rs
Lines 3601 to 3610 in c1428fe
#[cfg(target_arch = "wasm32")] | |
Metamask(EthMetamaskPolicy), | |
} | |
#[cfg(target_arch = "wasm32")] | |
#[derive(Clone, Debug)] | |
pub struct EthMetamaskPolicy { | |
pub(crate) public_key: EthH264, | |
pub(crate) public_key_uncompressed: EthH520, | |
} |
We have 2 options:
1 - Either use generics and rename metamask to
DappCompatibleWallet
or something similar2 - keep metamask but we should move it to
EthPrivKeyPolicy
instead in the future.
I think this is outside this PR scope anyway but I will leave this comment as a reminder for whoever will get to refactor this.
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.
fwiw, initially I also designed this to be a central/generic implementation in mm2, but considering the time we have, I couldn't afford the time allocation to do that.
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.
Really great work!, a question and couple changes after first review
tx: TransactionData::Signed { | ||
tx_hash: tx_hash.to_string(), | ||
tx_hex: msg.into(), | ||
}, |
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 see that we are constructing TransactionData::Signed
a lot of time. what about creating an helper function e.g
fn construct_signed_tx_from_hash_hex<Hash: ToString>(hash: Hash, hex: BytesJson) -> TransactionData {}
just some thoughts 💭
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.
What about TransactionData::new_signed(tx_hash, tx_hex)
? The construct_signed_tx_from_hash_hex
name makes it even more complicated than before in my opinion.
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.
ok better
Thanks for reviews. As this is an early-stage PR, things can be very different depending on the other blocker tasks I am working on. I will be working on the other/blocker tasks and come back here once I finish other parts. |
… into keplr-and-external-sign-swap
163bbb7
to
06e2073
Compare
Signed-off-by: onur-ozkan <work@onurozkan.dev>
06e2073
to
7d87d32
Compare
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
b431563
to
f776f38
Compare
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
… into keplr-and-external-sign-swap
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
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.
Amazing Work! Only some minor comments, I will do another recheck of tendermint_coin.rs
and tendermint_token.rs
early next week before approving the PR!
if ctx.is_watcher() || ctx.use_watchers() { | ||
return MmError::err(TendermintInitError { | ||
ticker: ticker.clone(), | ||
kind: TendermintInitErrorKind::CantUseWatchersWithPubkeyPolicy, | ||
}); |
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.
Watchers are not implemented for tendermint yet but I believe they can be implemented for external wallets too. It's up to you if you want to remove this check at this stage or not.
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 you give a little bit more context about watchers using external wallet?
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.
It's just another signed transaction that gets sent to the watcher where they can add the secret once revealed by the maker, so it will be one more transaction signed by keplr. Maybe for Tendermint watchers support, we will need some additions to nucleus codebase, I need to check this but it's not a priority currently.
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.
If I remember correctly, we made watchers so people don't have to keep the mm2 open for the swaps. If user has to be online/active on the keplr window, how does using watcher make sense? I think we should not allow doing that as it doesn't seem beneficial for users and adds tons of complexity on the codebase to maintain.
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.
If I remember correctly, we made watchers so people don't have to keep the mm2 open for the swaps. If user has to be online/active on the keplr window, how does using watcher makes sense?
The main reason we need watchers is not offline swaps but to fix some security issues, if the taker goes offline after sending their payment for a long time the maker can get both payments. Watchers start their work after the taker sends their payment, so for keplr the taker will sign 2 transactions, one for the taker payment and another to send to the watchers, then if anything happens and they went offline, the watcher can complete the swap or refund it before the maker refunds theirs.
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.
P.S. if a swap fails, the taker has to wait some time before they can refund it. If they didn't get back online after some time to refund it, and the maker is malicious, they can lose their payment.
let metadata_list = git_controller | ||
.client | ||
.get_file_metadata_list( | ||
CHAIN_REGISTRY_REPO_OWNER, | ||
CHAIN_REGISTRY_REPO_NAME, | ||
CHAIN_REGISTRY_BRANCH, | ||
CHAIN_REGISTRY_IBC_DIR_NAME, | ||
) | ||
.await | ||
.map_err(|e| IBCTransferChannelsRequestError::Transport(format!("{:?}", e)))?; |
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 know it's our repo, but is it completely secure to rely on this repo for ibc channels data? We have to consider supply chain attacks, what would happen if a wrong channel id is used for a transfer?
P.S. the alternative would be to load a file like the coins file and it will be updated with each new GUI release while relying on the user to enter custom channel ids for new IBC channels similar to custom token imports. What do you think @onur-ozkan?
c.c. @ca333
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 know it's our repo, but is it completely secure to rely on this repo for ibc channels data? We have to consider supply chain attacks, what would happen if a wrong channel id is used for a transfer?
Either our repo or user's hostname configuration must be hacked (which is already ..... situation) in order to provide incorrect channels. But that's already more dangerous than providing incorrect channels.
The things which may happen when using wrong channel:
-
By default, if using a channel id that doesn't exists, funds will be recovered (except the tx fee part).
-
If channel id belongs to a relayer that is customized by malicious person, then anything can happen depending on what this person changed on his/her relayer.
P.S. the alternative would be to load a file like the coins file and it will be updated with each new GUI release while relying on the user to enter custom channel ids for new IBC channels similar to custom token imports. What do you think @onur-ozkan?
Channels can be changed very frequently, I don't think we can keep up with it by releasing komodo-wallet for each change on the channels.
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.
Either our repo or user's hostname configuration must be hacked (which is already ..... situation) in order to provide incorrect channels. But that's already more dangerous than providing incorrect channels.
Only one dev with write auth getting hacked is enough to write incorrect channels info to this repo and it will be used straight away by komodo wallet and the defi framework release. We can't lock this to a certain commit hash too to have auto update.
Channels can be changed very frequently, I don't think we can keep up with it by releasing komodo-wallet for each change on the channels.
We can leave it as is for now but I wanted to raise this issue for the sec review team to see their opinion.
One more question, do channels change for already running and established chains or is this needed for new chains to be always available in komodo wallet?
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.
Only one dev with write auth getting hacked is enough to write incorrect channels info to this repo and it will be used straight away by komodo wallet and the defi framework release. We can't lock this to a certain commit hash too.
We can but that kills the whole idea. I would just put the json file in the mm2 source code instead of using the locked hash, but as I mentioned above we can not make mm2 release each time a channel info changes in the repo. Giving the write access to someone irrelevant is not an easy accident and that's already pretty bad situation in my opinion.
We can leave it as is for now but I wanted to raise this issue for the sec review team to see their opinion.
One more question, do channels change for already running and established chains or is this needed for new chains to be always available in komodo wallet?
They can be removed/updated for any new/old chain.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
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 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.
Great work and well done!
* dev: feat(tendermint): pubkey-only activation and unsigned tx (KomodoPlatform#2088) fix(tests): set txfee for some tbtc tests (KomodoPlatform#2116)
* dev: feat(tendermint): pubkey-only activation and unsigned tx (KomodoPlatform#2088) fix(tests): set txfee for some tbtc tests (KomodoPlatform#2116) fix(eth): remove my_address from sign_and_send_transaction_with_keypair (KomodoPlatform#2115) fix(utxo-swap): apply events occurred while taker down (KomodoPlatform#2114) refactor(memory): memory usage improvements (KomodoPlatform#2098) feat(app-dir): implement root application dir `.kdf` (KomodoPlatform#2102) fix tendermint fee calculation (KomodoPlatform#2106) update dockerfile (KomodoPlatform#2104)
This PR implements pubkey-only mode for the Tendermint protocol, which means we can use any external wallet for wallet and swap operations on Tendermint.
Additionally,
ibc_withdraw
RPC is removed andwithdraw
is refactored for Tendermint to support IBC transfers by automatically finding IBC channels whenever possible.