New versions of the bootloader can be downloaded and built from https://github.com/trezor, but it seems as though the only option is to destroy the outer shell of the Trezor, then flash the new bootloader manually. Can you not use the "trezorctl" commandline client that comes as part of python-trezor?  It has a firmware-update option that allows you to update the firmware... So, if you can build older versions of the firmware, it is possible you could you could do incremental updates until you get to the necessary bootloader version, to be able to update using wallet.trezor.io Failing that... have you tried contacting support at SatoshiLabs and asking them how to get it updated? |
|
|
|
First sorry if it's a newbie question!
I'm try to understand how this platforms work, specially the part for deposit/withdrawal.
I read about bitcoin daemon, so i understand how they generate account/address for users but where i misunderstand it's about the notifications of deposit and withdrawal and the usage of the balance information in database, they use wallet notify for that?
I doubt it... I would expect that exchanges (especially the larger ones) are most probably running custom software, rather than simply using Bitcoin Core and using "walletnotify" to trigger scripts... The general process that most seem to follow is that after a deposit is made to a given address, a "trigger" will then update a users account, adding the appropriate amount to the balance. Although most exchanges will mark that particular amount as "pending" until a minimum number of confirmations have been received (generally around 6 confirmations). |
|
|
|
Electrum cant have possibly charge me 90% on a transfer could they?
Electrum (and wallets in general) DO NOT "charge" you transaction fees... That is not how Bitcoin works. Your transaction includes a fee that becomes part of the "reward" paid to a miner for mining the block. Fee rates are used as a way to "prioritise" your transaction, you want fast confirmation? == BIG fee... you don't care how long it takes? == use low fee. Paypal then charged me 30% so after expecting about $11 I got $0.78. If this is correct I am done with bit coins. What gives?
As others have already explained... using a LOT of small value inputs results in a transaction that has a large data size... transaction fees are generally calculated on the overall "data" size (currently termed "weight" since the implemenation of SegWit) of the transaction not the "value" of the transaction. As your transaction was very large from a data size perspective... over 3000 bytes, whereas a "typical" transaction with 1 input and 2 outputs is around 200 bytes. So, your transaction was about 15 times larger than a normal transaction. The result being that while the fee rate paid of 56 satoshis/byte wasn't overly excessive... the total fee paid seems relatively high... as 3334 * 56 = ~186000 sats... or ~90% of what you were attempting to send. I'm not sure why Electrum subtracted the fee from the amount you were attempting to send instead of "adding" it tho... possibly because your total balance wasn't high enough? But I thought it would just say "insufficient funds" in that instance? |
|
|
|
And just to confirm that it was indeed ViaBTC: Included In Blocks 573036 ( 2019-04-24 16:04:02 + 3,108 minutes )
...
Relayed By ViaBTC
"only" 3108 minutes...  hope the paid acceleration fee wasn't toooo horrific! Given you were only sending ~0.016 BTC (~US$90)  |
|
|
|
I was already thinking that there probably was something off about the code used for generation. I still find it quite weird that they're invalid and valid at the same time though.. How exactly does KwFAa6AumokBD2dVqQLPou42jHiVsvThY1n25HJ8Ji8REf1wxAQb == KwFAa6AumokBD2dVqQLPou42jHiVsvThY1n25HJ8Ji8REGDgzcJ1 ? Does the checksum not matter with wif keys?
Or i guess they share the same private key, from which the adress is derived, and this WIF encoded from again, correct? No, they're effectively different private keys... it is just the way the individual sites are coded to do their conversions. It would appear that some of the sites (ie. bitaddress.org and bitcoinpaperwallet.com) are simply truncating the generated HEX when converting from WIF to HEX. So they're effectively ignoring the last couple of digits... and keeping the "bad" leading 00's... which gives the impression that the "...wxAQb" WIF key == "...DgzcJ1" WIF key... which is obviously NOT true!  Whereas, the gobittest.appspot.com script... keeps the WHOLE hex and doesn't discard anything:  So, if we manually discard the leading 00's and keep the last 64 characters (32 bytes)... we get the "correct" hex key of: BF9C46A7C40AAF96ED20CFC0AB0F929D9BE1748AF89B37E9EFB4CDB98DA6B0CB |
|
|
|
Really? I'm currently using Mycelium to monitor new transactions as they are segwit. I think segwit is the default. How do I re-import my Ledger showing the legacy balances?
Ok, so I've just checked this... and within Mycelium, all of my Ledger transactions, both "Legacy" and "SegWit", show in the same Mycelium account. When I click "receive", I can select the address type as "Legacy (P2PKH)", "Segwit compatible (P2SH)" and "SegWit native (Bech32)". However, in Ledger Live... these transactions and addresses are divided between my "Bitcoin 1" account and "Bitcoin 1 (legacy)" accounts... Bitcoin 1 == SegWit "P2SH" addresses/transactions (ie. 3-type addresses)... Bitcoin 1 (legacy) == Legacy addresses/transactions (1-type addresses). When I was setting up Ledger Live and setting up the "accounts"... It automatically detected the "legacy" and "segwit" accounts and created them as separate accounts (separate balance, separate transaction lists etc) I use Ledger Manager live in desktop and all transactions there are in total not separated. Is it the same with Ledger Manager for android?
Really? As I said above, my old "legacy" transactions and newer "segwit" transactions display in separate accounts with separate transaction histories.  |
|
|
|
If we delete the leading 00 we end up with 32 bytes, which looks like a correct size, still Ian Coleman's website doesn't recognize it.
On the other hand BouncyCastle.Crypto.dll 1.8.15362.1 has no problem with it.
That's because Ian Coleman's Bitcoin Key Compression website will only accept hex public keys... private keys have to be WIF or BIP38  Input Key
Can be a public key (hex encoded) or a private key (WIF or BIP38 encoded)
|
|
|
|
Your WIF format private key (KwFAa6AumokBD2dVqQLPou42jHiVsvThY1n25HJ8Ji8REf1wxAQb) seems to be converting to a "bad hex"... if we look at the length: 00BF9C46A7C40AAF96ED20CFC0AB0F929D9BE1748AF89B37E9EFB4CDB98DA6B0CB
123456789012345678901234567890123456789012345678901234567890123456
We can see that it is 66 characters (33 bytes) long!!?! Private keys are only supposed to be 64 characters (32 bytes) of hex! I would guess there is an error somewhere in private key generation in your script... most likely because it doesn't include this patch from the botg.sh shell script: 0.0.3 -remake key if it's not exactly 64
I believe the exact bit of code is: hexsize=$(openssl ec -text -noout -in data.pem | head -5 | tail -3 | fmt -120 | sed 's/[: ]//g' )
while [ ${#hexsize} -ne 64 ]
do
openssl ecparam -genkey -name secp256k1 | tee data.pem &>/dev/null && hexsize=$(openssl ec -text -noout -in data.pem | head -5 | tail -3 | fmt -120 | sed 's/[: ]//g' )
done
openssl ec -text -noout -in data.pem | head -5 | tail -3 | fmt -120 | sed 's/[: ]//g'
It generates hex keys until it gets one that is exactly 64 chars long... this size check is NOT in that .php script... and I believe this is the likely reason why your script is generating "invalid" hex private keys and then converting them to invalid WIF keys.
Now, I know that it's a trust issue here with an exe, I don't even know if the link is not hidden by the forum.
If you PM me an e-mail I gladly post the link again (or I'll simply send it by e-mail). I can also give you the source code, it's 99% the old good "Bitcoin Address Utility", it's in c#, just ask.
Why reinvent the wheel? Once you have the "correct" hex... you can simply plug it into the "Private key to wallet import format" part of http://gobittest.appspot.com/PrivateKey or bitaddress.org (download and run offline etc)... or even the bitcoinpaperwallet.com that he was checking with will work just fine with HEX private keys... |
|
|
|
Why would you want to do this? So that you don't have to keep accessing your live wallets (eg. in Ledger) to check your balances.
That seems completely redundant... Why would you want to create "another" watching only wallet using Electrum, when "Ledger Live" is already a perfectly adequate watching only wallet (that can also watch balances for several other currencies other than just BTC)? You do realise that you don't actually need the Ledger device connected to be able to open and view all your balances in Ledger Live right? That was one of the major reasons why Ledger released the native Ledger Live apps Even if you're determined to use Electrum, going to all the trouble of exporting the xpub is not necessary if using Electrum. Simply use the "Standard Wallet -> Use a hardware device" option and connect the Ledger... it will automatically import and setup the "watching-only" wallet for you and if you DON'T encrypt the wallet file, you can just simply not connect the device when you open the wallet and it will act exactly like a watching only wallet. |
|
|
|
Okay so i tried to request another btc withdraw this time. When i put receive in btc on ledger live, it generated a different btc address this time. Now that means if i used the previous btc address from last time, that is still my receive address correct? Let say i copied/pasted that address somewhere. I would still receive btc to that address right?
Of course... all wallet addresses remain "valid"... regardless of how many you generate and/or use for any given "account" The other thing is this. Can you check all your btc receiving addresses similar to like electrum? When i used electrum, i could see all my receiving addresses, change addresses etc. Thus any of those addresses i copy and paste, i could have btc sent to that address etc.
You can't do it directly in Ledger Live unfortunately... the only way to do it would be to take the "xpub" for the account you want to see the addresses for and then generating the addresses from that. You can do this by clicking the spanner in the top right corner:  Click on "Advanced Logs":  Your "xpub" will be shown:  You can use this XPUB on IanColeman's Mnemonic Code Converter. - Paste it into the "BIP32 Root Key" field. - If using SegWit addresses ("3"-type), then click "BIP141" tab - Set "BIP32 derivation path" to: m/0 - Set "Script semantics" to: "P2WPKH nested in P2SH" All your "receive" addresses will be displayed... you can view move by clicking the "more rows" button. If you want to see "change" addresses, set the "BIP32 Derivation Path" to: m/1 NOTE: If you're using a "Legacy" account on the Ledger ("1"-type addresses), then click "BIP32" tab instead of BIP141... select "Custom Derivation Path" and use m/0 and m/1 for "receive" and "change" addresses respectively. |
|
|
|
I like the new blockchair "priority" tag...  Really gives you a sense of where your transaction is in the current "queue"... almost 37000th out of 52000... that transaction isn't going anywhere in a hurry. What are my options at this point to try and get the transaction picked up and confirmed?
Basically... your options are "wait". Would also like to know if I can be sure the transaction will eventually go thru, if I wait long enough, or will it expire at some point? Most likely it will confirm at some point... really depends on whether or not the queue of unconfirmed transactions drops enough that transactions around your fee level start getting included in blocks. Given the current price pump... it might take a few days. |
|
|
|
Yepp, its just bunch of single vanity addresses.
Having conducted a couple of (brief) experiments... it would appear that Mycelium will no longer generate SegWit addresses from older, uncompressed private keys. So, if you imported uncompressed private keys, it will now only generate the Legacy addresses for those specific keys. However, if you import the corresponding compressed private key... it will default to showing the SegWit (P2SH "3"-type and P2WPKH "bech32") addresses, but if you click "Receive" then it will give you the option of receiving to the "Legacy" (P2PKH) address from the dropdown. So, as suggested by Coiner.de, maybe try "converting" those private keys using something like bitaddress.org (download, then run offline etc etc)... to swap from the uncompressed to the compressed form of those private keys. No need to use segwitaddress.org tho, just import those compressed private keys into Mycelium and hopefully that will show you the appropriate SegWit addresses. |
|
|
|
when your tx is no longer in blockcypher's mempool, it's an opportunity to push new tx
instead of just rebroadcasting, OP should create a new tx with higher fee to get faster confirmation
That probably won't work if the transaction is still showing on some of the bigger block explorers (like blockchain.com)... it'll be rejected as a double spend. In any case, that transaction is still showing on: blockcypher blockchain.comblockchairbtc.comBlockchain.com and blockchair.com both show the "first seen" time as "2019-04-22 06:12 (UTC)", although blockcypher shows as ~7 hours ago (which would be something like 1830 UTC on 23rd... indeed the "API Call" info shows it as: "received": "2019-04-23T18:38:54.719Z Not sure if someone rebroadcast it, or blockcypher flushed their mempool and rebuilt it? In any case, with the current mempool being some 25 blocks deep... with 40K+ unconfirmed transactions... and 12+ blocks worth of transactions being 10x the size of the OPs fee... I'd be willing to bet that the OPs transaction is going nowhere fast |
|
|
|
|
A couple of things to try:
- Disconnect the ledger device from the PC
- Make sure all other applications, websites and programs that connect with the ledger device are closed
- Restart Electrum
- When creating the wallet... make sure you have connected the device, entered PIN and then selected the "Bitcoin" app on the device, so that you're on the "Use Wallet to view accounts" screen.
|
|
|
|
As for BTG issue, Ledger Live is only supporting SegWit addresses, and you probably have your BTG in legacy address. Because of that you can see it in Chrome app, but not in Ledger Live.
That's not entirely true... I have "BTG Legacy (unsplit)" showing in Ledger Live. Although, "new" accounts that are added default to m/49'/156'/x'/0... it still synced the legacy account first at m/44'/0'/0' |
|
|
|
I am using electrum and it usually had parent pays for the child. But can't see this option for the transaction. I have already made mempool.
That should be "child pays for parent" If you look at the transaction details (right click - details)in Electrum (or block explorer)... how many outputs are there? If there is only 1 output, then there was definitely no "change" output created. If there are multiple outputs, but none of them are highlighted "yellow", then again, there was no "change" output going to the local wallet. If there is no "change" going to a local wallet address, only the receiver would be able to execute CPFP. Also, because there is no "change", there would be no chance to execute RBF (Replace by Fee) either, as there is no "spare money" available to be able to bump the fee... That likely means that blockcypher (for whatever reason) has dropped the transaction from their mempool... while blockchain.com has not. You may need to try rebroadcasting the transaction. If you click the "copy" button on the "transaction details" window, it'll copy the raw transaction hex... you can then broadcast that raw transaction hex via Blockcypher if it bothers you that it isn't in their mempool. |
|
|
|
i have another question..how will i spend it on my onfaucet.com?
Unfortunately, it would appear that onfaucet.com (like most faucets) is most likely a "scam"... Looking at the basic maths of it all: you get MAX of 500 satoshis every 15 minutes (actually random amount between 400-500) and the minimum withdrawal amount is "0.002BTC" or 200000 satoshis. 200,000 / 500 = 400 claims to meet min withdrawal amount. 400 claims * 15 minutes = 6000 minutes = 100 hrs = 4.16 days! So, over 4 days... Assuming that you don't sleep and you click claim every 15 minutes exactly and you hit the max 500 sats every single time In reality it will take weeks to get close to the minimum withdrawal amount, by which time you've either given up... or you then find out that you cannot actually withdraw the funds. The added bonus with this particular site is that they claim you can "earn faster" by "investing"  To check this, I signed up with a "fake" BTC address... and surprise surprise, my "investment deposit address" is also: 1Cmwf5pG5VeMnNbRV3rp88Sc2aXo7ED53v  Which is exactly the same as yours... there is no way they can tell if I deposited money there, you did... or some other random person did. TL;DR: You've essentially lost 0.0006 BTC by "investing" in this (scam) site.  If you send your Bitcoin (from onfaucet.com) to another address, it will changed into "Spend"
No, it won't... because that address is not the OPs... it belongs to the scam faucet site. TLDR : There's nothing wrong, you can use your Bitcoin normally.
No, they can't... because they don't control the private keys for that address and it's no longer OPs Bitcoin |
|
|
|
Firstly... don't multipost... If you need to "add" new info and no-one has posted, you can simply use the "EDIT" button to edit your post to add to it I'm still a bit confused by what you were actually doing... Were you sending funds to this tockha marketplace? If so, what wallet did you send from? Were you sending funds from tockha to someplace else? Were you sending funds from your tockha wallet to another tockha wallet? That isn't a "transaction block"... you have linked to the transaction history for address: 17GNYZZ9y1Woyv5JdqLcAEJeYaQyRDTx2D 1GR1KivrjCJsdT1obBUpNyEwpy6neo8vLL is the address to my tockha onstie wallet by the way...... Ok, so the address you sent funds to is: 1GR1KivrjCJsdT1obBUpNyEwpy6neo8vLL ? As you can see from the link, that address has received 2 "deposits", totalling: 0.01181457 BTC... all of which was then sent to address: 1EryQJyJgUFJcXgk5gw7PZ9H34HiLi1R8r in this transaction1BVSb8mdWxqGXxRy5Tcx1YbwX9Zr9RSio is there pool address so can someone confirm please? thanks.
1BVSb8mdWxqGXxRy5Tcx1YbwX9Zr9RSio looks like a "change" address of some description. It seems to be included in a lot of transactions, receiving the leftover "change" when transactions are happening. |
|
|
|
I have a wallet.aes.json file backup from blockchain.info (from 2013), I know first password, but I forgot second, I know about which might be but I do not know the exact variation, 12 phrase word is lost too.
You will likely not be able to open that file in any other wallet application... There is no way to recover a "2nd password" from a blockchain.info wallet, except via brute force... And that will take a very long time unless you have a very good idea of what the password was. The best you could probably hope for is a script (perhaps modified btcrecover) that will allow you to test 2nd password variations? As far as I'm aware, it only supports trying to brute force the first password. |
|
|
|
|
Show Posts
