How do you decrypt the encrypted private key?
which shows encrypted_privatekey:
If the wallet file is encrypted, you need to use the --passphrase parameter and supply the "walletpassphrase" when you use the --dumpwallet command. In that case it will output the decrypted private key data in the output text and you should see fields labelled "sec" and "secret": python pywallet.py --dumpwallet --dumpwithbalance --passphrase=PUT_YOUR_WALLETPASSPHRASE_HERE --datadir=/path/to/wallet --wallet=wallet.dat > keys.txt
"sec" is the decrypted private key in "WIF" format "secret" is the decrypted private key in HEX {
"addr": "1EuK1VCzdyGzXgk1AnJswC1Y46dCyyqyXW",
"balance": "Never used",
"compressed": true,
"encrypted_privkey": "43e93c600c4e76eecbdc1311d09713234dc1c8c3e37067383f74e910afd6321f989c9a49dd73f018e76d2e0f1d759f1d",
"pubkey": "03feb65c4b3a2f163e991803e47b28231c2b62366814c08ed816b1aa150e856fc0",
"reserve": 1,
"sec": "WIF_PRIVATE_KEY_WOULD_BE_HERE",
"secret": "HEX_PRIVATE_KEY_WOULD_BE_HERE"
},
|
|
|
|
I also received emails from "Ledger". I didn't even buy anything and simply asked a few questions using one of my Tutamail accounts via TOR. Those don't come back to me but sure enough those phishing emails were sent to me there.
That's expected... given that the "marketing" DB was leaked as well as the "customer" DB. If they had your email at any stage, you were likely on the "mailing list"  So, in the absence of any evidence of a further data breach, it looks like the July data breach was much larger than they initially thought. It is more than a little concerning that they "cannot state the exact scope of the leak of this detailed data". They have no idea what has been breached.
This is probably the most disconcerting thing. They don't really appear to have any idea of what exactly was leaked. At least they finally seem to be starting to "get it": ...
We know we fucked up, we try to get it right for you.
Although, I doubt there is realistically much they can do to "get it right" for the affected users. The proverbial horse has bolted, so the data is out there... It's not like Ledger can "undo" this. |
|
|
|
I literally want to do whatever is easiest and fastest. If that means I leave Armory behind, then that means I leave Armory behind. I don't know. I'm just figuring this all out for my boss, and he's been waiting weeeeeks now to get access to these funds. :/
In which case, you might be better off exporting the private key that is holding your funds, and then importing that key into another wallet like Electrum that will allow you to sync/spend without downloading the entire blockchain. Electrum is an "SPV" (aka Simple Payment Verification) wallet, and it connects to servers which do the "heavy lifting"... it offers "speed and simplicity" in exchange for sacrificing "privacy". You can read my guide on how to extract your private keys from Armory here: https://bitcointalk.org/index.php?topic=4746784.msg43255691#msg43255691You can download Electrum here: https://electrum.org/#downloadNOTE: When you create the wallet in Electrum, you need to select the "Import Bitcoin addresses or private keys" option:  If you have any issues with the export/import, just let me know |
|
|
|
You can also have a read of the guide here: https://bitcoinelectrum.com/how-to-verify-your-electrum-download/It includes a link to proof of the key fingerprint ( as shown in a Youtube video of a slideshow presentation by ThomasV) So, unless we're all part of a giant conspiracy to defraud the world, you can be fairly assured that ThomasV's PGP publickey fingerprint is: 6694D8DE7BE8EE5631BED9502BD5824B7F9470E6
>This< is what I've done so far. What are the steps of what I should do nex? If you did all that, and got the "green message" in Kleopatra or the "Good Signature" message from GPG when verifying the Electrum download, and you can see the fingerprint shown is either: 6694D8DE7BE8EE5631BED9502BD5824B7F9470E6
or Then you're good to go... and can be assured that the digital signature on the Electrum binary/installer that you downloaded is "OK"  |
|
|
|
Yes I know it now, you can ceck my last comments. Here, my misunderstanding is because the service just mentioned G2FA only, so i think if it only works for google 2FA only.
Yeah, it's a common misconception that "Google Authenticator" is a "Google Only" service... you're not the first (and won't be the last) person to get confused by that. I certainly was when I first started using Google Authenticator several years ago. The sites that have implemented the 2FA service are partly to blame by calling it "Google 2FA" etc... And Google really should implement a "proper" (encrypted) backup solution for Google Authenticator. Relying on users to safely store the individual "secrets" themselves is messy and prone to error. Authy, Aegis and Authenticator (Plus) (and others) have all been able to come up with solutions, I'm not sure why Google can't?  |
|
|
|
As far as I can see, the company has not confirmed nor denied this... and I don't see any other users claiming that their affiliate info was leaked. Having said that, on the balance of probabilities, I'd say it was probably likely that it did happen, especially if all their systems were integrated Given that they have admitted the other data was leaked, I see no reason for Ledger to deny that the affiliate data was leaked if it did indeed happen. I would assume they are busy investigating this claim. Hopefully they can make a statement at some point in the (very) near future to clarify the status of this data, so users can be advised and take any necessary precautions. I feel for the folks currently getting spammed with scam text message "alerts"... must be alarming receiving a text with your full name claiming you've sent a transaction that you didn't, with a link to a website registered in your local region!  This entire episode has been a complete PR disaster for Ledger... their (normally) overworked and "slow" support is now pretty much completely swamped with requests to delete personal data (which don't seem to be being actioned)... and this is all down to what Ledger are claiming was a "misconfigured, Third Party API key". Going to take them years (if at all) to regain the trust of a lot of users. |
|
|
|
Okay, that box is definitely checked. If I uncheck it, it says it will need to re-download all 320 GB. So I'm going to set back another week?! SIGH
Yes, if the node gets pruned, then earlier blocks are deleted from disk... unfortunately, the only way to "unprune" is to redownload the entire blockchain again. Also, when I tried to do the config thing you said, it didn't know what program to pick and sent me to the app store. I tried to do it in notebook, but it just opens up blank. So I don't know what to do here either.
It's not unusual that the file is blank, by default it doesn't exist and/or is empty. Windows, by default, doesn't know what application to use to open a ".conf" file, hence why it asked which one you wanted to use. Notepad (or any text editor) is fine... do not use "wordpad" or word. They have the potential to break things. This seems to be generating more and more problems, rather than a solution T_T
There are other solutions for getting access to your coins, but it depends on whether or not you want to continue using Armory go forward. If you want to continue to use Armory, then you will absolutely have to redownload the full blockchain. There is no other option for that. If you don't want to continue to use Armory and just want to access your coins and migrate to another wallet, then there are ways to achieve that without downloading the blockchain. |
|
|
|
i have been abandoning my tx after waiting for couple of blocks to try again and again.. there were no confirmations. always shows the Status: 0/unconfirmed, not in memory pool
"Abandoning" a transaction does not cancel it... If it was broadcast, then it's like other nodes still have a record of it. Also, if a transaction was "abandoned", it will still show in your transaction list as it is stored locally within your wallet file. If you no longer want to see a record of this transaction, you should shut down Bitcoin Core, then start it with -zapwallettxes command line argument... This will remove all trace of the transaction from your wallet, and you'll be able to simply start again and create a new transaction. As mentioned, one potential issue is that the transaction was indeed broadcast at some point, and other nodes still have a record of it... this means it could still get confirmed at some point in the future (assuming none of the UTXOs are spent in the meantime). However, if you've searched for your transactionID on a blockexplorer (like blockstream.info, blockcypher.com, blockchain.com, blockchair.com, url=https://btc.com/]btc.com[/url] etc) and you've found nothing, then you should be OK. |
|
|
|
While your scenario is possible, it is not common. Most threat models involve creating a new backup of your seed if one gets destroyed.
Based on their last line: Jerry just use one of the methods suggested to you here, or in any of the threads you created last year and try to relax a bit.
I suspect that might have been a somewhat sarcastic reply from Pmalek, with a purposely ridiculous scenario... OP is a bit of an "over thinker" who seems to suffer from "analysis paralysis"... by which I mean they spend so much time dreaming up "...but what if?" scenarios that they never actually get around to taking concrete action to mitigate any of them |
|
|
|
AFAIR, I've read somewhere that it works in mainnet.
It's just that the difficulty is too high that it'll surely fail after the default 'maxtries' (1000000 iterations).
Yep, "no" realistic chance with Bitcoin, but with difficulty set to 1 on these custom coins, it will eventually find a block or 2  No mining scripts. Just generatetoaddress with 1 billion max tries. (I think)
Ah yes, that and a bit of patience finally resulted in a block being produced... however I'm in the same boat, the 2nd node seems like it has received the "header" at least... but doesn't seem to be retrieving or syncing the generated block...  EDIT: after mining a couple of subsequent blocks, it seems the 2nd node was able to sync up properly... and I'm now able to send transactions between the 2 etc. So maybe mine some more blocks and see if that kicks things into action for you   Note: I also dropped the maturity time to 5 blocks as mining on the VMs is very slow and I couldn't wait for 100 blocks! |
|
|
|
I think that guide may be a little out of date as the definition of payto() is incorrect looking at the current code: async def payto(self, destination, amount, fee=None, feerate=None, from_addr=None, from_coins=None, change_addr=None,
nocheck=False, unsigned=False, rbf=None, password=None, locktime=None, addtransaction=False, wallet: Abstract_Wallet = None):
The guide doesn't seem to be including the "feerate" option... Some notes from my brief experimentation using payto(): - fee is the TOTAL fee you want to pay in BTC (so, 0.00000500 would be 500 sats total fee) - feerate is the fee in sats/byte that you want to pay (so 2 would be 2 sats/byte) - You cannot specify the fee and feerate at the same time: >>> payto("AddressGoesHere",0.1,0.00000500,2)
Exception: Cannot specify both 'fee' and 'feerate' at the same time!
- If you don't explicitly set the rbf option, it will use whatever is defined in your global Electrum settings. - payto() will return a signed "rawtransaction" in hex, if you leave unsigned=False... if you set unsigned=True, you'll get a "PSBT" (Partially Signed Bitcoin Transaction) in what I believe is Base64 encoding. This can be viewed in "Tools -> Load Transaction -> From Text". - from_addr is a comma-separated list of addresses that you want to "spend from"... eg "2NGAbopZg9ZpKeAqFQWcsEKNrnqFsg4Qqyb,2Mwv1humoLS5YxARhU8wPb19xDWLxLSKYXi" - from_coin is a comma-separated list of coin "Output point" that you want to "spend from"... an "output point" is effectively the "transactionID:vout" of the UTXO as displayed in the "coins" tab. eg: "a504115e8740e6596ffedafc290c2a9e3ad64329c260764b1b231532be853ced:1" would be 198.58718211 tBTC from this transaction- Even if you specify multiple addresses or coins using from_addr and/or from_coin... it won't necessarily use ALL of them. Electrum will only use as few as required to meet the "total amount to send"+"total fee" requirements as per it's "normal" method of selecting UTXOs to spend. - You cannot include addrs/coins that have been "frozen". - As noted above, payto() will only create (and optionally sign) the transaction. You will need to use the "broadcast()" function to actually send the transaction to the network. |
|
|
|
|
You need to make sure that Bitcoin Core is fully synced, with the entire blockchain downloaded and stored on disk before you can get Armory working.
So, firstly, make sure pruning is switched OFF in the Bitcoin Core settings and then shut down and restart Bitcoin Core... It should automatically start redownloading/reindexing the entire blockchain. If it doesn't, then shutdown Bitcoin Core, delete everything in the Bitcoin "blocks" directory (all the blkxxxxx.dat and revxxxx.dat files etc) and then restart Bitcoin Core.
Once it has finished syncing everything again, you can start Armory. There is a chance that trying to run Armory against a pruned node will have done some strange things to the Armory databases etc, so if it is still having troubles once Bitcoin Core is fully synced, you'll probably need to use the "Help -> Rebuild and Rescan Databases" in Armory.
|
|
|
|
I need you to confirm a couple of things for me... #1. In Bitcoin-Qt, check "Settings -> Options -> Main" and make sure that "pruning" is switched off:  #2. You mentioned you had not changed any configuration files for Bitcoin Core, so it's quite possible that Armory is not able to connect to your Bitcoin Core node, as by default the RPC server is switched off. To fix this, you will need to create a bitcoin.conf file in the Bitcoin Core datadir... the simplest way is to simply click the "Open Configuration File" button on the "Settings -> Options -> Main" tab within Bitcoin-qt:  It should open a text editor, and you need to add the following line: After you have done that, save the file... then shutdown Bitcoin Core... then start it up again. Once that is done, you can start Armory and it should hopefully be able to connect to the Node. If you're still having issues, you'll need to repost your log file so we can see what Armory is doing now that you're made the changes. |
|
|
|
That does indeed look like you're running a pruned node... Check "Settings -> Options -> Main" in Bitcoin-Qt... make sure the box is UNTICKED:  NOTE: if your node was pruned, you'll need to redownload the full blockchain again to get Armory working properly. |
|
|
|
Out of interest, how did you mine that block? Did you have to setup a standalone "miner" of some description? Or did you just use the generatetoaddress option? |
|
|
|
Never received a "personal" notification from Ledger after the original hack... have not received any phishing emails or SMS messages recently (not even to my spam folder). What I did receive was an email from Ledger with the subject heading "Ledger Security Alert: be cautious with phishing attempts", which (somewhat ironically) went to my spam folder  So, kudos to them for at least trying, I guess As a side note, to whomever it was considering legal action, unless you can prove "willful negligence", you're probably unlikely to succeed. |
|
|
|
Yep, like a lot of premanufactured "physical" coins... you're relying on the manufacturer to not keep records on the private keys... with the Ballet Crypto one, they were claiming in the docs that the private key and encryption key are actually generated by 2 different parties and that nothing is stored anywhere etc refer: https://www.balletcrypto.com/en/2FKG/#three |
|
|
|
I don't remember exactly what kind of browser it was - either safari or chrome, but during the registration process, a window popped up that Google wanted to scan my key type. And I refused to give Google this right by clicking the corresponding button.
And to my surprise, after this, i could not complete the registration of my Trezor as a two-factor authentication key. Perhaps precisely because I refused to provide information about the parameters of my device.
Why would this surprise you? It's like acting surprised that you don't see any video if you deny access to your webcam  If you don't grant permission for the browser to be able to talk to the USB device, how is the USB device meant to communicate to the website? On another note, something I found somewhat interesting was that during my experimenting with the dropbox 2FA security keys, originally a Windows/Microsoft authentication dialog popped up when I was trying to add a security key... so, it was trying to use some sort of Windows/Microsoft account based authentication... I could use my Windows 10 "PIN" as my 2FA key??!? Once I removed that, and then cancelled that dialog on the next attempt to setup a 2fa security key, it then moved to using the hardware key. |
|
|
|
|
Show Posts
