Giter Club home page Giter Club logo

app-bitcoin's Introduction

Ledger Legacy Bitcoin Application

Legacy bitcoin application

Bitcoin wallet application for Ledger Nano S, Ledger Nano S+ and Nano X, up to version 1.6.5.

Warning This is currently only used in order to support and maintain altcoins cloned from Bitcoin. The last stable version of the app as it was used for Bitcoin is kept in the branch legacy-1.6.6 for future reference and does not support Stax or Flex device.

Versions starting from 2.0.0 are at https://github.com/LedgerHQ/app-bitcoin-new.

Ledger Blue is not maintained anymore, but the app can still be compiled for this target using the branch blue-final-release.

The original beta specification can be found at https://ledgerhq.github.io/btchip-doc/bitcoin-technical-beta.html - with the regular set of APDUs for standard wallet operations enabled.

How to use

This application adheres with Ledger latest application guidelines.

You can refer to app-boilerplate Quick start guide for comprehensive up-to-date instructions.

Are you developing a Ledger device application?

Client Library

Include the necessary headers (copied from the js/ directory) in your web page

<head>
  <script src="thirdparty/q.js"></script>
  <script src="thirdparty/async.min.js"></script>
  <script src="thirdparty/u2f-api.js"></script>
  <script src="dist/ledger-btc.js"></script>
</head>

Create a communication object

var dongle = new LedgerBtc(20);

For each UTXO included in your transaction, create a transaction object from the raw serialized version of the transaction used in this UTXO

var tx1 = dongle.splitTransaction("01000000014ea60aeac5252c14291d428915bd7ccd1bfc4af009f4d4dc57ae597ed0420b71010000008a47304402201f36a12c240dbf9e566bc04321050b1984cd6eaf6caee8f02bb0bfec08e3354b022012ee2aeadcbbfd1e92959f57c15c1c6debb757b798451b104665aa3010569b49014104090b15bde569386734abf2a2b99f9ca6a50656627e77de663ca7325702769986cf26cc9dd7fdea0af432c8e2becc867c932e1b9dd742f2a108997c2252e2bdebffffffff0281b72e00000000001976a91472a5d75c8d2d0565b656a5232703b167d50d5a2b88aca0860100000000001976a9144533f5fb9b4817f713c48f0bfe96b9f50c476c9b88ac00000000");

var tx2 = dongle.splitTransaction("...")

To sign a transaction involving standard (P2PKH) inputs, call createPaymentTransactionNew_async with the folowing parameters

  • inputs is an array of [ transaction, output_index, optional redeem script, optional sequence ] where
    • transaction is the previously computed transaction object for this UTXO
    • output_index is the output in the transaction used as input for this UTXO (counting from 0)
    • redeem script is the optional redeem script to use when consuming a Segregated Witness input
    • sequence is the sequence number to use for this input (when using RBF), or non present
  • associatedKeysets is an array of BIP 32 paths pointing to the path to the private key used for each UTXO
  • changePath is an optional BIP 32 path pointing to the path to the public key used to compute the change address
  • outputScript is the hexadecimal serialized outputs of the transaction to sign
  • lockTime is the optional lockTime of the transaction to sign, or default (0)
  • sigHashType is the hash type of the transaction to sign, or default (all)

This method returns the signed transaction ready to be broadcast

dongle.createPaymentTransactionNew_async(
   [ [tx, 1] ],
   ["0'/0/0"],
   undefined,
   "01905f0100000000001976a91472a5d75c8d2d0565b656a5232703b167d50d5a2b88ac").then(
     function(result) { console.log(result);}).fail(
     function(error) { console.log(error); });
);

To obtain the signature of multisignature (P2SH) inputs, call signP2SHTransaction_async with the folowing parameters

  • inputs is an array of [ transaction, output_index, redeem script, optional sequence ] where
    • transaction is the previously computed transaction object for this UTXO
    • output_index is the output in the transaction used as input for this UTXO (counting from 0)
    • redeem script is the mandatory redeem script associated to the current P2SH input
    • sequence is the sequence number to use for this input (when using RBF), or non present
  • associatedKeysets is an array of BIP 32 paths pointing to the path to the private key used for each UTXO
  • outputScript is the hexadecimal serialized outputs of the transaction to sign
  • lockTime is the optional lockTime of the transaction to sign, or default (0)
  • sigHashType is the hash type of the transaction to sign, or default (all)

This method returns the signed transaction ready to be broadcast

dongle.signP2SHTransaction_async(
   [ [tx, 1, "52210289b4a3ad52a919abd2bdd6920d8a6879b1e788c38aa76f0440a6f32a9f1996d02103a3393b1439d1693b063482c04bd40142db97bdf139eedd1b51ffb7070a37eac321030b9a409a1e476b0d5d17b804fcdb81cf30f9b99c6f3ae1178206e08bc500639853ae"] ],
   ["0'/0/0"],
   "01905f0100000000001976a91472a5d75c8d2d0565b656a5232703b167d50d5a2b88ac").then(
     function(result) { console.log(result);}).fail(
     function(error) { console.log(error); });
);

app-bitcoin's People

Contributors

a-bezrukov avatar ablagoev avatar alexitc avatar apaillier-ledger avatar bigspider avatar clementperon avatar drgora avatar fabricedautriat avatar fbeutin-ledger avatar gbillou avatar greenknot avatar grydz avatar jibeee avatar josephnicholas avatar khalilbellakrid avatar lpascal-ledger avatar oto-ledger avatar pa-t avatar philippebonnaz avatar ptagl avatar raulo avatar rodendron-xrhodium avatar saltari avatar samadsajanlal avatar scotty0448 avatar sgliner-ledger avatar tamtamhero avatar tdejoigny-ledger avatar teams2ua avatar tjulien-ledger avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

app-bitcoin's Issues

Internal error, please report (0x6f01) and Invalid Signature

I was receiving Errors while using signatures produced by signP2SHTransaction function of @ledgerhq/hw-app-btc. So I created a script using bitcore-lib to cross check it against the signature produced by Ledger and pinpoint the change causing the Error. I also verified all my input params and found them to be correct.

I will detail both scripts here, though I think it is an issue of ledger's signP2SHTransaction function.

I'm using the following dependencies and node v8.9.3:

 "@ledgerhq/hw-app-btc": "^4.17.0",
    "@ledgerhq/hw-app-eth": "^4.19.0",
    "@ledgerhq/hw-transport-node-hid": "^4.18.0",
    "babel-runtime": "^6.26.0",
    "bip32": "^0.1.0",
    "bitcoinjs-lib": "^3.3.2",
    "bitcore-lib": "^0.15.0"

I have created a 2 of 2 Multisig address using the following 2 paths of my ledger- 44'/0'/0'/0/0, 44'/0'/0'/0/1.
I used the following rawTx:

0100000001917f0f1321da9d0f44806a3d6dfa15063b1b83a30e582f61ea6324b1db36a71c020000004900475221028ef85ec7646df8744eac5c0499eefc794ccd6479f6e4ed089907f6440474bc572103ed25b9cf381feaa222c9a50dfe4d0ca4c983d67762b7d042bb45de91d15b3da952aeffffffff02393000000000000017a9145d2cf0d68efd203d4f1d3b1b7c2a7cfe72a6b73f8755af71010000000017a9145d2cf0d68efd203d4f1d3b1b7c2a7cfe72a6b73f8700000000

I used the following Redeem Script:

5221028ef85ec7646df8744eac5c0499eefc794ccd6479f6e4ed089907f6440474bc572103ed25b9cf381feaa222c9a50dfe4d0ca4c983d67762b7d042bb45de91d15b3da952ae

Here's the code I used to produce it:

const bitcore = require("bitcore-lib");
const PublicKey = bitcore.PublicKey;
const Script = bitcore.Script;

var publicKey1 = new PublicKey(
  "02a9d50f9817a9cf20f3feb7ad4038e88c8bd471e90dfba3a80c2e0bfd79c89312"
); // public key for path- 44'/0'/0'/0/0

var publicKey = new PublicKey(
  "02faf805ea3652cec322dda6f7571d926f359d8abbd73af1512924151edbec90e7"
); // public key for path- 44'/0'/0'/0/1

var pubkeys = [publicKey, publicKey1];

var redeemScript = Script.buildMultisigOut(pubkeys, 2);

console.log(redeemScript.toHex());

You can decode it here: https://live.blockcypher.com/btc/decodetx/
Here is my ledger's code which is creating a signature for 48'/0'/0'/69/0/0 path:

const TransportHid = require("@ledgerhq/hw-transport-node-hid").default;
const AppBtc = require("@ledgerhq/hw-app-btc").default;

TransportHid.create()
  .then(async transport => {
    if (!transport) return console.log("err: Unable to establish connection");
    var btc = new AppBtc(transport);

    const rawTx = "0100000001917f0f1321da9d0f44806a3d6dfa15063b1b83a30e582f61ea6324b1db36a71c020000004900475221028ef85ec7646df8744eac5c0499eefc794ccd6479f6e4ed089907f6440474bc572103ed25b9cf381feaa222c9a50dfe4d0ca4c983d67762b7d042bb45de91d15b3da952aeffffffff02393000000000000017a9145d2cf0d68efd203d4f1d3b1b7c2a7cfe72a6b73f8755af71010000000017a9145d2cf0d68efd203d4f1d3b1b7c2a7cfe72a6b73f8700000000";
    const redeemHex =
      "5221028ef85ec7646df8744eac5c0499eefc794ccd6479f6e4ed089907f6440474bc572103ed25b9cf381feaa222c9a50dfe4d0ca4c983d67762b7d042bb45de91d15b3da952ae";
    const bufferedData = await btc.splitTransaction(rawTx);

    const data = 
        [{
            transaction_hash: "4a3081d782fe84d95d6e353a665bf7677cba90c2002436d169e2a30a85cc3303",
            hex:"0100000001611ccf1bf54eca69fc3069137820e297cc2fa4afab9a8b4facca5fd88ed08a8001000000db00483045022100fdd7aa8c55292a88a5f28c4c0263d4302db9ab543aaf39ef8f6d333e63b3880802200d50a48fce6b9ed818f8a3267ac759bb43ce679560e8a571ae3709bf0c42e7ed01483045022100810c43b531759dfc54b5f88fd45e215e8c24f11239a3060606685d3a396b791e022073973063d13359c217b220780a79d50887b1094b48b8cc830b0f506dc71a009701475221028ef85ec7646df8744eac5c0499eefc794ccd6479f6e4ed089907f6440474bc572103ed25b9cf381feaa222c9a50dfe4d0ca4c983d67762b7d042bb45de91d15b3da952aeffffffff030000000000000000166a146f6d6e69000000000000001f000000003b9aca00aa0a00000000000017a9145d2cf0d68efd203d4f1d3b1b7c2a7cfe72a6b73f8708807f010000000017a9145d2cf0d68efd203d4f1d3b1b7c2a7cfe72a6b73f8700000000"
        }];
        let tx = btc.splitTransaction(
            data[0].hex,
            true,
            undefined
        );
    txs.push(tx);
    indexes.push(1);
    redeemScripts.push(
        redeemHex
    );
    const inputs = _.zip(txs, indexes, redeemScripts);
    const outputScript = btc
      .serializeTransactionOutputs(bufferedData)
      .toString("hex");

    console.log("\nOutput script hex:", outputScript);

    const accountIndex = 69;

    console.log("\npath:", `48'/0'/0'/${accountIndex}/0/0`);

    await btc
      .signP2SHTransaction(
        inputs,
        [`44'/0'/0'/0/${accountIndex}/0/0`],
        outputScript,
         undefined,
        undefined,
        segwit
      )
      .then(sig => console.log("\n\nSig hash:", sig))
      .catch(err => console.log("\n\nErr:", err));
  })
  .catch(err => console.log(err));

So as I am using the above code when I toggle to segwit as true in calling Ledger P2SH function signP2SHTransaction. The ledger device accepts the provided input data and produces the invalid signature.

When I toggle to segwit as false in calling Ledger P2SH function signP2SHTransaction. The ledger device throws this error:

TransportStatusError: Ledger device: Internal error, please report (0x6faa)

While my its legacy transaction so It must run without setting segwit to true. So could you please suggest what might be the problem.

Cant connect via browser?

Hi
I am using the latest btc app ver 1.2.3 and nano s firmware 1.4.1 chrome Version 64.0.3282.186 (Official Build) (64-bit) on Mac OS

I am trying to get the address on the browser using the following code but I get the error

Ledger device unreachable. Make sure the device is…unlocked and with the correct application opened.

previously browser mode had to be set however in the new app the option is not available (I heard it was not needed anymore)

Cable seems to be ok, I can use the chrome btc app no problem

    if (TransportU2F.isSupported()) {

      TransportU2F.create().then(function(transport) {

        const btc = new Btc(transport);

        btc.getWalletPublicKey("44'/0'/0'/0").then(function(address) {

          console.log(address);

        }).catch(function(error) {

          console.log(error);

        });
      }).catch(function(error) {

        console.log(error);

      });
    }

404 readme.md

There is a 404 here in the readme:

To compile and load it on a device, have a look here: https://ledger.readthedocs.io/en/latest/userspace/getting_started.html

image

Set CONSENSUS_BRANCH_ID_SAPLING based on CoinId

Proposal to set this based on coin type. ZCash and Komodo use the same branch id, but other coins dont.

I may get time to do this as a PR someday, but just logging it here as a reminder / note / proposal

second wallet disapear

Hi, I had setup my nano S ledger with the 24 words.
I send BTC to the main account segwit (4 times) and decided to create a second one account.
I send funds to the second one : https://blockchain.info/address/34X15ArQpQz2MGXrS8b2V4fJVhko4aSgGn.

Don't know what exactly happen, but I had hided the second account.
few weeks later upgraded bitcoin app on the key.
few weeks later when I opened the BTC app again I'm unable to get back the second account.

I tried to re-create a second account, it appears but it's empty
I noticed when I delete the newly created second account that the root bip44 path is 49'/0'/2'.

I was believing index were 0 based and first address of first account must be 49'/0'/0'/0'
and first address of second account must be 49'/0'/1'/0' vs 49'/0'/2'/0'

Do I miss something, and do you have a working fix to get back access to funds of my second account ?

thanks.

EDIT

furthermore if I check device logs I saw HTTP GET Requests to

Mon, 29 Jan 2018 05:12:38 GMT,INFO,WalletLayoutRecoveryTask,Recover batch 0 for account 1
https://api.ledgerwallet.com/blockchain/v2/btc/addresses/34X15ArQpQz2MGXrS8b2V4fJVhko4aSgGn[...truncated...]

which tends to prove that it's my generated public address for second account, and you could check your servers logs you will see a hit

Bug in KMD Ledger App

I’ve been contracted by a Komodo community member to build a third-party application to support Komodo interest claiming via a Ledger device. However, development is currently blocked because I’ve found a bug in the Komodo (KMD) Ledger app.

The KMD Ledger app is based on the BTC app codebase https://github.com/LedgerHQ/ledger-app-btc and so uses the same consensus rules to validate transactions. However, these consensus rules are slightly different in Komodo. Komodo has claimable interest which is calculated by the coinage of a given UTXO. Without going into too much detail, if the coinage is over a certain age and the value is over a certain amount, the UTXO is eligible to claim interest which means its next transaction can have a higher output value than input value. This causes two bugs in the current KMD Ledger app:

  1. Valid KMD transactions are treated as invalid (because of BTC rules) and the Ledger will throw an error when you try and sign and it won’t be signed.

  2. TX Fees are often shown with lower fees than what they really are because they don’t take the newly “minted” interest coins into account, these are given directly to the miners as fees.

We need to update the KMD firmware to respect the interest UTXO rules. It should allow output value of a greater amount than input value (under certain conditions including coinage and value of UTXO) and it should also take into account the interest amount when calculating TX fees.

It looks like maybe transaction_amount_sub_be() is the main culprit, although there may be some other modifications needed to correctly calculate the TX fee.

It seems like these issues could be relatively easily resolved by adding some small if (G_coin_config->kind == COIN_KIND_KMD) {} if statements to the BTC code so everything can continue to share the same codebase rather than forking off and maintaining a separate app just for KMD for a relatively small change.

Is this something you’d be willing to accept as a PR?

Pivx account balances inaccurate after recieving zpiv

After receiving zpiv "from coinbase", the balance and account balances are inaccurate.

After Uninstalling and reinstalling the chrome app. The balances are correct, but it is a hassle to do this and have to resync.

Sign message didn't work correctly (invalid signature)

I will like to report an issue with message signing.
I have Ledger Nano S and i was asked to sign some message with my BTC account address. I pick a correct address from dropdown list (it was a previous address not a current one) put the message, got some hash. But this hash was refused as an invalid signature. Just to be sure i repeat this steps few times without success.
Later on i did the same thing with my other wallet (i did account recovery to have the same xpub on it) and it worked correctly and signature was approved.

Nano S Plus support and continue updates

Hello why did you stop development of Bitcoin Liquid Network in Ledger App?
The last update was 3 years ago. It still not support Nano S Plus and I want to build it for myself.
Do you have any recommendation what I should change to build it for Nano S Plus please?

Ledger BTC app does not work via U2F on most browsers

Observed Behavior

When interacting with the bitcoin app on a Ledger Nano S via a browser with U2F:

  1. The device and application behave correctly as long as you complete the required click actions in a very short amount of time (2-3 seconds).
  2. If you take longer than that, the device appears to behave normally, but upon finishing your interaction, the web application does not respond.
  3. Eventually, (~30 seconds) the web application receives a U2F timeout error.

We observe this behavior with Chrome and Opera, but not with Firefox.

We do not observe any issues when interacting with the Ledger Ethereum App (with hw-transport-u2f)

Because of the last two reasons, this does not appear to be an issue with the browsers, @ledgerhq/hw-app-btc, or hw-transport-u2f.

Reproducible Example

We have provided a bare-bones example app at https://codesandbox.io/s/lp0j17klj9
It is only trying to call getWalletPublicKey() at BIP32 path m/45'/0'/0'

I have also seen this behavior easily reproduced using the ledger-provided wallet-webtool at
https://ledgerhq.github.io/ledger-wallet-webtool/

System

OS: Mac 10.14
Browsers: Chrome 73.0.3683.103, Opera 60.0.3255.59
Ledger Live: 1.7.0
Ledger Nano S: Firmware: 1.5.5 (MCU 1.7)
Ledger Bitcoin App: 1.3.8
@ledgerhq/hw-transport-u2f: 4.54.0
@ledgerhq/hw-btc-app: 4.54.0

Workarounds

We are currently instructing customers to use Firefox as that is the only browser that currently seems to work.

Fast button-clicking is not a viable workaround since you have to complete your interaction before all the necessary information has been displayed on the ledger screen, making it impossible to verify transaction details.

Using hw-transport-webusb has been suggested, but it is still labeled ‘experimental’; our production application requires high security and we are uncomfortable running code so-labeled. Furthermore, hw-transport-webusb has limited browser support (https://caniuse.com/#feat=webusb), which negatively impacts our end-users.

Communications

@btchip has mentioned this is "typically the old buggy behavior", and that recompiling the bitcoin app may be a solution (I have not tried this). Even if this works, our users cannot do this, they can only use applications distributed through Ledger Live. If this is the fix, we’d need Ledger to do it.

Device freezes when calling createPaymentTransactionNew_async

I'm compiling ledger-app-btc with COIN=bitcoin_testnet and installing it on a Nano S with firmware 1.6.0 and Bitcoin 1.3.17 installed. Then I follow the usage instructions in the README, but the call to createPaymentTransactionNew_async returns with a timeout error and the Nano S freezes and has to be restarted.

If I open the installed Bitcoin 1.3.17 app instead, the call to createPaymentTransactionNew_async returns correctly with a signed transaction.

It also works if I compile with COIN=bitcoin_testnet but change the Makefile so that DEFINES_LIB is set back to blank and APP_LOAD_FLAGS is set to "--appFlags 0xa50" like it does for Bitcoin. My understanding is that those changes make the testnet app standalone and not rely on the installed Bitcoin app.

bip32_print_path(): 30-char path splitting for TARGET_BLUE is not correct integrity-wise

https://github.com/LedgerHQ/ledger-app-btc/blob/03d0cbcad04fd84394a8af4de28594deb302b980/src/btchip_helpers.c#L402-L411

Decided to take a quick look at ledger-app-btc code, and noticed that the code referenced above have potential integrity issues, although with current code the issues do not lead to actual problems because bip32_print_path is only ever called on vars.tmp_warning.derivation_pathand vars is a union that contains other member structs that has the size much larger than tmp_warning, and writing beyond derivation_path will just trumple that unused space.

That said, I see two issues that, if not fixed and then bip32_print_path used with other destinations, could lead to data integrity issue that can actually manifest.

  1. uint8_t len=strnlen(out, MAX_DERIV_PATH_ASCII_LENGTH); uses constant instead of max_out_len argument, making assumption that is not tested inside the function; I think max_out_len should be used instead of MAX_DERIV_PATH_ASCII_LENGTH

  2. the loop makes up to 4 moves (MAX_DERIV_PATH_ASCII_LENGTH/30) of the data 'forward', thus extending the length of the data up to 4 bytes, and potentially making the resulting data length 4 bytes longer than the max allowed length, overwriting 4 bytes of unrelated data.

Doesn't build and install using instructions in Ledger SDK Documentation

To summarize, there are two issues here:

  1. Makefile ignores BOLOS_ENV and BOLOS_SDK
  2. ledgerblue Python modules has issues when icons are passed in

I could not get anything in this repo to build and install using the instructions in the Ledger SDK Documentation.

As warned in the docs, this Makefile does not acknowledge BOLOS_ENV and BOLOS_SDK... instead, you have to specify GCCPATH and CLANGPATH manually.

If I run COIN=bitcoin_testnet make, I get a couple of these errors:

find: ‘/home/brandon/repos/dev-ledger-sdk/qrcode’: No such file or directory

but these appear to be harmless and it does appear to compile.

Now if I run COIN=bitcoin_testnet make load, it errors out due to a TypeError:

TARGET_NAME=TARGET_NANOS TARGET_ID=0x31100002
find: ‘/home/brandon/repos/dev-ledger-sdk/qrcode’: No such file or directory
find: ‘/home/brandon/repos/dev-ledger-sdk/qrcode’: No such file or directory
python -m ledgerblue.loadApp --appFlags 0x50 --curve secp256k1 --targetId 0x31100002 --fileName bin/app.hex --appName "Bitcoin Test" `ICONHEX=\`python /home/brandon/repos/dev-ledger-sdk/icon.py nanos_app_bitcoin_testnet.gif hexbitmaponly 2>/dev/null\` ; [ ! -z "$ICONHEX" ] && echo "--icon $ICONHEX"`   --path ""
Generated random root public key : 04a51c...
Using test master key 04a51c...
Using ephemeral key 049f372...
Broken certificate chain - loading from user key
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/home/brandon/.virtualenvs/dev-ledger-btc-DoSE2Zou/lib/python2.7/site-packages/ledgerblue/loadApp.py", line 174, in <module>
    loader.createApp(args.appFlags, appLength, args.appName, icon, path, None, None, args.appVersion)
  File "/home/brandon/.virtualenvs/dev-ledger-btc-DoSE2Zou/local/lib/python2.7/site-packages/ledgerblue/hexLoader.py", line 163, in createApp
    data = self.encryptAES(data)
  File "/home/brandon/.virtualenvs/dev-ledger-btc-DoSE2Zou/local/lib/python2.7/site-packages/ledgerblue/hexLoader.py", line 95, in encryptAES
    encryptedData = cipher.encrypt(paddedData)
  File "/home/brandon/.virtualenvs/dev-ledger-btc-DoSE2Zou/local/lib/python2.7/site-packages/Crypto/Cipher/blockalgo.py", line 244, in encrypt
    return self._cipher.encrypt(plaintext)
TypeError: argument must be string or read-only buffer, not bytearray
Makefile:189: recipe for target 'load' failed
make: *** [load] Error 1

Now, if I try again but I pull out the Python one-liner that the Makefile runs, minus the icon part, this loads the app onto the Ledger just fine:

$ python -m ledgerblue.loadApp --appFlags 0x50 --curve secp256k1 --targetId 0x31100002 --fileName bin/app.hex --appName "Bitcoin Test"

This suggests that the problem is in here somewhere, but this also returns properly:

$ python /home/brandon/repos/dev-ledger-sdk/icon.py nanos_app_bitcoin_testnet.gif hexbitmaponly
0100000000ffffff00ffffffffffffbffe0ffc9ff99ff91ff89ff19ff39ff10ff8bffeffffffffffff

This fails:

$ python -m ledgerblue.loadApp --appFlags 0x50 --curve secp256k1 --targetId 0x31100002 --fileName bin/app.hex --appName "Bitcoin Test" --icon "0100000000ffffff00ffffffffffffbffe0ffc9ff99ff91ff89ff19ff39ff10ff8bffeffffffffffff" --path ""

So it's definitely something about how loader.createApp handles that icon hex.

If I screw up the icon hex on purpose by adding a 0x prefix:

$ python -m ledgerblue.loadApp --appFlags 0x50 --curve secp256k1 --targetId 0x31100002 --fileName bin/app.hex --appName "Bitcoin Test" --icon "0x0100000000ffffff00ffffffffffffbffe0ffc9ff99ff91ff89ff19ff39ff10ff8bffeffffffffffff" --path ""
Generated random root public key : 04d4d313382cce448d43e54e085a9732b6935134f6fbc1a5b7c240d2e6cf2bbf473b46f47fbcf0735a94490aa34d680301508156f1bfd62e9d67f2d28443aba450
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/home/brandon/.virtualenvs/dev-ledger-btc-DoSE2Zou/lib/python2.7/site-packages/ledgerblue/loadApp.py", line 134, in <module>
    icon = bytearray.fromhex(args.icon)
ValueError: non-hexadecimal number found in fromhex() arg at position 0

Now that's interesting, because above it says argument must be string or read-only buffer, not bytearray.

In loader.createApp, the loader part is an instead of HexLoader that comes in via from .hexLoader import HexLoader.

Taking a peek inside ledgerblue/hexLoader.py:

data = b'\x0B' + struct.pack('>I', applength) + struct.pack('>I', appflags) + struct.pack('>B', len(appname)) + appname
...
data = self.encryptAES(data)
...
encryptedData = cipher.encrypt(paddedData)

Ah! Changed it to encryptedData = cipher.encrypt(buffer(paddedData)) and now make load works great.

So, it would appear this is actually a problem in the ledgerblue Python module.

Changelog 1.5.4

Could we have the changelog of 1.5.4

Seems to be a little patch regarding to #180 but it would be nice

Installation of v1.6.1 failed on both of my devices

Yesterday I updated the firmware of my Nano X to 1.3.0, but the reinstallation of Bitcoin app failed.

Ethereum and Ripple apps can be installed successfully, during installation I can see the "Processing" and the spinner icon on the device. However, when installing Bitcoin app, nothing shows on the device, and the installation completes quickly. Bitcoin app icon never appears on the device.

Ledger Live Manager shows Bitcoin app installed successfully but it's not true, when I switch to the Accounts screen and then back to Manager screen, Bitcoin app is shown as not installed again.

Then I reset my Nano S device (firmware 2.0.0) and tried to install Bitcoin app, the same thing happened again. Ethereum app was installed successfully but Bitcoin app failed.

Then I tried several times, with Ledger Live 2.26.1 on MacOS 10.12.6 and MacOS 11.3.1. I also tried with Ledger Live iOS App. The results are all the same: The installation of Bitcoin app all failed!

My Nano S's firmware was update to 2.0.0 a few days ago, the reinstallation of all apps after updating firmware succeeded. But this time after resetting, the installation of Bitcoin app failed. I can only assume it is a bug of this new version 1.6.1 of Bitcoin app.

Now I lost access to all of my Bitcoin assets on both of my devices. What a sad day!

Please have a look and fix it as soon as you can! Many thanks!

Malformed GET_WALLET_PUBKEY causes app to halt

In https://github.com/LedgerHQ/blue-app-btc/blob/master/src/btchip_helpers.c#L220-L222 there is a THROW which is easy to trigger by sending a GET_WALLET_PUBKEY with BIP32 chain longer than 10. The app then halts and will refuse to answer future messages until the user exists and re-enters it.

This has a benefit, I can trigger it intentionally, e.g. if my PC application thinks it's being attacked and wants to quickly disable the dongle. But it would probably be better to have a dedicated message for this.

A more consistent behaviour would be to return BTCHIP_SW_INCORRECT_DATA to the caller.

Wrong signature for segwit transactions with multiple inputs

In trying to update HWI to get trusted inputs for segwit inputs, it seems like version 1.4.2 is producing incorrect signatures for transactions containing multiple segwit inputs.

I've largely been following the steps given in the documentation. Using btchip-python, I've been calling startUntrustedTransaction with inputs that have been trusted and using the scriptcodes for those inputs. Note that this is contrary to the documentation which says to use blank scriptcodes for this step in segwit transaction signing. However in my testing, using a blank scriptcode resulted in a bad signature. Then finalizeInput is done to set the outputs. Then for each input, startUntrustedTransaction is done again with only that input specified and its scriptcode. Then untrustedHashSign is done for just that input.

This works for segwit transactions with a single segwit input. But does not work for such transactions containing multiple inputs. For those transactions, a signature is produced, but the signature is not valid for that transaction.

The same code works on app version 1.3.14 (the default provided by speculos) with the change that getTrustedInput is not called for those segwit inputs.

The app should indicate whether the address to send to is own address or foreign address

I've noticed following thing when trying to accelerate transactions (may apply in other cases too).

The browser extension provides me with a set of addresses, and I have no choice but to confirm them, and I have no idea what those addresses are.

This mode of operation is inconvenient and provides a security risk, since if the browser is compromised, all addresses in question could be foreign ones.

One way to mitigate the issue would be to let the app show the user distinction if the address in question is own or foreign

Build error, unknown type

I have my sdk defined ready as I have easily loaded other applications before, but cannot seem to load the BOLOS application for bitcoin.
Running make load yeilds the follow result ($COIN defaults to bitcoin):

BOLOS_ENV=/home/dy5es41/Desktop/ledger-dev
BOLOS_ENV=/home/dy5es41/Desktop/ledger-dev
[CC]	  obj/btchip.o
In file included from src/btchip.c:20:
In file included from src/btchip_internal.h:22:
In file included from src/btchip_public_ram_variables.h:25:
include/btchip_context.h:99:5: error: unknown type name 'cx_blake2b_t'
    cx_blake2b_t blake2b;
    ^
1 error generated.
/home/dy5es41/Desktop/ledger-dev/nanos-secure-sdk//Makefile.rules_generic:51: recipe for target 'obj/btchip.o' failed
make: *** [obj/btchip.o] Error 1

Am I missing dependencies? How may I fix this problem? I am assuming that cx_blake2b_t is really defined in one of the headers

Can not send BSV when BTC and BCH app update to 1.4.6

Dears,

When Ledger update BTC and BCH apps at 1.4.6.

I can not send BSV on Electrum SV.
It always show "The sign path is unsual" on BCH apps. And I cannot sign althought I signed on Ledger but it still shows "The sign path is unsual"
image
image

So, I am so worry about that. Please help me back up old version.

Thank you and best regards,
Pao

Can't get passed "Open non genuine app?" confirmation on compile and install

Can't get passed "Open non genuine app?" confirmation on compile and install

Output of make load:

make load                                                                                                                    ✔   master 
TARGET_NAME=TARGET_NANOS TARGET_ID=0x31100004
BOLOS_ENV is not set: falling back to CLANGPATH and GCCPATH
CLANGPATH is not set: clang will be used from PATH
GCCPATH is not set: arm-none-eabi-* will be used from PATH
BOLOS_ENV is not set: falling back to CLANGPATH and GCCPATH
CLANGPATH is not set: clang will be used from PATH
GCCPATH is not set: arm-none-eabi-* will be used from PATH
python -m ledgerblue.loadApp --curve secp256k1 --tlv --targetId 0x31100004 --delete --fileName bin/app.hex --appName "Bitcoin" --appVersion 1.3.9 --dataSize `cat debug/app.map |grep _nvram_data_size | tr -s ' ' | cut -f2 -d' '` `ICONHEX=\`python /home/mxaddict/.sdks/bolos/nanos/icon.py nanos_app_bitcoin.gif hexbitmaponly 2>/dev/null\` ; [ ! -z "$ICONHEX" ] && echo "--icon $ICONHEX"`  --path "" --appFlags 0xa50
Generated random root public key : 044a6fa7144882182532430b3e1ec1bd73a51ddffc8eed3dcff8e844127fd785fbd43ac9303bfe818afe1684e86662bbdf4b56d8c3d5897c1a1cc0cf4950e1b8ba
Using test master key 044a6fa7144882182532430b3e1ec1bd73a51ddffc8eed3dcff8e844127fd785fbd43ac9303bfe818afe1684e86662bbdf4b56d8c3d5897c1a1cc0cf4950e1b8ba 
Using ephemeral key 0434fd16816d79a6b36b375c4acca7b825b166d7a1a5a23e094f9c667b642470f342b90062d7ccf18380b76f83c6840a5150ce144aa4b5cb9e9fba46ea7e37dea0
Broken certificate chain - loading from user key
Target version is not set, application hash will not match!
Application full hash : 66f8bc9d95d155c76519d4844b27fea24a9c737b3f33b94b4da8d0b88627fec5

Then I'm able to confirm manage permissions on device.

And install the app

Then I open the app and get stuck on this screen:
IMG_20190521_012357

KMD interest is not being claimed/enabled

The ledger NANO S does not claim the interest nor does it set a locktime when issuing a transaction which means our interest gets lost.
Can someone please look into this?

The KMD lead-dev already opened an issue with a detailed explanation.
LedgerHQ/ledger-nano-s#21

Please feel free to ask for further details if you need such.

Base58 is broken in master

Building the master branch appears to have a broken Base58 implementation.

This commit appears to be the culprit: 8866872 (PR #76)

KMD has a P2PKH prefix of 0x3C which should result in a Base58 address prefix of 'R'.

If I checkout the commit mentioned and build the BTC+KMD apps I get multiple KMD addresses that don't start with 'R' and don't have valid Base58Check checksums. For example the derivation path 44'/141'/0'/0/5 should result in the KMD address RNAeh18GPwx1udYAq5mZ3eJaU4d6f3ceom but instead results in 6ecJtMem7cRudYAq5mZ3eJaU4d6f3ceom.

If I checkout the previous commit before that and rebuild the apps everything works as expected.

Commit 8866872: 6ecJtMem7cRudYAq5mZ3eJaU4d6f3ceom

await ledger.getWalletPublicKey(`44'/141'/0'/0/5`)
// {publicKey: "04dcc34020b171b54dea212462b32f711ec8cbb0ec3bafc5167e46511fca3a40079cfa8e0c444b81bd9200f03b5cb5330abe37a2a9575c4696bf21a8e1b9a85f5c", bitcoinAddress: "6ecJtMem7cRudYAq5mZ3eJaU4d6f3ceom", chainCode: "e0798cc24a5059fa63ebb89f24872481f92e8eacaa76c2fa179edf65de81976c"}

Commit 992a2f4: RNAeh18GPwx1udYAq5mZ3eJaU4d6f3ceom

await ledger.getWalletPublicKey(`44'/141'/0'/0/5`)
// {publicKey: "04dcc34020b171b54dea212462b32f711ec8cbb0ec3bafc5167e46511fca3a40079cfa8e0c444b81bd9200f03b5cb5330abe37a2a9575c4696bf21a8e1b9a85f5c", bitcoinAddress: "RNAeh18GPwx1udYAq5mZ3eJaU4d6f3ceom", chainCode: "e0798cc24a5059fa63ebb89f24872481f92e8eacaa76c2fa179edf65de81976c"}

With the problematic build I checked the first 100 public KMD addresses and 23 were invalid.

I also checked up to the first 1000 BTC addresses and they were all ok.

0 fee transactions are accepted by the server but do not propagate

Recently I tried sending 0-fee transactions from Bitcoin wallet and Bitcoin Cash wallet. In both wallets, the transaction was market as successful, and it shows in the app, but the transaction actually never confirms and if you check it out through the blockchain explorers, it's not found.

Here's an example BTC transaction:
3901cfd1ae18ab18ad442d36593158e3ecaa8396df87bf099a42e197ce36dc35

Resetting the app does not fix this issue

Fake version 2.0.0 in Ledger Live

Hi I just updated to a version 2.0.0 from the store:
image
This version does not seem to exist. Thus I cannot verify what I am running at the moment.
Please advise.

add ( ICP) coin

hi. Please add internet computer ( ICP) coin on ledger This currency is ranked 16th with $8 Bn Market cap

Incorrect display of bech32 addresses on Ledger device

1.1.18 version of the Bitcoin application (the same with 1.1.10 on Testnet). Used with Electrum 3.0.5 and btchip_python-0.1.23.

If the transaction has only one bech32 output, the displayed address on the device is incorrect, it shows P2PKH (starting with "1") address. It is signed correctly (tested on testnet). If there are more outputs (regardless of type), the bech32 address is displayed correctly.

Also, P2WSH bech32 addresses are displayed without final symbols. They are longer than P2WPKH by 20 characters, and these are not displayed but the address is appended with "BTC" or "TEST" (on testnet).

Address Verification

The addresses are too big for Ledger Nano S screen, and the speed is also too fast.

I saw that for some cryptos it shows only the beginning and the end, omitting the middle part, what makes it much simpler and user friendly. Isn't it possible to do it for all of them? And what are the risks of it?

Another idea would be to navigate through the address using the buttons and confirm it pressing both at the same time, or even some kind of 'checksum' of the address on the device and Ledger Live and simplify it to only 6 digits for example.

Add support for showing multisig receiving address on Ledger

Although Ledger wallet supports showing the address when receiving Bitcoin, and supports signing messages for sending Bitcoin from a multisig address, it doesn't support showing the address when receiving Bitcoin.

To implement this feature, all public keys must be sent in a command. One option for implementing this feature would be to implement the Get Public Key command (though it wouldn't be able to return a public key, just the constructed address).

ledger nano s cannot verify and approve send transcription on device.

my device cannot verfiy and approve send transcription, i resfactory my device, reinstal ledger live and clear my ledger live cash but not solved. just wait in loading page . i try in both of the ledger live windows 10 and ledger live android . no live chat and noanwser with support . and i need tell you just one of my wallets cannot verfiy and approve send transcription on the device. other wallets verify and approved. i need my BTCs emergency . please help me.|
@gre @meriadec @valpinkman @EricLarch @pollastri-pierre @btchip @onyb

Nano S uses uncompressed keys even on Segwit paths

Segwit transactions are supposed to use compressed keys only, and uncompressed ones will be made invalid in the future.

This issue has two sub-issues (probably related) namely:

  • getWalletPublicKey() method always returns public keys in the uncompressed form: \x04+x_coord+y_coord

  • getFirmwareVersion() method says that keys are uncompressed.

dongle = getDongle(True)
app = btchip(dongle)
app.getFirmwareVersion() 

replies that: {'specialVersion': 48, 'version': '1.1.18', 'compressedKeys': False} when used on the official app installed from the manager.

I initialized my Nano S by restoring my BIP39 mnemonic, segwit path, no passwords.

A quick inspection on the generated P2SH-P2WPKH addresses suggests that they indeed correspond to the compressed forms, and in at least one case the wallet spent from a compressed-key associated segwit input, but I have not systematically checked that.

Native SegWit Support for Vertcoin (VTC)

Currently you can't send to vtc1 addresses (bech32) on Ledger Live (please respond if this is a Ledger Live issue instead) and also you can't create Native SegWit accounts on Ledger Live for Vertcoin. These features have been supported in the Vertcoin Core wallet since 2017. I assumed that this is a feature here due to Vertcoin being a Bitcoin fork that is developed in the same repository.
Thank you for your continued development and support of so many crypto assets.

Feature request: allow switching to your own full node

I think that being able to use your own full node is a good alternative to using your backend. I'm running a full node anyway, and I believe that being able to use the device with it can provide better privacy and a redundancy in case your backend is having issues and I need to broadcast transaction urgently

multiple coins under single app?

It seems this app is compiled separately for each coin, although they differ only in build parameters like BTCHIP_P2PKH_VERSION and BTCHIP_P2SH_VERSION?

Could these parameters be moved into the application settings? It would save space on device to use just one app with an initial coin-selection prompt.

Am I overlooking any problems with this?

Has Ledger ever used Libbitcoin?

Libbitcoin Explorer (bx seed), used by many crypto wallets to generate private key entropy, is flawed and hackers have been silently draining people's money across multiple blockchains. https://milksad.info/

Has Ledger ever used Libbitcoin?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.