bitcoin-core
add onekey device support
A GHA run in my repo: https://github.com/OneKeyHQ/HWI/actions/runs/6212074159
the newest passed GHA https://github.com/OneKeyHQ/HWI/actions/runs/7110790185
Hello @achow101, we are still waiting to merge this PR, we have already rebased to latest commit and addressed questions and issues above. Could you kindly reveiw again base on our latest commit?
Can you please rebase it?
Of course, But there seems to be a problem with the simulator's compilation dependency installation
Looking at the code, it seems this PR is not adding anything substantial.
The Onekey devices are just clones of Trezor One and Trezor Model T. They even copied the internal names (T1B1 and T2T1). I am not sure it is really worth complicating the codebase and risking rendering of Trezor (and all its clones) support unusable (this PR modifies trezorlib too).
Since Onekey tries to be compatible with Trezor (their FAQ mentions "support all third-party clients supported by Trezor"), maybe we should not change HWI at all and let Onekey be detected as Trezor via HWI?
@brunoerg @achow101 I fixed the onekey_t emulator Segmentation fault issue due to the CI env. If possible, please rerun the CI. Thanks.
The Onekey devices are just clones of Trezor One and Trezor Model T. They even copied the internal names (T1B1 and T2T1). I am not sure it is really worth complicating the codebase and risking rendering of Trezor (and all its clones) support unusable (this PR modifies trezorlib too).
OneKey Touch/Pro are using different MCU and SE than Trezor T/One, which means hardware and low-level codes are totally different. We also designed and built our own GUI since the screen resolution is different, and we have no interest to have GUI looks the same.
OneKey firmware was forked from Trezor, but I don't think building on top of a fork should count as a counterfeit, that's not how open-source projects work. Many great projects were based on a fork.
Since Onekey tries to be compatible with Trezor (their FAQ mentions "support all third-party clients supported by Trezor"), maybe we should not change HWI at all and let Onekey be detected as Trezor via HWI?
Due to the nature of initially forked from Trezor, our protocol is compatible with Trezor. However, it does not work the other way around, since OneKey has many things Trezor does not support. This is why we need a separate implementation to fully support our device, and adding OneKey support to HWI is the first step.
Looking at the code, it seems this PR is not adding anything substantial.
Introducing fewer changes possible was suggested by @achow101. Ideally, we want a separate library path.
Looking at the code, it seems this PR is not adding anything substantial.
The Onekey devices are just clones of Trezor One and Trezor Model T. They even copied the internal names (T1B1 and T2T1). I am not sure it is really worth complicating the codebase and risking rendering of Trezor (and all its clones) support unusable (this PR modifies trezorlib too).
Since Onekey tries to be compatible with Trezor (their FAQ mentions "support all third-party clients supported by Trezor"), maybe we should not change HWI at all and let Onekey be detected as Trezor via HWI?
Hi @prusnak
I totally understand your worries.
I'm a big fan of Trezor—my very first hardware wallet was a Trezor back in 2014.
Yes, a lot of OneKey's firmware was indeed developed on the shoulders of Trezor. We strictly followed Trezor's open-source license and had no intentions beyond that.
It’s worth mentioning that all of OneKey’s app code is completely open-source. We do have plans to fully rebuild our firmware using the RTOS architecture, but that's going to take some time.
To draw an analogy, if Trezor is like Google, then OneKey would be like Xiaomi. Sundar Pichai doesn't mind other manufacturers using Android's code in an open-source manner, because it actually helps Google solidify its position and market share in mobile operating systems. Similarly, I believe OneKey genuinely helps promote Trezor’s communication standards, which is beneficial for Trezor.
And let’s be honest—there's a big, annoying elephant in the room. That’s the one we really need to aim to surpass, right?
