If you have any concerns, the first thing you should do is raise those concerns with the campaign manager... via PM.

Publicly posting vague accusations like this just stirs up a hornets nest for no good reason.

honestly, it's impossible to say for certain...

you can get "some" idea by watching websites like https://mempool.space/ and https://jochen-hoenicke.de/queue/#BTC,24h,weight which give an overview of the current network conditions and transaction fees.

Unfortunately, the network is very busy right now... so you 70 sats/vbyte is  not even half what you need to have a chance of confirmation... 70 sats/vbyte is around 30 blocks from the tip. Assuming no new transactions are added that would take ~300 minutes or 6hrs... however new transactions will be added... so you're in for a long wait

You should have received a transaction ID of some description... or you should be able to see the transaction details. If you have the transaction ID you should be able to look it up on a blockexplorer like blockchair.com or blockchain.com or blockcypher.com etc... they will show the full details including the fee rate used.

Alternatively, you should know the bitcoin address that you sent the coins to on Binance... if you look up that address on one of those block explorers, you should be able to see the transaction as well.

Do you see any history at all... and your balance is zero... or do you see absolutely nothing at all? Is the "dot" in the bottom right corner of Electrum Green? Red? or some blue arrows?

Restoring a BIP39 seed an using the m/44'/0'/0' (legacy P2PKH) derivation path should generate the same wallet as used by BitPay and/or Bitcoin.com.


^-- This... Bitcoin.com has a really bad habit of making users think they're buying "BTC" Bitcoin... but they're actually buying "BCH" Bitcoin Cash

Is it a repeatable bug? Or does it only do it with particular address? Kinda seems like the sort of thing that should be highlighted to Ledger support and/or logged on their issue register.

Do you have a transaction ID we can look it? Without seeing the actual transaction, it's impossible to know exactly why it is taking so long... but the usual reason is that the fee rate used is too low.

https://mempool.space/ will give you a good idea of what is happening... currently a very LARGE amount of transactions are waiting... the absolute minimum fee to not get purged from the mempool of most nodes is currently 7.4 sats/vbyte...  However, to actually get included in a block, a transaction needs to be well over 100 sats/vbyte... if not 150-200+ sats/vbyte

What is the fee rate on your transaction?

Bitcoin Core is an "HD" Wallet (hierarchal determinisic) wallet... it doesn't have "a" Public address... it has many public addresses (theoretically an unlimited number).

Do you specifically need the "first" address? or will any address do?

If you have used the getnewaddress command ONCE, it should return the first address from the keypool, which should be the address at hdkeypath=m/0'/0'/0' NOTE: if you use it again, it'll return the m/0'/0'/1' address, then m/0'/0'/2' etc

If you didn't explicitly provide a "label" when using the getnewaddress... you can get it to display by using getaddressbylabel command and passing an empty string:

It should return something like:

Note... if you have generated multiple addresses, there is no guarantee that the getaddressbylabel command will return them "in order".



Did you search for the m/0'/0'/0' in the output text using dumpwallet... the address (and all 1000 keypool addresses) should be displayed in the dump file?

Yes, as per my PM, MultibitHD never used .key files. (The only wallet/key files in MBDH were mbhd.wallet.aes or mbhd-TIMESTAMP.wallet.aes files)

So, it's either a MultiBit Classic .key automatic backup (or export) file... or it is a .key file from some other wallet. I'm not aware of any other wallets that used files with a .key extension. However that doesn't mean they don't exist.

PyWallet should dump any valid wallet.dat... regardless of whether or not it was created by PyWallet, recovered by PyWallet, recovered by data recovery software or created by Bitcoin Core.

There isn't real "marker" that would indicate to the script that it was a "Recovered" wallet or not... As long as it is not corrupted and in a valid format, PyWallet should be able to read and dump it.

Note that it's nothing to do with Antivirus or anything like that... unfortunately, the Bitcoin Core devs ran into an issue where their code signing key was accidentally revoked... so the cert that the Windows installer is signed with is "Expired" and so Windows now blocks it by mistake

I am having the same issue with the 0.21 installer... the solution is:

1. Press Win+X
2. Select "WIndows Powershell (Admin)"


3. Navigate to the folder where the 0.21 installer .exe is located using the "cd" command. For instance, I downloaded it to C:\Downloads, so I use:


I can check the name of the file using the dir command and it displays a list of the files/folders


4. Run the 0.21 installer .exe by entering the name of the installer and pressing enter:


TIP: if you start typing the first few letters of the filename and press TAB, it will autocomplete the name

The installer should then start up:




Refer: https://www.reddit.com/r/Bitcoin/comments/m7rc5b/how_to_fix_bitcoin_cores_installation_error_this/gsy99q8/

Unfortunately... "Run As Administrator" doesn't work in this situation... but running from an elevated cmd/powershell window does??!?

Do you have an Electrum seed mnemonic (ie. one that was generated by Electrum)... or is it a BIP39 compatible seed mnemonic (generated somewhere else)?

If it is an Electrum Seed mnemonic, you will not be able to use Ian Coleman's tool... as Electrum Seed mnemonics are slightly different to BIP39 seed mnemonics... and Ian Coleman's tool only works with BIP39 seeds.

If you have an Electrum Seed and want to test it... try this: https://github.com/FarCanary/ElectrumSeedTester

Is it a fork of Ian Coleman's tool, that has been modified to work with Electrum seeds. It should generate the same addresses as Electrum does. Download it and run it offline... it is just a single .html file to download and open in your browser.

Ahhhhh ok... Electrum tends to show just the transaction fee when it detects a transaction that sends funds to purely to yourself... ie. you're sending to one of your own receive addresses.

Rather than show 1 send transaction and 1 receive transaction... Electrum rolls them into one transaction and shows the total "net" effect to the wallet balance... which will just be the cost of the transaction fee.

ie. if I have myWalletAddressA and myWalletAddressB... and I currently have 0.25 BTC in my wallet... and I send 0.1 BTC with a fee of 0.00001000 BTC from A to B... Electrum will show 1 transaction as being -0.00001000 BTC.

I've also noticed that some wallets do not include in the "Transaction fee" in the "amount spent"... they show how much you sent to the other address in the history, but the transaction fee isn't included. This can throw manual calculations out if you don't remember to include the fee.


For instance... looking at the spreadsheet:


- BRD says you sent: 0.08027553 to "1BHr2yT4yG8d..." and the fee was 0.0001
- Whereas Electrum says you spent a total of: 0.08037553

Electrum includes the fee in the amount being deducted from your balance... it's not the amount you actually sent to someone, as it is (amount sent + transaction fee). Whereas BRD is "splitting" the 2 items out into separate amounts.

This also explains the "differences" that you have highlighted in the transactions here:


Electrum is including the transaction fee in the amount spent... where BRD (slow and fast) have separated it into: amount sent to other person and the transaction fee. So if you add the transaction fee to the amount sent, you get the same value as Electrum.



For the transactions highlighted here... I think I know what the issue is:



It seems that BRD "Fast" is sometimes not detecting the "change" coming back to your wallet for some reason??!?


Electrum seems to have detected that in this transaction: 086a3c5c65715ef8c8d0e30a32d8e0c419b9b65978691a75ee2b2e282a5e7e07

You sent: 0.0001 to 175BpxeLwANJzakLdZaZW4Vs9K3V5sdeoF... and the rest of the 0.10111943 BTC INPUT was split between the 0.0001 transaction fee... and 0.10091943 BTC going back to your wallet as "change".

Whereas, BRD Fast seems to think that you spent the entire amount... ie. both the receive addresses are being treated by BRD fast as being "External"...
BRD Slow seems to have worked it out ok... and is showing 0.0001 being sent + 0.0001 fee... total spent = 0.0002... just like Electrum.


BRD Fast seems to have done the same thing in the next transaction where you spent the change from above: f79f75508afda9bbab420d039b63f7478232148679f2e3bbe7355d5b4e358cce

It thinks the whole lot has been spent... rather than just 0.0003 + 0.0001 transaction fee (and rest as "change")... BRD Fast thinks you "spent" the entire amount to external addresses + transaction fee.

Why BRD Fast is doing this I do not know... perhaps the change address that was used by MultitBit was out past the BRD "change address gap limit"? Or the "Fast Sync" isn't pregenerating enough addresses to detect "change" properly or something? I really don't know, you'd need to contact the BRD devs and ask them.



Anyway, given what I'm seeing from your spreadsheet (and my personal experience with Electrum) I would say that I am inclined to believe that the balance being displayed by Electrum is likely to be more reliable than BRD Fast... BRD Slow would also seem to be "OK".

Yeah... I would agree.

If you're concerned that the RNG in the Trezor is malicious, broken or "poor"... you could just as easily create your own BIP39 seed using dice or coinflips offline... and import that into the Trezor.

You can then easily use offline tools like iancoleman's BIP39 mnemonic code converter to validate that the Trezor is generating the "correct" keys/addresses from your BIP39 seed.

Awesome... that's excellent news that the wallet files is not password protected... seems like when you exported the keys, you set a password on the export file and it was encrypted.

Unfortunately, this means you'll need to wait until MultiBit finishes syncing before you can export the private keys again It's a bit of a nuisance and likely to take an hour or more, but it will eventually sync... (I just synced up a new MultiBit wallet and it took about an hour). Note, if you use "View -> Messages" in MultiBit you can see how many more blocks to go until it is synced.

Also, if required, you can close MultiBit and then open it later and it will continue syncing from where it left off. So you don't need to worry about trying to sync it all in one go etc.


There are other ways to get access to the keys, but it will involve installing Python and mucking about with commandline scripts etc to dump the keys from the unencrypted .wallet file. So, unless you're comfortable with Python scripts etc, I would recommend just waiting for Multibit to finish syncing... then export the private keys from within MultiBit (without encrypting the export file).

Sorry for not replying sooner... I keep forgetting to check this old Multibit board from time to time... it seems with the increase in BTC value there are more and more old multibit users coming out of the wood work

Anyway... have you tried using the openssl method to decrypt the .key file?

This command (on Linux, but you can also install openssl for Windows) will prompt you for the password and then decrypt the .key file (simply change the multibit.key part to match your .key file) and create the .txt file that contains the decrypted text:

This is my "key_test.key" file:


This is what happens when I run the openssl command in linux:



This is the contents of newtest.txt:


If you're getting garbage output, it sounds like the .key file might be corrupt

If your wallet.key file looks like that, with the +'s and /'s etc and starts with the text "U2F"... then it is an encrypted .key file.

Encrypted .key files are either generated by the user when they explicitly export their private keys from Multibit using the "Tools -> Export Private keys" option and set a password on the export file in the last section of the export window:



or

they are created automatically by Multitbit when you set/change the wallet password (it creates an automatic .key backup encrypted with the wallet password).


My advice would be to install MultiBit and try and open the .wallet file... hopefully there is no password set on the .wallet file and you'll be able to create a new "key export" but using the "Do not password protect export file" option... you'll likely have to wait for MultiBit to finish syncing, which could take quite a while (upwards of an hour)... but once you do that, you should end up with a "plaintext" .key file that you can open in a text editor and it will look something like this:

If you're desperate to have exactly one and only one address in Electrum... I would suggest creating a new "standard" wallet with the 12 word seed backup... then export the private key for one of the addresses created at start up... and use that to create an imported wallet.

After creating the "Standard" wallet and writing down the 12 word seed, you just click the "addresses" tab ("View -> Show Addresses" if you can't see the tab), then right click on any of the addresses shown as "receiving" and select "private key".

Then create a new wallet:
- "File -> New/Restore"
- "Import Bitcoin Addresses or Private Keys"
- Enter the private key you copied above

You will now have an "[imported]" wallet that only contains 1 private key... but can be "restored" at any time by using the 12 word seed backup. You can even delete the "Standard" wallet file so you don't accidentally open it in the future and get given a "new" address.

For the record, I don't recommend doing any of this... but if you have a real requirement for a single key wallet, it'll still give you the simplicity of a 12 word seed backup.


If you just need to be able to "re-use" addresses... then just use a "standard" wallet in Electrum, give people one address and go for it... Electrum doesn't care if someone sends coins to the same address multiple times... the addresses don't "expire".

The whole "payment request/invoice expiry" thing is confusing and unintuitive... just ignore it.

That's not how the encryption with Electrum wallets work... "Secrets" like mnemonics are never stored unencrypted in the wallet file if there is a wallet password set. Basically, there are 3 levels of "encryption" for Electrum wallet files:

1. No Password - The wallet file is stored as plain JSON text... everything (including private keys, seeds/mnemonics etc) is stored in plaintext

2. Wallet Password only (encrypt wallet box is NOT checked) - The wallet file is stored as plain JSON text, "Secrets" including private keys, seeds/mnemonics and xprvs are stored encrypted, everything else is plaintext

3. Full file encryption (wallet password set, encrypt wallet box IS checked) - The entire wallet file is encrypted using the wallet password. Nothing is in plaintext.

You could not have had the "same" wallet in Bitcoin Core and MultiBit... they are two different programs, with completely different wallet file formats. You cannot use a Bitcoin Core wallet.dat in MultiBit... and you cannot use a ".wallet" file from MultiBit in Bitcoin Core.

You might have been able to export/import the keys between the different wallet applications, but you could not have simply opened the wallet file. Likewise, you can't simply open these files in "these new programs"... all the wallet applications have their own wallet formats and they're generally not compatible with one another.

It's also entirely possible that you had 2 completely different sets of private keys/addresses in the two programs... one set in Bitcoin Core and one set in MultiBit.


If you have a multibit.key file, that is generally a private key "export" file... If it was not password protected, then you should be able to open it in a text editor (I'd recommend Notepad++ https://notepad-plus-plus.org/) and view the private keys... It should look something like this:


However, if it is just "gibberish" that starts with "U2F" and looks something like this:
Then it is encrypted and you did set a password when the export file was created...


In any case, you should be able to install Multibit Classic 0.5.19 and simply open the .wallet file... Even if it has a password set, it won't ask for the password until you attempt to either send coins or export the private keys. You should still be able to let the MultiBit sync (although it might take several minutes and possibly as long as an hour or more) and you should be able to view the addresses contained in the .wallet file (even if it has a password).

---

As per this thread on reddit: https://www.reddit.com/r/Bitcoin/comments/m7rc5b/how_to_fix_bitcoin_cores_installation_error_this/

It isn't antivirus related... it's a Windows code signing issue. Sadly, the Windows signing key for Bitcoin Core expired and the dev's were having issues getting a new one... because of this you get the stupid Windows 10 error saying that the application has been blocked. I ran into this issue a few days ago when install Bitcoin Core on a new laptop.

The solution was to use Win+X (or right click the start button) and then launch "Windows Powershell (Admin)"... you then have to navigate to and run the windows installer .exe from the admin powershell window...

For some reason... that doesn't work... but opening an admin powershell window and running from that does... Windows is "Awesome"

It shouldn't take a year... but one problem you might run into is that I suspect that the blockchain.com wallet system automatically rebroadcasts transactions and/or their system holds the transactions for a much longer period that other nodes do.

This could potentially mean your transactions end up in "limbo" for an extended period of time, if they keep being rebroadcast

As ranochigo says, mempoolminfee has increased lately... currently on https://mempool.space/ it is showing as 3.7 sats/byte... so theoretically most nodes with a "default" config should have purged your transactions... but these 2 transactions are still showing up on a number of blockexplorers (blockcypher, blockchain, btc.com, blockchair etc)