HWI is thinking of updating its support policy such that supported wallets must implement a simulator/emulator. See https://github.com/bitcoin-core/HWI/issues/685. That's why a simulator is implemented for bitbox02, supporting functionalities of its API.
This first version of the simulator is capable of nearly every functionality of a normal Bitbox02 device, without promising any security or production use. Its main aim is to be able to run unit tests for features and test the API.
In addition, it will be configured to run automated tests in CI, which helps both us and HWI integration.
Right now, the simulator has 3 different ways to communicate with a client: giving inputs/getting output from CLI, using pipes or opening sockets. Socket is the most convenient and reliable choice in this version. It expects the clients to open a socket on port 15432, which is selected intentionally to avoid possible conflicts.
The simulator resides with C unit-tests since it uses same mocks, therefore it can be built by make unit-test.
Lastly, Python client implemented in py/send_message.py is updated to support communicating with simulator with the socket configuration mentioned above. Client can be started up with ./py/send_message.py --simulator command. To run the simulator, build-build/bin/test_simulator command is sufficient.
HWI is thinking of updating its support policy such that supported wallets must implement a simulator/emulator. See https://github.com/bitcoin-core/HWI/issues/685. That's why a simulator is implemented for bitbox02, supporting functionalities of its API.
This first version of the simulator is capable of nearly every functionality of a normal Bitbox02 device, without promising any security or production use. Its main aim is to be able to run unit tests for features and test the API.
In addition, it will be configured to run automated tests in CI, which helps both us and HWI integration.
Right now, the simulator has 3 different ways to communicate with a client: giving inputs/getting output from CLI, using pipes or opening sockets. Socket is the most convenient and reliable choice in this version. It expects the clients to open a socket on port 15432, which is selected intentionally to avoid possible conflicts.
The simulator resides with C unit-tests since it uses same mocks, therefore it can be built by
make unit-test.Lastly, Python client implemented in
py/send_message.pyis updated to support communicating with simulator with the socket configuration mentioned above. Client can be started up with./py/send_message.py --simulatorcommand. To run the simulator,build-build/bin/test_simulatorcommand is sufficient.