sometimes things confused me like in here block time is ~10min right?
It's " average" block time and not an absolute value. That is based from the adjusted " difficulty" from the previous 2016 blocks ( about 2 weeks). The harder the difficulty, the harder it is to produce a hash lower than the " target". So since mining is basically generation of pseudo-random hash, we will never know if miners get lucky enough to generate a valid hash in the next second or unlucky to generate it after an hour. is it possible to have a transaction confirmed in few sec
by putting the higher fee on the time
by saying final i meant with no possibility to rteplace it with another one
Is there any particular reason for this? Because in normal circumstances, this shouldn't be an issue if you're the sole owner of the private key. Solved puzzle 66 or something? |
|
|
|
Any ideas?
There's not much info available but an indication of permission issue. Try running Armory as Administrator. By Either: - A. Right-click 'ArmoryQt.exe' and select "Run as administrator". (has to be done every time you open Armory)
or
- B. Right-click 'ArmoryQt.exe' and select "Properties", Under 'Compatibility', find "Run this program as administrator" and save. (permanent)
If it didn't work, try to install Armory somewhere else and not in Program Files. |
|
|
|
what about the other input (the confirmed UTXO used on the transaction, address ends in avh5). Can it be spent on a different transaction?
I saw that you've already did that which replaced the mentioned " screwed_TXID" in the OP, it's now confirmed. Not only that, this screwed_TXID has now some descendants because the change address of screw_TXID was used for another transaction (for some reason, the wallet of this entity thought it was a good idea instead of using available UTXO's to forge that transaction)
Since you did replaced it, those descendant transactions are now dropped from mempools. If you do not want the client to spend unconfirmed UTXO in your next transactions ( in Electrum as hinted in the OP), Tick the setting " Spend only confirmed coins" in the settings icon [  ] of 'New Transaction' window ( After clicking "Pay..."). |
|
|
|
-snip-
This happened before, and I used Electrum with my ledger to replace the fee
I tried to do this again, but it only loads the BTC transaction to the point when I did this last year
Aside from the script ( address) type above, If you've used an address from your " second account" in Ledger Live, you must edit Electrum's derivation path's 'account_index' from /0' to /1'. If you've used the third account, use /2', and so on. For example, if Native Segwit, second account: From m/84'/0'/0' to m/84'/0'/1'. |
|
|
|
-snip-
I am feeling good that I ask this in this thread before making any transaction. -snip-I've tested that they are using standard derivation paths and key derivation methods. If ever, it'll be more of an inconvenience than lost bitcoins. In case someone did that: Backup the seed phrase, import it to Sparrow by selecting Script Type: " TapRoot (P2TR)", set the default derivation path. And the same address will be restored in Sparrow, first in the address list. |
|
|
|
-snip-
So I did the reindex-chainstate=1 and removed the pound sign. Now Bitcoin Core wallet is running again, but now it's starting back from 2009, which was the reason I was afraid I'd have to do. I made a note about reindex-chainstate in my reply just below his. To rephrase that, if your blockchain is pruned, it'll have to redownload the blockchain to rebuild the chainstate. If it is pruned, I'm afraid that you don't have any choice but to restart IBD due to having a corrupted chainstate and pruned blockchain. Also, read the other important notes since you've used the config file method. Or is your blockchain not pruned? Because it will seemingly do IBD but it's just processing the existing blocks on your disk. Are you using Bitcoin-qt ( with GUI)? Does it show " Processing Blocks on disk", if so, that's just " reindexing"... not downloading. |
|
|
|
Might be a question you should ask ViaBTC -snip-
-snip-
Not seem obvious but OP is talking about normal transactions with OP_RETURN output with very-high fee broadcasted after block height 839999 in order to be included to the next " halving" block height 840000. Perhaps it's @100bitcoin's phrase: " Have you been able to send a message in this block?" that's confusing everyone. |
|
|
|
If I then send some coins to that address, does that automatically create the address in the real bitcoin world?
Depends on how you define " real bitcoin world". The Bitcoin Network? If so, there's no addresses in every node's mempools or the Bitcoin blockchain, just scripts. That address is just a representation of a locking script, If you send your address to someone, you're basically instructing the sender's wallet to create new outputs with the script derived from that address. If you see sender and recipient address in your wallet, it's just conveniently displayed as addresses by your wallet. So, there's no " created" address in the " real bitcoin world", addresses stays in the wallet as a human-friendly way to show senders and recipients. I'd redirect you to learn " UTXO" instead: |
|
|
|
-snip-
I think it's gonna be useless because yesterday when I'm trying I used (getbalance) on btc core and it shows 0.000 I dont remember how many zeros but there wasn't another numbers It's 0.00000000 BTC, so is you Bitcoin Core fully synced? Because if not, getbalance will just show you false-negative results regardless if the wallet has bitcoins. If yes, then why did you have to go through the unsafe dumpwallet and manual/scripted balance checking if you're going to sync Bitcoin Core anyways? What's done is done and if it's the actual balance Bitcoin Core shows, then the wallet is really empty since it already checked all script types derived from the wallet's private keys. Also: on the first I tried to search for (name ) on wallet.dat file by notepad (normal one) and hxd (hex editor) and there wasn't The former isn't reliable specially if the backup is an unused copy of the wallet.dat file. Without any history of usage, you wont find any address using that method. P2SH-Segwitt address type (3...) seems to be default for at least Bitcoin Core 26.0.
It's been " bech32" since v20.0: github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.20.0.md#wallet |
|
|
|
-snip-
And I'm already have all the addresses of the wallet but they're alot and it will take very long time to check them individually
Are those addresses the result of the suggested dumpwallet command? If so, you may have to specify which address type to dump because the command defaults to " bech32" if addresstype isn't explicitly set. Since you do not know the actual address( es), you may have to create a separate dump with legacy and p2sh-SegWit addresses. To do that, you either: - A. Close Bitcoin Core, set addresstype=legacy to your bitcoin.conf file, Open Bitcoin Core then use dumpwallet command;
Close Bitcoin Core, set addresstype=p2sh-segwit, Open Bitcoin Core then use dumpwallet command with different dump file name.
(Your third option would be addresstype=bech32 if your current dump file has legacy addresses; and the other type, bech32m isn't an option in 2020)
Those two dump files will contain same private keys and amount of 'key & address lines' as your first dump file but will have the specified address type.
Then use the script that you've mentioned above (after you share it so we can check if it's legit) to see if those addresses have bitcoins.
- B. This wont require another two dump files;
When you import to Electrum, specify the script types as noted in 'import private key' window's "info" tooltip button.
Each WIF private key should be imported with different script types to restore all three address types.
e.g. (imports legacy, p2sh-SegWit and Native SegWit addresses):WIF_Private_Key01
p2wpkh-p2sh:WIF_Private_Key01
p2wpkh:WIF_Private_Key01
WIF_Private_Key02
p2wpkh-p2sh:WIF_Private_Key02
p2wpkh:WIF_Private_Key02
WIF_Private_Key03
p2wpkh-p2sh:WIF_Private_Key03
p2wpkh:WIF_Private_Key03
... But, don't import too many in one wallet or Electrum may not sync.
|
|
|
|
-snip-
But my question is, can I receive Bitcoin with that taproot address or not? It's specifically noted that the address is to receive Ordinals and BRC-20 tokens. Has anyone used it?
Aside from that note, there's a pop-up that explicitly tells the user not to send Bitcoins to it. This message:  And if that's not convincing enough, for actual testing, it can be done by switching to testnet in 'Settings Icon' ( lower-right)->" Change Network". I've sent tBTC to my test xverse wallet's TapRoot address and it didn't arrive. |
|
|
|
-snip- I will also send the json as copied from network/response in the browser web dev so maybe you can see something in the payload that I can't. I really appreciate this. And no worries all wallets have been defunded other than the one I'm trying to recover.
I didn't expected that it would be this fast but your " full json script" with the exact token file contents ( copy-paste) perfectly worked in my setup. Command: btcrecover.py --wallet hurley27-wallet.aes.full.json --token hurley27-token.txt --dsw : Starting btcrecover 1.12.0-Cryptoguide on Python 3.10.2 64-bit, 21-bit unicodes, 64-bit ints
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* Note for Blockchain.com Wallets... *
* *
* Writing all `possibly matched` and fully matched Passwords & *
* Decrypted blocks to possible_passwords.log
* This can be disabled with the --disablesavepossiblematches argument *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Wallet Type: btcrpass.WalletBlockchain
Wallet difficulty: 5,000 PBKDF2-SHA1 iterations
2024-04-21 20:39:43 : Using 8 worker threads
19758 of 139599 [#####---------------------------------] 0:00:27, ETA: 0:02:46
If this tool helped you to recover funds, please consider donating 1% of what you recovered, in your crypto of choice to:
-snip-
Password found: 'xxxxxxx7.' So, it may be your OS, python version, dependencies or character formatting; testing it in another machine is worth the try. But overall, BTCRecover should work in normal circumstances.
The other formats didn't worked and my best guess is your wallet file may be specifically formatted that way as I saw some " extra" stuffs that aren't in BTCRecover's or my test wallets. So using the payload alone might have caused the errors, I'm not a Blockchain( .info/.com) developer so I can't tell. |
|
|
|
-snip-
Do you mind if I send you the code or the json files as I have formatted them? Along with the password so you can check? I can also send the raw wallet data/wallet id/pass so you can see the login works but for some reason btcrecover doesn't recognise the password when run on the json file. I just am totally confused by this. I don't mind testing the " wallet.aes.json" + " token file" as long as the bitcoins are already swept to another wallet of yours; Otherwise, please don't send me those if it's still funded. As for the full login credentials, it would be more beneficial if you coordinate with BTCRecover's developer instead, for him to find a fix to that possible bug. |
|
|
|
Many ppl recommend creating a new (SegWit-Bech32) walltet and transfering all funds to the new wallet. But don't I need to pay fees for such transaction (given I want to slice my funds into smaller chunks )?
Is there a better way ?
Slicing it in smaller " chunks" or UTXO/coins would only lead with higher fee in your next transactions if each of those coins aren't enough to pay your usual transactions. You should go for a small number of big value chunks to make sure that your transactions will only use one or two input( s) at a time. As for ( kinda) free transfer to a new SegWit wallet, do this in your next payment. Use 'Send' tab setting's ( upper-right icon) " Pay to many" option and fill the Pay to field in the format below. example: recipient_address,0.0001
your_OWN_SegWit_Address,! That way, all the remaining non-frozen coins ( amount = !) from the wallet will be sent to your SegWit address instead of that legacy wallet's change address. So you only paid for the payment's transaction fee and the transfer to your new wallet is basically free. Make sure to double-triple-check the address to make sure that it will be sent to your new SegWit Electrum wallet. |
|
|
|
-snip-
I just do not understand how it runs without finding the password. Is it an issue of it not finding certain characters in the password? My password contains a single fullstop but is otherwise alphanumeric. Does that have any impact? I'm legitimately baffled here. I just used --listpass and it shows the correct password. I just don't know why it doesn't acknowledge it as being the right password for the wallet.
You can try your current setup with BRCRecover's test wallets from: ...\btcrecover\test\test-walletsParticularly, " blockchain-v4.0-wallet.aes.json" and/or other blockchain web wallet test wallets, the common password used in test wallets is: btcr-test-password You may also check other passwords in " test_passwords.py" script. If it somehow failed to find v4.0 Blockchain wallet's password despite being in the list ( --listpass), then there's something wrong with your setup. If it can find the password, then it may be your wallet or something else that you've missed. I have tried the v0.0 format but btcrecover finds errors. -snip-
Is the '.json' file only contains the payload ( including the "=" at the end of the string) without anything else? Because it should be accepted even if the wallet isn't actually v0.0, but it'll show false-negative result despite having a good token file. |
|
|
|
Im curios how safe is currently the 12 mnemonic seed phase for example of of electrum 12 words against bruteforce?
is it possible to get a hit if someone would use all words and has some capabilities have any success or is it safe as of now?
From this context you want to check if Electrum's default wordlist^12 is safe? Electrum by default uses the same word list as BIP39 ( but not limited to that) so you have 2048 words and will be bruteforcing 12 words. 2048^12 is 5,444,517,870,735,015,415,413,993,718,908,291,383,296 So based from the number, I don't think that there's a good chance to hit another person' seed phrase by bruteforcing the words alone. I mean, it's not 1% low or even 0.000001% chance, it's 0.0000000000000000000000000000000000000002% chance. Don't even think that starting from the entropy is slightly faster either since Electrum's seed doesn't have a checksum unlike BIP39, all those 12 words are part of the entropy so you'll start with 132bits of entropy which is the same as the above. In terms of actual resistance against bruteforce, read this document: electrum.readthedocs.io/en/latest/seedphrase.html#security-implications |
|
|
|
-snip-
Ok what I will do is post the wallet file here as copied from browser. This makes up my wallet.aes.json file. When I contacted 3rditeration on GitHub he tells me the format is wrong but doesn't tell me what is the right format. "payload": "{\"payload\":\"RcAFIu...4ngdwYpw4=\",\"pbkdf2_iterations\":5000,\"version\":4}"Hmm, if I use this format with my own and test payloads, 3rdIteration's BTCRecover detects that it's not in the correct format. It's reading the backslash in the quotation \" as part of the base64 string payload. Are you sure that it's pointing to correct wallet.aes.json file during those attempts? Because you should see an error with that wallet file. You can retry it with absolute path to the wallet.aes.json file to be sure. Then, try to create two separate wallet.aes.json files with your payload, then bruteforce those instead: - One containing just the base64 string payload (from RcAF... to ...Ypw4=) and take note of it as as "v0.0" format.
- And another in this format: {"pbkdf2_iterations":5000,"version":4,"payload":"RcAF......Ypw4="}.
(Do not put quotation marks outside: "{contents}" should be {contents})
|
|
|
|
Probably to start from the scratch is the best advice you have found so far as reindex-chainstate takes the painful time and doesn't guarantee that it will cope with the problem.
But the debug.log entry shows otherwise. It specifically written that a file in his chainstate folder is corrupted that should be fixed by rebuilding the chainstate as mentioned by achow101. Your previous case may not be related to chainstate corruption that's why the command didn't worked. And the time it takes to --reindex-chainstate may not be fast but not as slow as --reindex or IBD. |
|
|
|
|
Show Posts
