ledgerhq / app-bitcoin Goto Github PK
View Code? Open in Web Editor NEWBitcoin wallet application for Ledger Blue and Nano S
License: Apache License 2.0
Bitcoin wallet application for Ledger Blue and Nano S
License: Apache License 2.0
hi. Please add internet computer ( ICP) coin on ledger This currency is ranked 16th with $8 Bn Market cap
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.
BitGo users would like to use their Ledger devices to sign segwit v0 inputs in their transactions, but it is currently not supported by ledger-btc.js
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.
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.
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.
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
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
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?
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.
When interacting with the bitcoin app on a Ledger Nano S via a browser with U2F:
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
.
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/
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
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.
@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.
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
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
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.
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:
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.
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?
Please add support to generate both xpub, ypub and zpub.
As QRC tokens become more and more important, I'd love to store them securely on my Nano S.
Please see here for a list of all QRC tokens.
Could we have the changelog of 1.5.4
Seems to be a little patch regarding to #180 but it would be nice
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.
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"
So, I am so worry about that. Please help me back up old version.
Thank you and best regards,
Pao
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.
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.
This feature is necessary for safe receiving, but seems to only be available for BTC legacy and BCH wallets.
I'm using a Nano S.
The issue happens when you try to deploy a newly compiled token following the official tutorial at Step 4 on deployment: https://developers.tron.network/docs/issuing-trc20-tokens-tutorial
See error message:
After release @ledgerhq/hw-app-btc:5.3.0 the function serializeTransactionOutputs is missing.
What alternative there is to generate outputScript ?
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
Electron Cash SLP defaults to the 245 (SLP) coin type for its derivation paths:
https://github.com/simpleledger/Electron-Cash-SLP/blob/master/lib/keystore.py#L803
This causes newer versions of app-bitcoin
to warn about an unusual derivation path. The 245 derivation path should be considered normal for Bitcoin Cash.
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.
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
During the signature of a transaction with a lot of inputs, the Blue application (tested with Zcash) will crash if the user touches any part of the screen.
See Youtube video (sent directly to the team for privacy reasons)
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);
});
}
Hi
I am using a nano s 1.3.1 on ubuntu 16.04 and using the python loader here with python 3.5
https://github.com/LedgerHQ/blue-loader-python
and the nanos-1314 sdk
the app makes and loads however there is no icon
I get this error during make maybe message?
/home/christian/nanos-secure-sdk//Makefile.glyphs:29: recipe for target 'src/glyphs.h' failed
make: [src/glyphs.h] Error 1 (ignored)
Currently, signing a transaction involves a stateful protocol in which bits and pieces of the transactions need to be sent over.
Are there any plans of creating an interface that accepts a PSBT and does all the signing in one go?
As per the spec (https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#Signer) no additional data sources should be required if the PSBT is constructed correctly.
To summarize, there are two issues here:
BOLOS_ENV
and BOLOS_SDK
ledgerblue
Python modules has issues when icons are passed inI 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.
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.
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?
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).
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
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).
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
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?
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_path
and 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.
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
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.
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!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.