I mean is there any chance our wallet/seeds become obsolete?
The short answer is "No". All the information/processes required to get from seed -> private keys is public, common knowledge. It would take something like a complete failure of the internet... at which point Bitcoin would effectively be worthless anyway  |
|
|
|
Armoury V 0.93.3
This is your problem. The older versions of Armory will not work with the newer versions of Bitcoin Core (anything after around Bitcoin v0.17 from memory)... You should try using the latest Armory from here: https://btcarmory.com/0.96.5-release/Also note that Armory will likely not show you any of your history etc until Bitcoin Core is fully synced. |
|
|
|
I've tried to do this but all the private keys say they are unused so any idea where i can find the used keys?
If your Armory is "offline" and not synced/connected with Bitcoin Core etc... your private keys will indeed say "unused" as Armory will be unable to see the history etc. That is "normal". Just export all your private keys as indicated above and then import them. |
|
|
|
Something odd going on with your Bitcoin Core... It got as far as getting the new block at 524491, and then just stopped getting new blocks... 2021-01-09T14:55:25Z UpdateTip: new best=0000000000000000000b6ce14cc39740a42d817ba68382075927555cd707f3e1 height=524491 version=0x20000000 log2_work=88.888701 tx=318642673 date='2018-05-26T14:39:09Z' progress=0.532869 cache=410.4MiB(2884728txo)
2021-01-09T14:55:25Z Imported mempool transactions from disk: 0 succeeded, 0 failed, 0 expired, 0 already there
2021-01-09T15:32:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 2205 seconds ago)
...
2021-01-12T08:53:05Z Potential stale tip detected, will try using extra outbound peer (last tip update: 237460 seconds ago)
Are you actually connected? What is the networkactive value and how many connections do you see if you do: bitcoin-cli getnetworkinfo Or look at the "Window -> Information" screen in Bitcoin Core GUI?  |
|
|
|
I am able to retrieve another wallet (always with the same seed), this time with bc1 addresses, I open it and I see some transactions, so this wallet was used too. Unfortunately though the address I am looking for is not there. So, you created a "standard" wallet in Electrum, using the seed your friend provided, selected "BIP39" and then selected the "Native SegWit (p2wpkh)" option... and doing this, you see transaction history, but not the address you're looking for?  I've just been trying with the Coinbase App to create addresses/wallets from different derivation paths, and I just don't see a way to do it... Regardless of the "Active Wallet" setting in "Settings -> Advanced"... it only seems to use the standard m/84'/0'/0' and m/44'/0'/0' addresses for BTC... the "Active wallet" setting only seems to affect ETH as far as I can tell. Although I don't think Coinbase provides a way to get addresses beyond the gap limit, you could try increasing the number of addresses generated by using the method that was posted earlier: There's also a chance that the address is at higher index than Electrum's default of 20, in that case, try to create more addresses by typing this in the console ( View->Show Console): [wallet.create_new_address(False) for i in range(200)] Then restart Electrum. Change " False" to " True" if you want to generate change addresses. He certainly screwed it up by using a legacy wallet and giving out a segwit address.
I don't think so... the Coinbase app lets you swap between Segwit and Legacy in the "same" wallet. You simply tap the "SegWit"/"Legacy" tabs above the QR code shown on the "Receive" screen. Did your friend ever use the Coinbase website? I'm wondering if they had used the "walletlink" feature or something... and the "mystery" address was one that was actually from the Coinbase website and not one generated by the app? |
|
|
|
When armory is closed there is no such process as ArmoryDB or alike opened. I understand what you think might be the problem here, but this would mean that Armory works smoothly after restarting the PC but that isn't the case.
Then I'm not sure why (according to your armorylog.txt debug log) that sometimes Armory is not spawning ArmoryDB... The only reason I can think why that happens is because it detects that ArmoryDB is already running. I assume you clicked the "more details" button in Task Manager and that you've checked all the background tasks:  Still, as you say, a restart should fix that problem... so it's not likely that a zombie process is the issue here. For my limited understanding, there must be a problem with Bitcoin Core and this is the reason why I can't get Armory online. While watching the processes carefully I recognized that BTC Core is not opened every time Armory is running. Keep in mind that BTC Core is not installed in the default path and I'm not sure if I have given Armory the correct guide to finding it.My "Bitcoin Install Dir" f.e. is "E:\Bitcoin\daemon" and the "Bitcoin Home dir" "E:\Bitcoin".
I think your "pathing" is fine... you can see in the debug output that it finds your bitcoind.exe ok: 2021-01-13 19:39:56 (INFO) -- ArmoryQt.py:1891 - Setting satoshi datadir = E:\Bitcoin
2021-01-13 19:39:56 (INFO) -- SDM.pyc:171 - Found bitcoind in the following places:
2021-01-13 19:39:56 (INFO) -- SDM.pyc:173 - E:\Bitcoin\daemon\bitcoind.exe
And ArmoryDB is finding your blocks OK: -INFO -0 10:32:05.000: (e:\users\goat\code\armory3\cppforswig\blockutils.cpp:915) blkfile dir: E:\Bitcoin\blocks
This output is a little worrisome tho: -INFO -0 13:37:27.188: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:134) scanning new blocks from #577594 to #577593 It seems you're missing ~90000 blocks??!? The Bitcoin blockchain is currently at block #666366... so either your node is not fully synced, or it's actually using the "btc" folder instead of "bitcoin" and Armory is looking in the wrong place, or there is some corrupt data stopping Armory from scanning the blocks properly. Regarding the size of the blockchain there are 2 folder installed by default: - "Bitcoin" which includes folders like "blocks","chainstate","daemon", "database", "doc" and various files including bitcoin-qt.The other folder is called "btc" including "blocks","chainstate","Wallets" only but apparently the blockchain is safed into both folders.
It's possible that your Bitcoin Core GUI setup has been configured to store the blocks in "btc\blocks"? whereas, when Armory is spawning "bitcoind.exe" it is explicitly using the "Bitcoin\blocks" folder... If you run the Bitcoin Core GUI (aka BitcoinQt) and look in the "Window -> Information" screen... what are the values for "datadir" and "blocksdir"? Either that, or it's an old datadir from a previous install? What is the highest number blkXXXXX.dat file in the " btc\blocks" directory? What is the highest number blkXXXXX.dat file in the " Bitcoin\blocks" directory? This is what I've been able to extract from the Dblog : https://pastebin.com/tbb8vbLF .I've got no idea why it is 1,2 GB but only shows data of the last run. You mean the dbLog file is 1.2 gigs??!?  Something not right there... I'd try shutting Armory down and deleting both armorylog.txt and dbLog.txt... and then restart Armory. It'll help get rid of any old debug that isn't relevant anymore. |
|
|
|
Those characters are unicode, which is why they don't show up in preview. The same is true of any unicode, such as custom emojis like this one - 😀
But why would people with bad intention do it? Wouldn't it makes the email more likely filtered by spam filter feature? Possibly the opposite depending on how advanced the spam filter is. By making it unicode, it's possible that a lot of the more basic "keyword" type spam filters will be unable to actually scan the message. It is a strange tactic tho... because it seems like their instructions to copy/paste and remove the ^^'s might fail if you try and copy/paste the message into apps that don't support unicode characters etc. At least it's useful for Ledger customer who're not affected by previous data leaks and future Ledger customer, assuming they actually and successfully do it.
And also something they should have been doing from the very start... or at least encrypting stored data  They should know that... I mean, they work in the " cryptosphere" FFS! |
|
|
|
@HCPI just check your post and I enter my phrase here now its showing my account identifier but still password is not right now so can you give any information about this how can I recover my funds as first time I have this phrase working ?
If you can't find your old wallet.aes.json file as suggested by nc50lc... then I would recommend that you contact blockchain.com support and ask for their help/advice. They may be able to provide your wallet.aes.json file given that you have the 18 word recovery phrase. Tell them what you information you have (but do not email them your 18 words!), and what you have already tried to recover your wallet and see what they say. |
|
|
|
I can Cancel this transaction from Electrum wallet? my Electrum ver is 4.0.9, nofound menu CPFP item.
If it can cancel how to do and how much fee will cost?
If, when you did the RBF/"bump fee", you selected "Finalise", then you will not be able to select the "Cancel Transaction" menu option... "Cancel Transaction" is just an RBF that redirects the transaction back to your own wallet. So, it's not really "cancelling" anything, you're just creating a new version of the transaction that spends everything back to your wallet... and because it is RBF, it means it will use a higher fee! If your transaction is eligible to be cancelled, you can simply "right click" on the unconfirmed TX in your "history" and select "Cancel TX" CPFP (Child Pays For Parent) is not relevant to this situation. That is something the "receiver" can do to try and speed up confirmation of the parent transaction. |
|
|
|
Is it the total Fee or the x/Byte Fee?
Miners generally prioritise transactions based on x/byte fee... not the total fee. It's because the size in a block is limited, so if you have a transaction with a large data size (like yours) that only pays a relatively "low" x/Byte fee... it takes up a lot of space in the block without much reward. Your 14447 byte transaction might pay 0.00145480 BTC in total fee... but it is taking up ~1% of a blocks total size. A "standard" transaction of 1 input/2 outputs is closer to ~220 bytes... so you're taking up the space of ~65 "standard" transactions! the Total Fee is not low, I think
No, it's not a low total amount... but because of the large data size, it's a low x/byte amount by the way how to reduce weight?
Regularly consolidate your UTXOs during times when the mempool is empty and fees are low. It'll mean you only need to use 1 or 2 UTXOs instead of 98!!?! The UTXOs you have aren't really small, the vast majority are 0.01 BTC or higher...but you're trying to send so many of them at once, when fee rates are high. Read this: https://bitcointalk.org/index.php?topic=2848987.0Then keep an eye on the network, when you see the mempool is empty and fees are around 1 or 2 sats/byte... send all your UTXOs to yourself in a single transaction... it'll consolidate them all together in one single UTXO and you'll pay a "minimal" fee. If you had 1 input for your current transaction, it would be around ~200 bytes... even at 100 sats/byte fee... you'd still only be paying around ~0.00020000 sats... and if you'd consolidated it all at 1 sat/byte... you'd only have paid around 15000 sats... so in total maybe 0.00035000 sats... less than 1/4 of your current total fee! and your transaction would have confirmed days ago! what's the right fee rate ?
That depends on what is happening with the network, and how fast you need it confirmed. If you need fast confirmation... check the bottom chart here: https://jochen-hoenicke.de/queue/#0,24hand check the stats here: https://mempool.space/See what fee rate is currently at the "1meg from tip" rate. Then go near or above that. If you don't care and can wait a while, then it doesn't really matter, set it to 1 sat/bye with RBF enabled and wait... if you can't wait more, you can always bump the fee if the transaction is not got confirmed a long time, how long will the bitcoin back to my wallet ?
Generally it'll take around 14 days for your transaction to drop out of the mempool of most nodes that are running at "default" settings. Some might be sooner, some might be later. And it also depends if your what rebroadcasts transactions or not... or if someone else rebroadcasts it, then it might never drop out of the mempool until it is confirmed. I checked the Current best transaction fees from btc.com ,just now is 13sat
As I type this... it looks like you're getting closer, as it is the start of the weekend and transactions are slowing down... the good fee is down around the 12-15 sats/byte area. You might get lucky and get in a block some time in the next 6-12 hours if it keeps trending down... noting that there around 10 blocks worth of transactions at the 10 sats/byte level. |
|
|
|
what 's wrong with the transaction?
the TxID is d6103699c9066e34f5ccc88bdecf20d9567aea16a51804456a05b5d2120b92a1
Your transaction is HUGE!!?! 14447 bytes... 98 legacy inputs... fee rate is only 10 sats/byte. Given that the network is very busy, free rates have been over 100 sats/byte. Check here: https://jochen-hoenicke.de/queue/#0,24hYour transaction may not get confirmed for quite a while |
|
|
|
For instance, I had never expected that the address format of BTC would change some day from P2PKH to bech32. And such things make me nervous when I'm not a coder.
As Rath mentioned... the format didn't change... new formats were added... all existing formats are still valid and can still be used. 1-type "legacy" addresses 3-type "Pay to Script Hash" addresses (aka "P2SH"), used for MultiSig and "Nested SegWit" amongst other things bc1-type "bech32" addresses (aka "P2WPKH), aka "Native SegWit" Or can I still today send BTC to an old address format P2PKH with the current BTC software from a bech32 address? You can send from any valid bitcoin address, to any other valid bitcoin address... the type does not matter. The only time this was an issue was because of badly coded (or old) wallet software or exchanges that did not recognise newer address types as being "valid"... This was a problem when SegWit was first released with some services/wallets marking bech32 addresses as "invalid". It is not so much a problem these days... as the more popular/common wallets and services have been updated etc. |
|
|
|
The Seed option is greyed out as I most likely imported private key.
On the title bar of your Electrum app, does it say "[imported]":  or does it say "[imported, watching-only]"? :  Also, what version of Electrum are you using? Is it 4.0.9? |
|
|
|
And what exactly does it mean when they say they will remove 24 words with some 'technical solution'?
They're not removing the 24 words... they're removing the 24 words as the "the single pillar of the security of our hardware wallets". Essentially, it sounds like they're trying to (or have already) come up with some fancy way of protecting your wallet (and/or backups/seeds) that doesn't just rely on a user writing down 24 words etc. It's difficult to say what they're thinking... possibly something similar to the "blind oracle" thing that Blockstream are using for their "Jade" wallet that requires some form of external confirmation? Also, quite what they mean by "and will open the door to funds insurance for individual customers" is anyone's guess. Sounds like a way to generate ongoing revenue by "selling" insurance to users Based on the quality of Ledger Live... I'm not going to hold my breath that their "technical solution" is actually a solution to any problem that I currently have... or that it even works. |
|
|
|
I also searched the Task Manager while having Armory open and there is only 1 process (ArmoryDB)running .None other looked relevant, in terms of being a Zomby DB.
What do you see in Task Manager when Armory is not open? Is there still an ArmoryDB process? The whole problem with the zombie process, is that it is "stuck" and will then prevent a "new" ArmoryDB from starting... Basically, Armory sees that there is already an ArmoryDB process running (but doesn't know that it is "stuck") and won't try and restart ArmoryDB Then, when you shut down Armory, it'll send a message to ArmoryDB to shutdown, but because ArmoryDB is "stuck", it won't shutdown and will just hang around forever... then when you restart Armory, the same thing happens, it sees the "stuck" one so doesn't bother trying to start a new ArmoryDB etc etc etc... |
|
|
|
I have about 10 transactions from about 8 years ago. About 150 dollars, just trying to get it out of the wallet. It takes about 6 hours to scan the database, 3 hours or so to rebuild. Just waiting now.
Ok... if you're just wanted to get your funds out, and don't wish to continue to use Armory in the future... you might be better off just exporting your private keys from the wallet and then importing those keys into another wallet like Electrum. I have a guide on how to export the keys here: https://bitcointalk.org/index.php?topic=4746784.msg43255691#msg43255691When importing into Electrum... use the "import Bitcoin addresses or private keys" options:  And ONLY copy the WIF key part... don't copy the "PrivBase58:" part... so when you paste into Electrum, it should look like this:  NOTE: You can import multiple private keys at the same time... one per line |
|
|
|
Thank you, really helpful. Using Electrum now with imported keys  I would highly recommend that if you are going to continue to use Electrum that you create a "standard" Electrum wallet that is created using as 12 word backup phrase (File -> New\Restore -> Standard wallet -> Create seed) and then send all your funds from the "imported keys wallet" to the new standard wallet. That way, if anything happens in the future, you'll be able to recover using the 12 word backup phrase. The 12 word backup phrase is essentially like Armory's "Root Key" paper backup... using the "imported keys", you will need to maintain either copies of the private keys themselves, or make copies of the Electrum wallet file. |
|
|
|
Thanks for posting... it's nice to see a "Happy Ending" post occasionally, rather than posters who just disappear into the sunset after they get it all working  For others reading this, MAKE THE GODDAMN PAPER BACKUP folks; it works.
This... very much this! |
|
|
|
How can I do that with CMD and Editor? Is this the right way to get the correct bitcoin address?
I don't think you can... because the steps outlined in that post are for going from public key to address... not from the private key... Also, it should be noted that (for the public key): - http:// blockexplorer.com/q/hashtoaddress no longer works... but you can use http:// blockchain.info/q/hashtoaddress - you only want the last 65 bytes from the output of the base64 -d command: wget -O - -q http://blockchain.info/q/hashtoaddress/$(grep -v 'PUBLIC KEY' <<<"
-----BEGIN PUBLIC KEY-----
MIH1MIGuBgcqhkjOPQIBMIGiAgEBMCwGByqGSM49AQECIQD/////////////////
///////////////////+///8LzAGBAEABAEHBEEEeb5mfvncu6xVoGKVzocLBwKb
/NstzijZWfKBWxb4F5hIOtp3JqPEZV2k+/wOEQio/Re0SKaFVBmcR9CP+xDUuAIh
AP////////////////////66rtzmr0igO7/SXozQNkFBAgEBA0IABJJ6TBhmiWm4
Y1ACBVJVn0oyG9Ay5IzEZq8cPyrs1PERl963YQh5UrGOT0NodynfHswkz8bUpaJW
FsowR/l9wXc=
-----END PUBLIC KEY-----" |
base64 -d |
tail -c 65 |
openssl dgst -sha256 |
cut -d\ -f2 |
xxd -r -p |
openssl dgst -rmd160 |
cut -d\ -f2)
This will return the example BTC address: 1Hy9dexzNzjvQYkYy6zKRVZMU8k2j5vuPt So given a bitcoin address such as :
btc=1Hy9dexzNzjvQYkYy6zKRVZMU8k2j5vuPt
These commands only work on Linux... So you'll either need a Linux box, a Linux virtual machine, or you can even use "Windows Subsystem for Linux"...
As for your situation of having a private key .pem file... Theoretically, you should probably be able to decode the private key from the .pem file output in a similar fashion... but you'd need to know exactly which parts of the Base64 encoded text were actually the hex private key (like how you only want the last 65 bytes of the "base64 -d" command above to get the public key from the .pem file.) Looking at this post on StackExchange: https://bitcoin.stackexchange.com/questions/66594/signing-transaction-with-ssl-private-key-to-pemWe can see that if you can find the byte sequence: "30740201010420" in the decoded base64 output... then the next 32 bytes (64 chars) should be the HEX private key... from that stack exchange post, we can see the example hex private key they started with was: 3cd0560f5b27591916c643a0b7aa69d03839380a738d2e912990dcc573715d2c
And the privkey.pem is: -----BEGIN EC PRIVATE KEY-----
MHQCAQEEIDzQVg9bJ1kZFsZDoLeqadA4OTgKc40ukSmQ3MVzcV0soAcGBSuBBAAK
oUQDQgAEvzUNKCE3UVimCLUePomOUH/kfy0ujHdN5Kmn7ez3TtokJDy5ksVnOgf6
WzpmzY46zvKAnQ44Cgx5Kdqx5dVDiw==
-----END EC PRIVATE KEY-----
If we use Python... we can decode that and view the bytes in "hex": hardcorepawn@HardCorePC:~/$ python
Python 2.7.17 (default, Jul 20 2020, 15:37:01)
[GCC 7.5.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import base64
>>> import binascii
>>> base64_message = "MHQCAQEEIDzQVg9bJ1kZFsZDoLeqadA4OTgKc40ukSmQ3MVzcV0soAcGBSuBBAAKoUQDQgAEvzUNKCE3UVimCLUePomOUH/kfy0ujHdN5Kmn7ez3TtokJDy5ksVnOgf6WzpmzY46zvKAnQ44Cgx5Kdqx5dVDiw=="
>>> message_bytes = base64.b64decode(base64_message)
>>> binascii.hexlify(message_bytes)
'307402010104203cd0560f5b27591916c643a0b7aa69d03839380a738d2e912990dcc573715d2ca00706052b8104000aa14403420004bf350d2821375158a608b51e3e898e507fe47f2d2e8c774de4a9a7edecf74eda24243cb992c5673a07fa5b3a66cd8e3acef2809d0e380a0c7929dab1e5d5438b'
From this we can see the decoded Base64 is: 307402010104203cd0560f5b27591916c643a0b7aa69d03839380a738d2e912990dcc573715d2ca00706052b8104000aa14403420004bf350d2821375158a608b51e3e898e507fe47f2d2e8c774de4a9a7edecf74eda24243cb992c5673a07fa5b3a66cd8e3acef2809d0e380a0c7929dab1e5d5438b
We can see the sequence "30740201010420" right at the start (highlighted "Red")... so the next 32 bytes (64 chars) (highlighted "orange") should be the hex private key: 307402010104203cd0560f5b27591916c643a0b7aa69d03839380a738d2e912990dcc573715d2ca00706052b8104000aa14403420004bf350d2821375158a608b51e3e898e507fe47f2d2e8c774de 4a9a7edecf74eda24243cb992c5673a07fa5b3a66cd8e3acef2809d0e380a0c7929dab1e5d5438b Giving us a hex private key of: 3cd0560f5b27591916c643a0b7aa69d03839380a738d2e912990dcc573715d2c
Which matches the HEX private key the example started with! So, try base64 decoding your .pem file contents... and see if you can find the sequence "30740201010420"... if you can, the next 32 bytes (64 chars) should be the private key. Let me know if you need any help. |
|
|
|
|
Show Posts
