Well... colour me confused then... I honestly have no idea why your private key is decrypting as 94 chars which is effectively 47 bytes... that just makes no sense??!?

Do you have a .key file at all? maybe try just running the decrypt_multibit_classic_keys.py script on the .key file...

Are you not able to open your wallet with MultiBit Classic and export the keys from there?

Sent you a PM with my Skype... but I guess you dropped offline before I sent it.

Anyway, 94 characters?? that's not a good result. That sounds like something is going a bit wonky somewhere...

Does the script output say the following right at the beginning?:


The script should have generated a file called "parsed_wallet.txt". Can you open that up and see what it contains?

you should see things like:

key {
  type: ENCRYPTED_SCRYPT_AES
  public_key: "\0030g\351\227 ~-\370b\261 6\031\347\004U\321\331cFV\222HRD\255\240\255H\317\254\252"
  creation_timestamp: 1494035052000
  encrypted_data {
    initialisation_vector: "\201e\2700m}\217x+I}\235\237\356\201n"
    encrypted_private_key: "\2564\274\217\263Q\177\345\270\216\275]N\326\305\360\226\246\207B\033\225e\311j\200\353\014\016\205\355jn\206Q\366\023\306\303\306\017\267\2670\021\3501_"
  }
}

NOTE: DO NOT POST ANY OF THE CONTENT OF YOUR "parsed_wallet.txt" FILE HERE!!!

The pubkey isn't encrypted within the file... but the private key is... can you confirm that your "parsed_wallet.txt" has key{}'s that have type: ENCRYPTED_SCRYPT_AES and also contains the encrypted_data{} section that has the initialisation_vector and encrypted_private_key?

Also, near the end of the file should be some sections that look like:

encryption_type: ENCRYPTED_SCRYPT_AES
encryption_parameters {
  salt: "\355\220\310M\277UJ/"
}
version: 2
extension {
  id: "org.multibit.walletProtect.2"
  data: "\000"
  mandatory: true
}

Again, DON'T post any of that here... I just want to confirm that you have ENCRYPTED_SCRYPT_AES with the "salt"... and that there is the org.multibit.walletProtect.2 in there as well?

I'm trying to rule out a different wallet format to what I have seen and that the script is expecting...

You're welcome...

NOTE: it has been around 6 hours since ViaBTC mined a block, so hopefully it won't be too much longer until they get another one...

EDIT: And now ViaBTC have mined it in block#469188... and you're already got 4 confirmations.

Actually... to avoid doubt of OP editing messages, you just need another (independent) user to "Quote" the full message immediately after it is posted... that way, there is a record of it that the OP cannot possibly edit, and if they do edit their original message, you can easily see the differences.

This is how the address staking thread works. User's quote the previous user so it can't be edited later.

If the transaction has already been sent with low fee... and you're trying to speed it up you have two other options, which are really just variations on "high fee"...

1. "Replace By Fee" or "RBF". If your wallet supports it, and you had it enabled, RBF allows you to effectively delete the transaction and send it again with a higher fee.

This only really works if the "change" from the transaction was sufficient to enable you to increase the miners fee, as you can't add new inputs, you can only use exactly the same inputs that were used in the first transaction. It is also only something that the "Sender" can do.

2. "Child Pays For Parent" or "CPFP". Basically, you use the "unspent output" or UTXO from the unconfirmed transaction, and use it in a new transaction with a MASSIVE fee that makes the average fee for BOTH transactions nice and big. Miner sees big fee, and confirms parent transaction so they can also confirm new transaction and claim fee.

This can work if you are the "Sender" if you control one of the addresses that an output got sent to (ie. a "change" address). This can also work if you are the "Receiver" and the sender messed up and used a low fee.

If you're still using blockchain.info wallet, then I'm pretty sure your problem is going to be low fee related.

AFAIK, binfo still haven't fixed their broken fee calculation system. Recommended fees (https://bitcoinfees.21.co/ and https://btc.com/stats/unconfirmed-tx) are still well over 300 sats/byte and I suspect binfo are still using 120 sats/byte...

Go use the ViaBTC TX Accelerator... and for the love of bitcoin, STOP USING BLOCKCHAIN.INFO!!

Steps to Transaction happiness:

Step 1. Go and download latest version of Electrum and make sure that "Use Dynamic Fees" is on and ReplaceByFee is "Always" (Tools -> Preferences -> Fees)
Step 2. Send transactions with proper fees
Step 3. Be happy your transactions don't get "stuck" for days

Pretty sure it isn't. When I use "encrypt wallet file", I get a wallet file that looks a bit like this:


If I untick that, then sure... JSON with encrypted keystore entries:



This was switched on by default since 2.8 apparently: http://docs.electrum.org/en/latest/faq.html#how-is-the-wallet-encrypted

You can tell which setup you have based on whether or not Electrum asks for a password when you first start it up (or open a wallet). If it asks for the passphrase, the wallet file is encrypted, so it needs the passphrase to open and read it and load your addresses/transactions. If it just opens up and displays all your transactions etc and only needs a password to send or sign messages etc, then the wallet file itself is unencrypted (but obviously your keystore is still encrypted)

Assuming you're on linux given the "/media/genericusername/SB@/home/genericusername/blocks/" path...

It's possible that your 800GB of free space is on a different partition...

In a terminal window, if you type: df -h

What is the output that you get?

Firstly, sorry that my script is not working for you. I tested it with a number of files and never got this error

This part of the error message suggests that the checksum of the generated WIF format private key, doesn't match the original checksum from the private key stored in the file:

Is the .key file encrypted as well? Can you open it in a text editor like Notepad and read anything? If it is all encrypted, can you run the decrypt_multibit_classic_keys.py script on the .key file with that password? Does that generate any errors?

Unfortunately, I cannot replicate this error... so it is a little hard for me to test and figure it out...

I have made a quick modification here: https://pastebin.com/Z2zfbwiv

It should hopefully print out the "hex" version of the private key after the Pubkey: line... and before the error occurs. it'll look something like (NOTE: hex should be exactly 64 chars long):

Privkey: 41e09d37764805f234d2d17995d1c8f6338243f413a374c8d8a8b1e002b5b67e

Create an offline copy of the bitaddress.org website (links are at the bottom of the bitaddress.org page)... and then copy/paste that hex value into "Private Key" section of the "Wallet Details" page and click the "View Details" button. See if it gives you the matching addresses or an error message.

If you don't actually get that big long hex string (exactly 64 chars) from the script... then that is the reason for the error... as the private key is not being retrieved correctly... which is a bit of a problem

Of course you can. It will store all addresses. It just generates new ones to help aid "privacy", but old addresses will continue to work just fine.

Biggest clues for me as I was reading down the thread were:


and then this one:



But I got to the party late and the issue was already solved

Sometimes you need to copy/paste into a pure text editor like Notepad so that you can see ALL the characters clearly. Notepad doesn't interpret them as anything else... whereas apps like Webbrowsers try to be "smart" sometimes and convert special character encodings for you...

Have you tried just opening the .dat file in a text editor to see if you can see anything "readable"... ie. plaintext.... something like this (you may need to scroll down past a list of bitcoin addresses):


if however you see something like this with a jumble of random letters and numbers, it is likely to be encrypted:


if you see something REALLY random and weird like strange characters like this, it might be a Litecoin Core wallet:

So confirming you have a couple of wallet.dat files? If so, then Bitcoin Core is an option... although you'll need to wait for it to sync, then swap the new wallet.dat file with your old wallet.dat.

There is also pywallet: https://bitcointalk.org/index.php?topic=34028.0

That might help you extract the private keys etc

About all you can do on your end is to shut down your wallet application and don't open it until you can no longer see the transaction on any block explorers.

However, this does not guarantee that the transaction will not get rebroadcast. Anyone can rebroadcast it at any time if they have the raw transaction. So, if the receiver of the transaction wants to make sure they get their coins, they can just keep rebroadcasting the transaction to make sure it doesn't drop out of the mempool.

Some nodes will rebroadcast transactions and some webwallets (like blockchain.info) rebroadcast transactions sent from them and there really isn't anything you can do to stop it.

Also, as soon as you re-open your wallet, it may rebroadcast... What wallet software are you using?

I believe the OP is asking how to increase fees when you're withdrawing from Exchanges etc ("BTC Trading Market")... specifically, ones that use "fixed" fees that are way to low for today's fee levels...

Generally... No. This is why leaving large amounts of coins in Exchanges/"Trade Market homepage"/Gambling sites is a "Bad Idea"™. You don't have access to the private keys, which means you effectively don't have control of the coins. You are basically trusting the site to not steal your coins. Look at the "Scam Accusation" forum to see how this scenario can end up

You won't be able to do this... as you don't have the private key to be able to sign the "double spend" transaction. Only the holder of the private key can sign transactions.

ViaBTC TX Accelerator can be very effective. Although it is not without limitations.

1. The fee must be at least 10 sats/byte. This usually isn't a problem for most transactions from exchanges etc... they generally send at least 50-100 sats/byte transactions.
2. They only accept 100 transactions per hour. These slots reset at the start of an hour. As the network has become very busy lately, and fees skyrocketed to 300+ sats/byte... this service got VERY popular. So much so, that the 100 slots per hour will generally fill up in the first minute of an hour. So it can take a while to get your tx submitted successfully.
3. There can be no "unconfirmed parents" for your transaction. This could be problematic with exchanges. Some have a habit of creating chains of unconfirmed transactions by spending unconfirmed change amounts.
4. You have to wait for ViaBTC to mine a block (and sometimes 2 depending on how busy they are). They're a Top 10 pool by hash rate... and seem to average something like 5-10 blocks per day. So you could be waiting 10 minutes... you could be waiting 10+ hours.


Another option you have is to do a "Child Pays For Parent" or CPFP transaction. Basically, you create a transaction using the unconfirmed output (unconfirmed UTXO) that you got sent from the site... You send this to yourself and use a HUGE fee... so big that it makes the average fee across the two transactions big enough that the miners want to claim both (ie average of 400+ sats/byte). This works because the miners need to confirm the parent transaction to be able to confirm your new transaction and claim the huge fee ).

The formula to calculate the fee to use for Transaction 2 is: ((Trans1 Size in bytes + Trans2 Size in bytes) * BIG fee rate in sats/byte) - Trans1 fee.

Ie.
TransactionA (from Site to You): 0.2 BTC... Transaction size = 226 bytes, fee of only 100 sats/byte = 22600 sats
TransactionB (from you to you): 0.2 BTC... Transaction size = 226 bytes
BIG fee is currently 400 sats/byte

So your calculation is: ((226 bytes + 266 bytes) * 400 sats/byte) - 22600 sats = 198200 sats

Your 2nd transaction then "looks" like it has a fee of 198200 / 226 = 877 sats/byte... but when combined with the first transaction it averages to 400 sats/byte.

The big 'gotcha' with this method, is that you MUST ensure that you are using the exact same (unconfirmed) UTXO that was created by the first transaction. This can be a problem if your wallet doesn't have "coin control" features that allow you to specify which inputs to use. If you get this wrong, and don't use the correct UTXO, you are just creating a 2nd transaction with a massive fee that is unconnected to the first and so the first transaction still probably won't get confirmed.

Firstly, try here: http://www.mocacinno.com/page/feeestimate

You can also get recommendations here: https://bitcoinfees.21.co/
and here: https://btc.com/stats/unconfirmed-tx

350 * 258 = 90,300 sats... or 0.00090300 btc

It all comes down to how long you want to wait for confirmation... At this moment in time, a fee of 400+ is a good chance for confirmation within an hour. A fee of 300+ sats/byte is good chance to get confirmed within a day (if not a few hours) whereas a fee of 102 sats/byte "may" get confirmed in a week or 2... or never.

You can always roll the dice and try and send with low fee and use the ViaBTC TX accelerator, but that is very busy these days.

As discussed with mocacinno via PM, I'm just posting here to state that I will be assisting him with this...

Hopefully, I can fill the gaps when he isn't online

TIP address: 1PMu6KrSGBmJ5EQ7siUXcshFAE55bFDrxk

This is wrong... the minimum fee is 10k sats PER KILOBYTE aka 10 sats/byte...

If you have a 17.7kb transaction and try and put a fee of 10K sats... your effective fee is 0.565 sats/byte... (10,000 / 17,700) Even if the network accepts your transaction, ViaBTC will not accelerate it, as it doesn't meet the minimum fee requirement.

To meet the minimum requirement, you'd need to include a fee of at least 177,000 sats... safer to go more in case your transaction is actually slightly larger than 17.7 kb and the numbers are being rounded

Assuming it isn't encrypted... which Electrum seems to default to these days when creating a wallet...

How exactly are you trying to import it?

The key file is simply a text file, you should be able to open it in a text editor like notepad and read the key. So your decode.key file should look something like like this:

if however you see something like:
Then the file is still encrypted.