Splitting your Ethers securely on your Nano S

09/19/2016 | Blog posts

We covered in the past an example of how dynamic applications supported by Ledger Nano S and Blue were quite useful to secure interactions with smart contracts for TheDAO tokens — we’ll now cover a similar use case for splitting Ethers, along with an example for power users before offering a simple User Interface around it.

This article is less developer oriented than the previous one.

ETH, ETC and the splitting problem

Let’s see why splitting is necessary in the first place.

When the Ethereum fork happened, all existing coins were duplicated on both branches on the fork (the original chain, Ethereum Classic — ETC and the forked chain, Ethereum — ETH). For the clients and the nodes, both chains are indistinguishable, which means that if the right conditions are met for an account on both sides of the fork (if both have the same number of transactions and acceptable balances), transactions sent on one chain will be duplicated on the other one automatically while the nodes broadcast it. This creates very confusing scenarios, and can be solved by splitting.

Splitting is achieved by sending a transaction to a smart contract existing on both chains and having a different behavior on each one — it will redirect the funds to a different account on each side.

You can find preexisting splitting contracts to run into your favorite Ethereum client, and several third parties such as Shapeshift or MyEtherWallet are offering a splitting contract as a service. Both are quite useful but create security risk that dynamic hardware wallet applications can solve.

Splitting security issues

Some third party services can require your private key associated to the account to split, which is of course a large security risk if malwares are listening or if the user is tricked into an hostile service impersonating the real one (this unfortunately already happened for MyEtherWallet)
All splitting contracts share the same security risk — the contract parameters include the destination addresses on both sides of the fork, and the contract has no way to verify that these addresses belong to the user.

To solve those issues, a hardware wallet dynamic application aware of the contract can enforce that the address is derived from the Hierarchical Deterministic wallet and of course never expose the private key associated to the account.

Performing a split

To use our splitting sample, proceed as follows :

python.exe -m ledgerblue.loadApp --targetId 0x31100002 --fileName bin/1.0/token-chainsplit.hex --appName "ETC/ETH Split" --icon 0100ffffff0000000000000000000080008000c000c000e000c0002000c000c0008000000000000000 --appFlags 0x40 --path "44'/60'" --path "44'/61'" --curve secp256k1 --signature 30450221009cef8dfecf1ec5dad3556a1b59464e514083be1e2820f2534d876323b818c07a02205d72b514142ae85be723c4fee64e305a57b8296cd79704b06cfdfa80870b7b3e
python splitEther.py --broadcast

Developers, join our Slack!

The ability to provide clear information to the user on what a smart contract is doing is a key functionality of the dynamic applications provided by Nano S and Ledger Blue — expect more for popular contracts such as the Token standard (ERC 20) and join our developer slack at Slack to discuss your use cases and integration.
The code of this sample is available on https://github.com/ledgerhq/blue-app-eth in the src_chainsplit directory — for more details regarding the modifications allowing to parse the smart contract data, you can refer to our previous post on that topic.

BOLOS series

<< Dynamic secure applications with BOLOS and Ledger Blue