Of breadwallet or the python scripts?

BreadWallet is a mobile app for Android or iOS... They don't have a desktop version... and no desktop wallets that I know of work with MultiBit HD recovery seeds

Python is available for Windows, Linux and Mac OSX: https://www.python.org/downloads/release/python-2713/

I have only tested my python scripts on Windows, because that is all I have and I can't be arsed setting up a VM with Linux and/or Mac OSX... so it may or may not work on Linux or Mac OSX.

ps. If someone wants to donate some bitcoins, I'll go buy a macbook

It is a function of: "average" bitcoin fees currently being used/required to get included within a certain number of blocks... and your transaction data size.... hence people talk of "satoshi's per byte" or "btc per KB" when talking about fee "size".

If your wallet is full of tiny "dust sized" inputs (say, less than 0.001 btc each) from faucet collection or setting minimum payouts from mining pools etc... when you try and send an amount of BTC that is (0.01 or higher), you're going to end up with transactions that require 10+ inputs which results in a data size of over 1500 bytes (in some cases, I've seen users generating 2000-4000 byte transaction sizes).

Now, the current recommended fees are well in excess of 200 sats/byte. So, if you have a 1500 byte transaction (instead of an average 226 byte transaction), you end up having to have a fee of 1500 * 200 = 300,000 sats = 0.003 to send say 0.01 btc!!

now, imagine if you're sending 0.04375 (~$80 today)... and all your inputs are 0.001... you're going to need 44 inputs to make that amount... which would be a transaction that was like 6500 bytes... that would require 6500 * 200 = 1,300,000 sats = 0.013 btc which is around $20...

Moral of the story: DON'T collect dust.

If you do, you're going to get slammed on transaction fees... or you're going to have to find a wallet that allows you to set a manual fee (Note: Electrum will import Mycelium seed if you select BIP39 from options during seed restore), and send with a stupid low fee and your transaction will get stuck for days waiting for confirmation. You can then join the legions of people posting "ZOMG Transaction not confirmed for DAYZ!!!!!1!1!" threads... 

It "works" in the sense that it allows you to place bets on dicesites via their APIs... and gives you a multitude of options that most sites don't offer in their "autobet" settings. However, I will tell you right now that you WILL will be disappointed if you download the bot thinking that it is some sort of magic profit generating app that will make your rich beyond your wildest dreams.

The bot is advertised as "a program to automate betting strategies, like martingale, for crypto currency dice sites, or in other words, a betting bot."... and in the FAQ:


So, essentially, it is just like using the "autobet" on any given dice site... it just provides a lot more in the way of options and customisation for stopping/resetting on profit, stopping/resetting on loss, setting multipliers and bet amounts etc... and has a "programmer" mode that lets you create all sorts of fun betting systems

Also, this bot is open source and isn't a total scam like a lot of the "guaranteed to win!" scambots advertised on YouTube and dodgy blogspot pages that either steal your coins or your username/password...

I hate to be the negative guy... but honestly, I doubt that he owns that address... https://blockchain.info/address/1EWvt2QYX6KSKHrMT1yZdhHE7F44tJzscX

It looks to me like the collection address for something (possibly malware/trojan). "Total Received: 582.47734318 BTC". And then the deposits to that address regularly being consolidated in massive 40, 50, 60, 100 BTC chunks?? Yeah... that isn't some drunk guy moving coins from one address to another in the same Electrum wallet... 

OP says he moved his coins TO the 1DPdT875jAn3KF4eRdSbopiqVEGhvbAZFi address... which would be this transaction. Then almost a full 12 hours later... we see this transaction which moves the coins to 1EWvt2QYX6KSKHrMT1yZdhHE7F44tJzscX

Upgrading your wallet isn't going to magically make all your transactions confirm... and making more transactions that are spending unconfirmed transaction outputs is just making things worse. You see how you had all the "unconfirmed parent" transactions? That is basically the chain of unconfirmed transactions you have made... it is like digging yourself into a hole... and then digging further and further...

If you didn't have time anymore to wait, you shouldn't have sent transactions with such low fees. Additionally, by continuing to send coins, using outputs from unconfirmed transactions, you are just making the situation worse.

And now I suspect you have transactions like these two:

https://blockchain.info/tx/367e10a58f3595e86c716c6338efc6a2ba3e707dc956ef50de1b87ff354a5ef4
https://blockchain.info/tx/87a2f637497b927b2e33e774b47671c3f66fdc40274c50d3c6c16c0498690507

which both use fees of around 20 sats/byte... which are now the unconfirmed txes that are blocking :

https://blockchain.info/tx/6896a440fed57e8897f19c94d17f38006c6c7a8e6ceea7589e11f7e061a85afa

which is blocking:

https://blockchain.info/tx/f3ce6ae839a3fede597175e16a828a5cc90e178f72e9baf58b8c2c43cbf54bbf

If your "bitcoin activity depends my entire income", you had better learn how the bitcoin network actually works and how to use appropriate fees... I would also recommend that you stop sending long chains of unconfirmed transactions...

In the future, make sure you use "Dynamic Fees" and ensure you have enabled "Replace-By-Fee"...  that way you might be able to bump the fees of stuck transactions to try and get them confirmed faster.

To help other investigators.... the transaction IDs are:

65d4b53331a24dfdee6e91a34144645d6d2319213437db72af54ae490566f126
33a8209abb1c8b34cbaf552e0471bae7a752424cc6fefa3c87ffa1de46842797

In the future, please copy and paste the ID number here... trying to type in a 64 char txid from a screenshot is a PITA

Now, to answer your question about your transactions... The most obvious issue is that your transactions use very low fees of 50 sats/bytes. At this moment, the recommended fees are well in excess of 200 sats/byte:


Additionally, your 2nd transaction, is spending the output from the 1st (unconfirmed) transaction... so it won't be getting confirmed before the first one does.

You can use mocacinno's fee checker tool to get some tips (with links) on what you can do to get your transactions confirmed... including RBF or Replace-By-Fee (if you enabled it in Electrum), CPFP or "Child Pays For Parent", Using ViaBTC TX Accelerator (Free, but overloaded) or using BTC.com's TX Push (Paid service, possibly usable with Alipay).

Also, in future, you should make sure that you have enabled "Dynamic Fees" in Electrum's settings... this should help prevent you sending transactions with super low fees. It won't magically cure the Bitcoin network congestion... but it might help the chances of your TX being confirmed.

The simple answer is "wait".

- There are currently 150,000+ unconfirmed transactions in the mempool: https://blockchain.info/charts/mempool-count
- Some 12MB worth of these transactions (or around 12 full blocks worth) are all paying fees above 130 sats/byte: https://btc.com/stats/unconfirmed-tx

You haven't provided a transaction ID, so we can't check for issues like low fee, unspent transctions, double spend etc...

However the current recommended fees are:


Check your transaction and compare the fee... If it is below 200 sats/byte, you're going to be waiting for quite a while.

If you want to try getting it confirmed faster... visit the ViaBTC TX Accelerator and try to submit your transaction right at the start of every hour until you get the "acceleration succeeded" message... They only accept 100 txes at the start of every hour... and with the network the way it is, you have to get in quick as the accelerator service is being hammered hard.

Good luck

Your transaction: "Fee per byte 120.322 sat/B"

Compared with:
and

I'll let you do the math to figure out why your transaction is going nowhere fast... in the meantime, go and hammer away at ViaBTC TX Accelerator like the other 100,000 people with unconfirmed transactions are doing...

It was probably "rebroadcast" 2 days ago... the blockexplorers show the most recent time the transaction was received... so it probably started to get dropped from the mempool and then rebroadcast and so the new date is now showing...

OP better start setting alarms to go off 5 minutes before every hour and getting set up on the ViaBTC accelerator page waiting for the hour to tick over so he can try and sneak into the first 100 txes for the hour... (Have we had it confirmed that it is 100 txes per hour? or per block?). With the mempool count over 100,000 unconfirmed... and a metric shitton of unconfirmed transactions with low fees... the accelerator is getting hammered! 

How did you run Electrum the first time? Surely, you must have downloaded the Electrum software to a location on your computer to be able to run it at least once?

If you are on Windows, did you download the "Standalone Executable", the "Windows Installer" or the "Portable version" from: https://electrum.org/#download ?

If you didn't get the Windows Installer, it won't have setup start menu links and all that jazz... The "Standalone Executable" is exactly that... a simple .exe that you can put anywhere and run and the wallet will open. I believe the portable version is like the standalone, but doesn't create data files in your %appdata% directory... it just stores them whereever the .exe is located

From DeterministicKeyChain.java:

which leads to this a bit further down in DeterministicKeyChain.java:


Hopefully that helps... Not 100% familiar with the bitcoinj code itself... but recently I have been poking around using python to extract data from MultiBit HD wallets...

If you have an Android smartphone or an iPhone, you can use your MultiBit HD seed to restore your wallet to "Breadwallet" app. It is the only wallet that will work with MultiBit HD seeds (since Hive got shutdown).

Otherwise, you can try using my recovery scripts to dump out the addresses and private keys from your MultiBit HD wallet that have unspent outputs in them... you can then import those private keys to another wallet.

It would appear that while the MultiBit HD wallet "fees" setting says that it is calculating as X mBTC "per KB"... it is in fact just setting the fee as X mBTC for all transactions up to 1KB... so for an "average" 226 byte transaction, that should result in a relatively "decent" fee of ~221 sats/byte if you stick with the default 0.5 mBTC... However, once your transaction size starts climbing (ie. adding in multiple inputs) the fee starts getting smaller and smaller until at 1000 bytes, you would end up with a 50 sat/byte fee and transactions getting "stuck"

The fees seem to be set here:


and you either pay 1000 sats total (0.00001) , 50,000 sats (0.0005) or possibly 500,000 sats (0.005)... as when the wallet goes to send bitcoins it just calls normaliseRawFeePerKB():




seemed like they meant to calculate when you needed to add another lot of fees"

But that MINING_FEE_BOUNDARY is not actually used anywhere in the code??

Just FYI in case you missed it... as I mentioned in one of the other threads... If you have Android or iPhone you can try installing Breadwallet and importing your seed. It is the only other wallet that I know of at this time that uses the same derivation paths as MultiBit HD (m/0'/0 and m/0'/1).

If you can't use Breadwallet... then you have to do it the long painful way... although the script should now identify the address and private key that has the unspent output(s)... ie. your coins... saving you from having to try and check them all one by one...

Good luck!

If it walks like a duck... looks like a duck... and swims like a duck...   

But seriously... I'm still trying to figure out how 100 pixels on a site that seems like it was designed for Netscape Navigator 1.0 (needs more <BLINK> btw) is somehow worth 1.0 BTC... or indeed, why anyone would visit a site composed entirely of ads?

There is precisely ZERO content... and yet, somehow a tiny 10x10 pixel square is worth 1.0 BTC?? Maybe bussybuddy should sell whatever he is smoking on "teh DarkNetz"™... would probably make more money.

FYI, You will need to either use the -zapwallettxes command to get the transaction to drop out of the mempool, otherwise Core will continue to rebroadcast your transaction periodically if you don't do this.

Your other option is to shut Core down for a few days and don't use... but the problem is that while that will cause it to drop from the mempool, as soon as you re-open the wallet, it is likely to rebroadcast it...

Make backups of your wallet.dat (just in case) and then use the -zapwallettxes command

FYI, if it is a MultiBit HD wallet and you have your seed... and you have an Android or iPhone, you can install BreadWallet and restore your wallet there to access your funds until the MultiBit devs release an update to fix this issue.

If you don't have your seed, but you have your wallet and wallet password... you can use decrypt_bitcoinj_seed.pyw by gurnec to recover your seed, then restore to BreadWallet...

Finally, if you have a MultiBit Classic wallet and know your wallet password (or you have a MultiBit HD wallet, know your password and can't use BreadWallet)... I have written some python scripts based on gurnec's, that will allow you to extract your private keys either from a MultiBit HD "wallet file", a MB Classic "Key Backup" file or a MB Classic "wallet file"...

Goto: https://iancoleman.github.io/bip39/

Create an "offline" copy of the page (usually Right-Click and select "Save As...")... then run the offline version and put your seed in at the top where it says BIP39 Mnemonic... make sure the Derivation Path is BIP44... and Purpose, Coin, Account, Internal/External are set to 44, 0, 0, and 0 respectively.

The "BIP32 Derivation Path" field should show as "m/44'/0'/0'/0"

The Account Extended Private and Public Key's should match the xpub and xprv that you can see in Mycelium (Tap on Account, click 3 dots, Select "Export")...

Finally, the addresses at the bottom of the page should match what Mycelium is showing.

No... The password used to encrypt the wallet is specific to that device and installation. Different installations are independent from each other with regards to settings and passwords. So, even when you "restore" from seed, you are making a completely independent version of the wallet... so you can use a different (or no) password and all other copies on separate devices are unaffected

The moral of the story, don't got restoring your wallet on random PCs, and if you have "lost" a PC with a copy of your wallet, you may want to seriously consider creating a brand new wallet and moving all your coins to it. Even though the existing wallet on the lost PC should be safely encrypted, if your password was weak, it could be bruteforced and someone else could get access to your coins...

Are you getting the "Password did not unlock the wallet" errors? If so, your money may not be lost... (if you have Wallet Seed for HD, or password and multibit classic wallet or key file)...

Your password has not been changed. It is just some newer transactions that are breaking MultiBit Classic and MultiBit HD and result in that error message. I have already helped at least three people recover their coins... My python scripts for extracting keys from multibit classic and HD can be found here: https://github.com/HardCorePawn/multibit_recovery

Once you have your keys, you can import them into another wallet and "rescue" your coins  

Ok, I took on the challenge... and figured out what I was doing wrong when trying to decrypt the multibit classic private keys... so I have now added: decrypt_multibit_classic_walletkeys.py to my recovery scripts...  

It works on multibit.wallet files and dumps out the public/private keypairs... should work on both password protected and non-password protected wallets.  

Turns out, I was decrypting them correctly the whole time... I just couldn't get the addresses to match because the python functions I was using to generate addresses was generating the "uncompressed" addresses/keys... whereas MultiBit is using compressed keys... pretty obvious really

Or you should "rescue" your coins and move them to an actively developed/supported wallet... I suspect this issue will be just the tip of the iceberg... and who knows what will start happening when/if SegWit or Hard/Soft Forks start happening...