No worries mate, I actually opened the wallet file with Garlium, instead of another one I had downloaded from the official Garlicoin website. Works fine, despite the fact that...it has 5 coins only. lol.
Yeah... it's like opening my old Byteball/OByte wallet and seeing "thousands of coins" and checking the price and thinking that I've done OK... only to realise the price is actually for a "GByte"... and I'm looking at the Byte value!    I still appreciate your time and effort you put into helping me. I wish we could have actually recovered something of worth, then I would have definitely sent you a reward as an appreciation of your effort.
All good... always happy to help (or try to anyway  )... generally end up learning something new along the way!  |
|
|
|
Maybe try "Garlium": https://xske.github.io/garlium/It is supposedly an Electrum fork for Garlicoin Also, I must apologise... I forgot that Electrum stores the wallet history in the wallet file... so that would explain why it could see it all, but didn't actually sync properly or allow you to send. It's when you import private keys that it needs to scan from scratch. |
|
|
|
But this assume the blkxxxxx.dat file isn't corrupted, right?
Correct, if it detects a corrupted file on disk, it'll ignore the corrupted version and redownload the necessary blocks and verify them again. |
|
|
|
I can't use the Vpub keys because bitcoin-cli (v0.21.0.0) throws this message: key 'vpub5UXsYa6RJKsn5DYT52PanEWhidjBRpt11vx7Y3MP4ShSRnEH9TZrGN2Cg4KjK2GVJNg2ynpZzq8YC1Jr1m3cnTfV8wsNT7EwTaYMy4PCDAg' is not valid. I just did a quick test and it seems to work OK when using Legacy Electrum MultiSig wallets (see example below)... However, when attempting to use "Vpubs" from an Electrum SegWit multisig... I also get the "key 'Vpub5g.....FA5' is not valid (code -5)" error  Seems like Bitcoin Core is not recognising the "Vpub" as being a valid key for whatever reason?
A couple of points to note for anyone following along at home: 1. the "child path" you will need to use in your descriptor is: /0/* 2. If you don't want to generate 1000 addresses (the default 'range' setting), then include a "range" in the descriptor 3. You will need a "descriptor checksum" to use importmulti (use the getdescriptorinfo call to generate the checksum for your descriptor) So, I created 3 "standard" wallets in Electrum Testnet... and then created a 2-of-3 MultiSig... this MultiSig uses the three tpubs: tpubD6NzVbkrYhZ4XgEBrr2NwxfyEehaHfm83BqX79y1QMs5ewSkpyQgSFQ9vSfEqiDeHuNU55gABbDMDtfyfVBq6pBgeJmSUxisnqKG89Mgtu3
tpubD6NzVbkrYhZ4XkeJ7kHEo6Bu8fFRM7b5rsYCBBVFesJRNcxuMXhqDCPKiiWxke7mrRDrQAghGsn3MH3xQYFEPbAsutnyMVo835YeToYVB2R
tpubD6NzVbkrYhZ4WP2J1AQDCCzzAJFtbxwrwNAPdGrj7f8fpEKC1yQC3Dio9EvMGF6AGY6oN46Bbea6pgV1hXuTGegPcy5mMY2eUy8gwnesrsF
   This wallet generated the following addresses: 
So... our "descriptor" will be: "sh(sortedmulti(2,tpubD6NzVbkrYhZ4XgEBrr2NwxfyEehaHfm83BqX79y1QMs5ewSkpyQgSFQ9vSfEqiDeHuNU55gABbDMDtfyfVBq6pBgeJmSUxisnqKG89Mgtu3/0/*,tpubD6NzVbkrYhZ4XkeJ7kHEo6Bu8fFRM7b5rsYCBBVFesJRNcxuMXhqDCPKiiWxke7mrRDrQAghGsn3MH3xQYFEPbAsutnyMVo835YeToYVB2R/0/*,tpubD6NzVbkrYhZ4WP2J1AQDCCzzAJFtbxwrwNAPdGrj7f8fpEKC1yQC3Dio9EvMGF6AGY6oN46Bbea6pgV1hXuTGegPcy5mMY2eUy8gwnesrsF/0/*))"
NOTE the /0/* child paths Ok, so we have our descriptor, now we need the checksum: getdescriptorinfo DESCRIPTOR_STRING_GOES_HERE
getdescriptorinfo "sh(sortedmulti(2,tpubD6NzVbkrYhZ4XgEBrr2NwxfyEehaHfm83BqX79y1QMs5ewSkpyQgSFQ9vSfEqiDeHuNU55gABbDMDtfyfVBq6pBgeJmSUxisnqKG89Mgtu3/0/*,tpubD6NzVbkrYhZ4XkeJ7kHEo6Bu8fFRM7b5rsYCBBVFesJRNcxuMXhqDCPKiiWxke7mrRDrQAghGsn3MH3xQYFEPbAsutnyMVo835YeToYVB2R/0/*,tpubD6NzVbkrYhZ4WP2J1AQDCCzzAJFtbxwrwNAPdGrj7f8fpEKC1yQC3Dio9EvMGF6AGY6oN46Bbea6pgV1hXuTGegPcy5mMY2eUy8gwnesrsF/0/*))" This should generate something like: {
"descriptor": "sh(sortedmulti(2,tpubD6NzVbkrYhZ4XgEBrr2NwxfyEehaHfm83BqX79y1QMs5ewSkpyQgSFQ9vSfEqiDeHuNU55gABbDMDtfyfVBq6pBgeJmSUxisnqKG89Mgtu3/0/*,tpubD6NzVbkrYhZ4XkeJ7kHEo6Bu8fFRM7b5rsYCBBVFesJRNcxuMXhqDCPKiiWxke7mrRDrQAghGsn3MH3xQYFEPbAsutnyMVo835YeToYVB2R/0/*,tpubD6NzVbkrYhZ4WP2J1AQDCCzzAJFtbxwrwNAPdGrj7f8fpEKC1yQC3Dio9EvMGF6AGY6oN46Bbea6pgV1hXuTGegPcy5mMY2eUy8gwnesrsF/0/*))#7mwe6979",
"checksum": "7mwe6979",
"isrange": true,
"issolvable": true,
"hasprivatekeys": false
}
And we can see that it has handily calculated the checksum (7mwe6979)... and also appended it for us! So... our "descriptor#checksum" string is now: "sh(sortedmulti(2,tpubD6NzVbkrYhZ4XgEBrr2NwxfyEehaHfm83BqX79y1QMs5ewSkpyQgSFQ9vSfEqiDeHuNU55gABbDMDtfyfVBq6pBgeJmSUxisnqKG89Mgtu3/0/*,tpubD6NzVbkrYhZ4XkeJ7kHEo6Bu8fFRM7b5rsYCBBVFesJRNcxuMXhqDCPKiiWxke7mrRDrQAghGsn3MH3xQYFEPbAsutnyMVo835YeToYVB2R/0/*,tpubD6NzVbkrYhZ4WP2J1AQDCCzzAJFtbxwrwNAPdGrj7f8fpEKC1yQC3Dio9EvMGF6AGY6oN46Bbea6pgV1hXuTGegPcy5mMY2eUy8gwnesrsF/0/*))#7mwe6979"
And now we can just use importmulti: importmulti '[{"desc":"sh(sortedmulti(2,tpubD6NzVbkrYhZ4XgEBrr2NwxfyEehaHfm83BqX79y1QMs5ewSkpyQgSFQ9vSfEqiDeHuNU55gABbDMDtfyfVBq6pBgeJmSUxisnqKG89Mgtu3/0/*,tpubD6NzVbkrYhZ4XkeJ7kHEo6Bu8fFRM7b5rsYCBBVFesJRNcxuMXhqDCPKiiWxke7mrRDrQAghGsn3MH3xQYFEPbAsutnyMVo835YeToYVB2R/0/*,tpubD6NzVbkrYhZ4WP2J1AQDCCzzAJFtbxwrwNAPdGrj7f8fpEKC1yQC3Dio9EvMGF6AGY6oN46Bbea6pgV1hXuTGegPcy5mMY2eUy8gwnesrsF/0/*))#7mwe6979","range":10,"timestamp":"now"}]'
Important things to note for this example... we use sortedmulti() as the keys need to be order lexographically... I specified the "range" as 10 for brevity... if you leave the range out, Bitcoin Core will default to generating 1000 addresses!  and you'll understand why we don't want 1000 for our test in a bit "timestamp":"now" basically says, I've only just created these keys, so don't bother rescanning... again, this was to save time testing purposes... so the result won't actually show the transaction history for these addresses... (for the record, I actually did a rescanblockchain 1905760 to scan from block 1905760 and it found the appropriate transactions ) Anyway... this command gives:
[
{
"success": true,
"warnings": [
"Some private keys are missing, outputs will be considered watchonly. If this is intentional, specify the watchonly flag."
]
}
]
GREAT SUCCESS! and looking in "Receiving Addresses" in Bitcoin Core (Testnet):  We have the same addresses as generated by Electrum... (just displayed in a different order! Now do you understand why we set the range to 10 and not 1000??!? ) |
|
|
|
Yeah... if it shows a transaction history (not necessarily a positive balance ), then the likelihood of it being something else are about the same chances of randomly typing in a private key and it being to one of Satoshi's old addresses |
|
|
|
Alternatively, if you aren't in a hurry, wait until the mempool empties and then consolidate at 1 sat/vbyte.
Could be waiting quite a long time for that to happen again... The mempool hasn't been close to empty for quite a while now https://mempool.space/graphs#1mI've been wanting to consolidate some stuff... and it's just not feasible with the current network state  Even the traditionally "quiet" weekend periods have been busy. And you can't just fire off a 1 sat/vbyte transaction and hope for the best any more... with a flooded mempool, the current mempool min fee is like 2 sats/vbyte |
|
|
|
Can the password in the dat file become malformed or garbled ? The password is not "stored" in the .dat file... the data in the .dat file is encrypted using the password as a key. This error is indicating that the "old" passphrase entered in the "Enter Passphrase" textbox is incorrect This error is indicating that the two passphrases entered in the "new passphrase" and "repeat new passphrase" boxes are not the same. I suggest that you tick the "show passphrase" box and doublecheck that the passphrases that are being entered are correct... If it was incorrect would it assert that my change of the phrases do not match? its handing it off to the next step to change so it was accepted but then declines the change... its 2 messages and occurs when i delete a space from the recovery , which i am told is outside the scope of the other co and is a core matter.
It is indeed a 2-step process... Step 1. - Compare the text entered in the "new passphrase" and "repeat new passphrase" textboxes. - If "new passphrase" == "repeat new passphrase", then continue to Step 2. - Else show "The supplied passphrases do not match" error Step 2. - Attempt to decrypt wallet using text from "enter passphrase" textbox as the key - If decryption is successful, then encrypt wallet using new encryption password (using text from "new passphrase" as the key) - Else show "The password entered for wallet decryption was incorrect" error |
|
|
|
Make a copy of the wallet.dat... then open the copy using a text editor (for windows, I'd recommend you get Notepad++, the windows notepad is terrible)... then do a search for: name You should find several results, and immediately after "name" you should see what looks like a cryptocurrency address... what letter do the addresses start with? If it isn't a "1" [1], then you've got an altcoin wallet. In this example, you can see they start with a "D"... it's a Dogecoin wallet.dat:  [1] - theoretically could also be a "3" or "bc1" |
|
|
|
One more question please, could it also be something else? Like Bitcoin Cash? I mean, can those two get confused? If I open it with ElectrumG, will it be BTG 100%?
Definitely not Bitcoin Cash... BCH used either the identical addresses to Bitcoin (as it was, falsely, claiming to be Bitcoin ) or their "cashaddr" format... but it could be another altcoin that also used addresses that start with a "G" and has a fork of the electrum wallet. I'm not aware of any other altcoins with addresses that start with a "G"... but then, I haven't really looked... the main one I know is BTG. |
|
|
|
That took so long because the transaction was "non-standard" and likely required some "tweaking" of node/mining software to be able to include it... most miners would shy away from doing something like that... "if it ain't broke, don't fix it". I would guess because they were nervous about wasting a lot of time/resources and possibly generating an invalid block. But yes, unless you have an existing deal/contact with a mining pool, trying to sort that out before the original transaction gets confirmed would, I imagine, be somewhat difficult. Also, based on the OPs screenshot showing 75 sat/byte fee... and fees are down around the 20 sats/byte level again, I'd say it's all rather moot... I'm sure the original transaction has already confirmed. So, the OP is left with the single option of asking (very nicely!) whomever owns the address they sent coins to, to kindly send them back |
|
|
|
What was the answer to original riddle btw, if you or tweetious don't mind sharing?
PS aid also like to know the answer to the original riddle  Perhaps I can provide the answer to the riddle... with another riddle! A green egg? With a watery red "yolk"? sounds refreshing... Also, it's all in lowercase. |
|
|
|
It's a JSON format wallet... and it looks a lot like the Electrum wallet file format: {
"addr_history": {
"12B..........................HR": [],
"13Q..........................BX": [],
"13i..........................u9": [],
"16B..........................qn": [],
"19A..........................Gu": [],
"19V..........................yv": [],
"1A9..........................Ro": [],
"1Ak..........................Bb": [],
"1Bk..........................W3": [],
"1Br..........................RL": [],
"1Cm..........................eN": [],
"1Co..........................NF": [],
"1EV..........................4E": [],
"1F1..........................KX": [],
"1H3..........................NP": [],
"1HK..........................Sj": [],
"1Ha..........................oK": [],
"1LZ..........................ib": [],
"1M6..........................yH": [],
"1NF..........................Vh": [],
"1PQ..........................7k": [],
"1Pa..........................PN": [],
"1Pb..........................1Q": [],
"1Pj..........................wL": [],
"1Q4..........................qt": [],
"1QL..........................tN": []
},
"addresses": {
...
However, given that the addresses all start with a "G"... it's not a Bitcoin wallet... possibly Bitcoin Gold? You could try opening it with the BTG fork of Electrum called "ElectrumG" from here: https://bitcoingold.org/electrumg/ |
|
|
|
But not displaying the seed phrase by default, allowing the back up to be skipped and still have full use of the wallet, and not providing future reminders other than a small "!" in the settings menu is not enough in my opinion. If they aren't going to display the seed phrase by default when you create the wallet, then I would expect something like a notification screen every time you open the app or a banner at the top visible at all times saying that you have not backed up the wallet.
errr... that's exactly what it does... you even quoted that part I should point out that if you click "later" (or the 'x') to close the backup popup... then close and re-open the app, you get the "Don't risk your money" pop-up again.
If the user copies and pastes or uses some other method to avoid writing down the seed phrase, than that is entirely their fault and they cannot argue they were not given adequate notice or warning.
How is showing 12 words and getting the user to re-enter them "adequate notice or warning" compared with: "Take 2 minutes to backup your wallet, and never risk losing your money" IMO, the real issue, as someone mentioned earlier, is education... if someone doesn't understand that they need a backup of a wallet because iCloud backup isn't a magic bullet... they're probably not likely to realise how important the 12 word backup is anyway... and that's when people take screenshots, or email them to themselves, or scribble it on an easily lost post-it/notepaper so they can "just get past this stupid dialog and start using the app" etc... and then they just end up losing money further down the line. It's certainly a shitty situation... and I've done it myself... granted, only a tiny fraction of the amount lost here... so I was lucky and learned the lesson "cheaply". @dadbody00, best of luck with the arbitration... and I hope this experience hasn't totally put you off crypto. |
|
|
|
Looking at your logs, Armory seems to be running quite slow... 2 hours to process all the blocks and like 4 hours to create the Armory DBs... Not sure why it's "stuck", but until Armory is able to properly scan all the blocks and parse all the transaction history... it will likely show all your addresses as "unused"... because as far as it knows, they all are! Once it is able to parse the transaction history, your addresses will be marked as used etc. When you checked the initial addresses shown during export... did any of them show any transaction history (regardless of current balance)? If they didn't, then it's possible that the addresses you used previously were not simple P2PKH addresses I'd recommend exporting all your keys and then bulk importing them into Electrum... check to see if there is any transaction history showing (don't worry about the balance at this point). If you don't see any history, then you wallet was either not using P2PKH addresses, or you've restored an "unused" wallet |
|
|
|
Sounds like something may not be working properly. - What versions of Armory and Bitcoin Core are you using? - Is Bitcoin Core running in "pruned" mode? - Does the "online" Armory say "Connected" in green in the bottom right with the number of blocks? If so, what is the number of blocks it shows? Can you please post your Armory logs? Copy/paste the contents of your Armory log files to https://pastebin.com/ click "Create new paste" and then post the URL generated by pastebin here. |
|
|
|
|
It'll be because of the lack of replay protection... when you moved the BCH, it likely moved the BSV as well... if you look at the BCH address on a BSV blockexplorer you should be able to see an identical transaction to the BCH one.
So you swept the BCH into a Coinomi wallet? If so, you should be able to access the private key to get the BSV... but you'll need to make sure that you properly split the coins. You need to get some "split" BCH dust to add to a BCH transaction that sends all your BCH back to yourself... having the split BCH dust added in will make the transaction "invalid" on BSV chain... then you should be able to move the BSV.
|
|
|
|
It’s not easy to get into just 100 transactions that are accepted every hour because probably thousands of people are trying to speed up their transaction, and the opportunity to do so only takes a few seconds. What many don't pay attention to is that Via requires a certain minimum fee to accept the transaction - which is why many claim that the whole thing doesn't work. It should also be noted that ViaBTC are calculating the min fee as 10 sats/ byte... NOT as 10 sats/ vbyte... Which can be problematic for folks using SegWit addresses... as their wallet might say 10 sats/byte... but in reality they mean 10 sats/vbyte... which, if you're using SegWit, will result in a lower fee in sats/byte and putting you below the min fee rate for ViaBTC |
|
|
|
I have the public key which shows that the BTC is still there. It's a Legacy (P2PKH) wallet and according to Magnum the derivation path is: 44'/0'/0'/0/0
I've tried connecting my Ledger to Electrum but I'm not seeing the address there. Was wondering if anyone else has run into this issue or has any ideas on how I can access my BTC?
Likely just a derivation path issue... If you've connected the Ledger directly to Electrum and created a "standard" wallet with the "Use a Hardware Device" option and it found nothing... then you might have to try experimenting with various derivation paths to try and find it. You can either create wallets in Electrum using your 24 word seed ("standard wallet" -> "I already have a seed" and tick "BIP39 seed" under "Options")... or you can experiment using an offline version of https://iancoleman.io/bip39/Creating individual wallets in Electrum is relatively time consuming... but arguably more secure than using Ian Coleman's tool... however Ian Coleman's tool allows you to quickly and easily modify the derivation path and check lots of addresses at the same time. Whichever option you select, I'd suggest doing it on an offline computer... and after you've finished, consider your seed as being compromised... you should recover the funds to a new wallet... then reset your ledger device, create a new 24 word seed and then move the coins to an address on the newly configured Ledger. |
|
|
|
Is there a way to get this back?
No. Without RBF, there is almost no way to replace that transaction. The only way you could achieve this, would be to find a friendly miner with a LOT of hashrate... and ask them to mine a replacement transaction directly for you (and probably pay them a hefty fee to do so)... and then hope they find a block and include your new transaction in it before your original transaction confirms in a block mined by another miner. Your chances of successfully executing a "double-spend" these days is practically zero... any replacement transaction would be rejected by the majority of nodes on the network and fail to propagate properly, so no miners would see it. |
|
|
|
I spent a few hours with python and was progressing slowly. I was not able to install Twistted because even pip has apparently stopped supporting older versions of python.
Note that twisted was only needed for the fancy "WebUI" for PyWallet that never really took off... and which jackjack has removed in the recent updates... it isn't actually needed for the base pywallet.py commandline tool. You do still need the bsddb package though. |
|
|
|
|
Show Posts
