Skip to content
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

tx raw ft-transfer use wrong destination address with hermes v1.0.0-rc0 #2405

Closed
5 tasks
WinterNis opened this issue Jul 13, 2022 · 1 comment · Fixed by #2407
Closed
5 tasks

tx raw ft-transfer use wrong destination address with hermes v1.0.0-rc0 #2405

WinterNis opened this issue Jul 13, 2022 · 1 comment · Fixed by #2407
Assignees
Labels
A: bug Admin: something isn't working
Milestone

Comments

@WinterNis
Copy link

Summary of Bug

With hermes v1.0.0-rc0, when using the tx raw ft-transfer command to send IBC tokens from one chain to another:

  • The --receiver parameter address seems to be ignored.
  • The funds are actually sent to the wallet used by hermes to relay, meaning the address of the wallet specified by the key_name parameter in hermes config.

Note that this has been tested on the rc-0 version of the v1 release. We know the version is not supposed to be stable. We still decided to report the bug since it was quite concerning and we could not find any mention of it elsewhere.

Version

v1.0.0-rc.0

Steps to Reproduce

We send xki tokens from osmos testnet to kichain testnet. The receiver address should be tki1aygsj8q29lsygpt8m6mse4hch69m32kzygh5rr

hermes tx raw ft-transfer --dst-chain "kichain-t-4" --src-chain "osmo-test-4" --src-port "transfer" --src-channel "channel-269" --amount 1 --receiver "tki1aygsj8q29lsygpt8m6mse4hch69m32kzygh5rr" --key-name=test-relayer-wallet --timeout-height-offset 1000 --denom="ibc/1D1596887FC06B9C5A4F79743C5E2D34A9928BA25796DF561B946B42A1AE9730"
2022-07-13T13:14:03.175114Z  INFO ThreadId(01) using default configuration from '/home/hermes/.hermes/config.toml'
2022-07-13T13:14:03.175443Z DEBUG ThreadId(01) Message: TransferOptions { packet_src_port_id: PortId("transfer"), packet_src_channel_id: ChannelId("channel-269"), amount: Amount(1), denom: "ibc/1D1596887FC06B9C5A4F79743C5E2D34A9928BA25796DF561B946B42A1AE9730", receiver: Some("tki1aygsj8q29lsygpt8m6mse4hch69m32kzygh5rr"), timeout_height_offset: 1000, timeout_duration: 0ns, number_msgs: 1 }
2022-07-13T13:14:03.246447Z DEBUG ThreadId(01) connection hop underlying the channel: ConnectionEnd { state: Open, client_id: ClientId("07-tendermint-1945"), counterparty: Counterparty { client_id: ClientId("07-tendermint-427"), connection_id: Some(ConnectionId("connection-427")), prefix: ibc }, versions: [Version { identifier: "1", features: ["ORDER_ORDERED", "ORDER_UNORDERED"] }], delay_period: 0ns }
2022-07-13T13:14:03.247488Z DEBUG ThreadId(01) client state underlying the channel: Tendermint(ClientState { chain_id: ChainId { id: "kichain-t-4", version: 4 }, trust_level: TrustThreshold { numerator: 1, denominator: 3 }, trusting_period: 1209600s, unbonding_period: 1814400s, max_clock_drift: 1800s, latest_height: Height { revision: 4, height: 5017926 }, proof_specs: ProofSpecs([ProofSpec(ProofSpec { leaf_spec: Some(LeafOp { hash: Sha256, prehash_key: NoHash, prehash_value: Sha256, length: VarProto, prefix: [0] }), inner_spec: Some(InnerSpec { child_order: [0, 1], child_size: 33, min_prefix_length: 4, max_prefix_length: 12, empty_child: [], hash: Sha256 }), max_depth: 0, min_depth: 0 }), ProofSpec(ProofSpec { leaf_spec: Some(LeafOp { hash: Sha256, prehash_key: NoHash, prehash_value: Sha256, length: VarProto, prefix: [0] }), inner_spec: Some(InnerSpec { child_order: [0, 1], child_size: 32, min_prefix_length: 1, max_prefix_length: 1, empty_child: [], hash: Sha256 }), max_depth: 0, min_depth: 0 })]), upgrade_path: ["upgrade", "upgradedIBCState"], allow_update: AllowUpdate { after_expiry: true, after_misbehaviour: true }, frozen_height: None })
2022-07-13T13:14:03.311046Z DEBUG ThreadId(06) send_tx_commit{id=ft-transfer}:send_tx_with_account_sequence_retry{id=osmo-test-4}: sending 1 messages using account sequence AccountSequence(1179)
2022-07-13T13:14:03.311203Z DEBUG ThreadId(06) send_tx_commit{id=ft-transfer}:send_tx_with_account_sequence_retry{id=osmo-test-4}: max fee, for use in tx simulation: Fee { amount: "50001uosmo", gas_limit: 2000000 }
2022-07-13T13:14:03.317517Z DEBUG ThreadId(06) send_tx_commit{id=ft-transfer}:send_tx_with_account_sequence_retry{id=osmo-test-4}:estimate_gas: tx simulation successful, gas amount used: 115263
2022-07-13T13:14:03.317730Z DEBUG ThreadId(06) send_tx_commit{id=ft-transfer}:send_tx_with_account_sequence_retry{id=osmo-test-4}: send_tx: using 115263 gas, fee Fee { amount: "3170uosmo", gas_limit: 126789 } id=osmo-test-4
2022-07-13T13:14:03.320201Z DEBUG ThreadId(06) send_tx_commit{id=ft-transfer}:send_tx_with_account_sequence_retry{id=osmo-test-4}: broadcast_tx_sync: Response { code: Ok, data: Data([]), log: Log("[]"), hash: transaction::Hash(32119B54EF0F29E9D23F94D11C2C503F8117DB94DC9808B910ACAC620CEAB4E8) }
2022-07-13T13:14:03.320330Z  INFO ThreadId(06) send_tx_commit{id=ft-transfer}: wait_for_block_commits: waiting for commit of tx hashes(s) 32119B54EF0F29E9D23F94D11C2C503F8117DB94DC9808B910ACAC620CEAB4E8 id=osmo-test-4
Success: [
    SendPacket(
        SendPacket - h:4-5569788, seq:1220, path:channel-269/transfer->channel-351/transfer, toh:4-5019089, tos:Timestamp(NoTimestamp)),
    ),
]

The resulting transaction is 32119B54EF0F29E9D23F94D11C2C503F8117DB94DC9808B910ACAC620CEAB4E8

We can see that the receiver is actually tki16klm67dla3cnv7k2889cyprnt62s4uy8rjpkj9 and not tki1aygsj8q29lsygpt8m6mse4hch69m32kzygh5rr.

tki16klm67dla3cnv7k2889cyprnt62s4uy8rjpkj9 is actually the address behing hermes key_name wallet.

For reference, here is hermes configuration:

[global]
log_level = 'debug'

[mode]

[mode.clients]

enabled = true
refresh = true
misbehaviour = true

[mode.connections]

enabled = false

[mode.channels]

enabled = false

[mode.packets]

enabled = true
clear_interval = 1
clear_on_start = true
tx_confirmation = true

[rest]

enabled = false
host = '127.0.0.1'
port = 3000

[telemetry]
enabled = true
host = '127.0.0.1'
port = 3001


[[chains]]
id = 'osmo-test-4'
rpc_addr = 'http://x.x.x.x:26657'
grpc_addr = 'http://x.x.x.x:9090'
websocket_addr = 'ws://x.x.x.x:26657/websocket'
rpc_timeout = '60s'
account_prefix = 'osmo'
key_name = 'relayer-wallet'
store_prefix = 'ibc'
max_gas = 2000000
gas_price = { price = 0.025, denom = 'uosmo' }
gas_multiplier = 1.1
# src_chain_config.clock_drift + dst_chain_config.clock_drift + dst_chain_config.max_block_time
# we want the value to be equal to 1800s
clock_drift = '895s'
max_block_time = '10s'
trusting_period = '240h'
trust_threshold = { numerator = '1', denominator = '3' }
max_tx_size = 150000

[chains.packet_filter]
policy = 'allow'
list = [
  ['transfer', 'channel-269'],
]

[[chains]]
id = 'kichain-t-4'
rpc_addr = 'http://x.x.x.x:26657'
grpc_addr = 'http://x.x.x.x:9090'
websocket_addr = 'ws://x.x.x.x:26657/websocket'
rpc_timeout = '60s'
account_prefix = 'tki'
key_name = 'relayer-wallet'
store_prefix = 'ibc'
max_gas = 2000000
gas_price = { price = 0.025, denom = 'utki' }
gas_multiplier = 1.1
# src_chain_config.clock_drift + dst_chain_config.clock_drift + dst_chain_config.max_block_time
# we want the value to be equal to 1800s
clock_drift = '895s'
max_block_time = '10s'
trusting_period = '336h'
trust_threshold = { numerator = '1', denominator = '3' }
max_tx_size = 150000

[chains.packet_filter]
policy = 'allow'
list = [
  ['transfer', 'channel-351'],
]

Acceptance Criteria

The IBC transaction fund are sent to the address specified by --receiver argument and not the address used by hermes for relaying.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@ljoss17 ljoss17 self-assigned this Jul 13, 2022
@romac romac changed the title tx raw ft-transfer use wrong destination address with hermes v1.0.0-rc0 tx raw ft-transfer use wrong destination address with hermes v1.0.0-rc0 Jul 14, 2022
@romac
Copy link
Member

romac commented Jul 14, 2022

That is indeed a regression, thank you so much for bringing this up!

We have a fix pending in #2407 if you want to take a look at it and test it yourself?

@adizere adizere added this to the v1.0.0 milestone Jul 15, 2022
@adizere adizere added the A: bug Admin: something isn't working label Jul 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A: bug Admin: something isn't working
Projects
No open projects
Status: Closed
Development

Successfully merging a pull request may close this issue.

4 participants