I think I understand what may have happened...

If you look here https://blockchain.info/charts/mempool-count you can see that 4 days ago, the transaction volume was very low... Dynamic Fees suggestion would have been low. Then, just as you sent your transaction, the spam attack started and the number of unconfirmed transactions shot up to like 60K+... so everyone started paying higher fees and your transaction got buried

You just got unlucky, no one could really have predicted that the volume of transactions was going to just spike up like that... Electrum can't control people spamming the network... a lot of people using all different wallets will have been caught out by this.

Electrum does have a nifty feature that can help prevent his from happening again tho... make sure that you have "Replace-By-Fee" option enabled for your transactions (Tools -> Preferences -> Fees and make sure that "Propose replace-by-fee" is set to always). That way, in future, should this happen again and you get stuck with a low fee, you can just re-send the transaction with a higher fee

If your transaction is showing in the history as "Replaceable" you can just right click on it and select "Increase the fee"... Ref: http://coinour.com/index.php/how-to-apply-replace-by-fee-to-save-the-bitcoin-transaction-fees/

Did you also import all the "change" addresses that belong to the MultibitHD wallet? I suspect what you are seeing is an HD wallet with change addresses in action.

It goes something like this:

- You make a large payment for 2.0 BTC into AddressA... your wallet now has 2.0 BTC...
- You then send a small transaction for 0.01 BTC to a friend. The wallet has to use the WHOLE 2.0 BTC input and spend it (that is just how bitcoin works)... break off 0.01 BTC and send it to your friend and then deposits the remainder 1.99 BTC into a "change" address (AddressChange1) that your wallet controls. Your wallet now has 1.99 BTC in it... but it is not in AddressA now, it is in AddressChange1.

You'll probably find that the difference in the total that MultibitHD was showing, and what Electrum is now showing, is all the change that is stored in change addresses which you have not imported.

Did you also check addresses/keys that use the the BIP32 Derivation Path: m/0'/1  as was mentioned by HI-TEC99? These are the change addresses that MultiBit will have created, and where the leftovers from breaking up larger inputs will have been put.

Without the TXID and transaction details we can only guess... my guess would be that you sent the transaction with a fee that was too low and the transaction has not been confirmed.

If I understand that correctly and you still have the funds on your paysafecard... I'd suggest sending it somewhere else as fast as possible! that exchanger-bitcoin site would appear to be a scam:

https://bitcointalk.org/index.php?topic=778007.0
https://bitcointalk.org/index.php?topic=1080227.msg11541002#msg11541002
https://bitcointalk.org/index.php?topic=947622.0
https://bitcointalk.org/index.php?topic=836379.0

Most of these messages are at least a year old... next time you should do a Google search before trusting your money to a website.

The slider allows you to set a "target" confirmation time for transaction, measure in blocks... and Electrum will slap on a fee that the Electrum Servers estimate will have a good chance of getting your transaction confirmed within that many blocks.

I believe the slider steps are set to 1, 2, 5, 10 and 25 blocks...

Note: these are just targets and estimates... there is no guarantee that your transaction will confirm in that timeframe.

No... he isn't concerned about the value of the transaction... he is concerned with minimum fee and sending TX where the fee isn't appropriate to the size

OP can just use latest version of Electrum (2.8.2), and select "Edit Fees Manually" from "Tools -> Preferences -> Fees"... then when he goes to send the transaction, he can set whatever ridiculously low fee he likes

Just bear in mind that the Electrum servers (and/or Bitcoin Network) may not relay your transaction if the fee is too low.

To be precise, it is the first "hash" in the checkpoint_array[] struct defined for "main net" around line 79 in the source here:

https://github.com/voisine/breadwallet/blob/e607583477870bee2c0b4490b955c3aeb49ec7d8/BreadWallet/BRPeerManager.m

The hash is: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
Block Height is 0.

If you're creating a wallet for a different virtual currency, you would need to adjust all of the values in this struct to match the appropriate values in the blockchain for that currency.

Have to agree with mocacinno... Electrum has one of the better interfaces in my opinion...

It does, but probably not to the extent that the OP wants... there is a simple slider that you can move up and down... but it doesn't really give fine grain control (and it is supposed to calculated on a mBTC/KB basis, but in a lot of instances of people having difficulty with MultiBit it always seems to set a fixed fee according to the slider? )



I think the lowest you can set on the slider is 0.1 mBTC/KB.... which seems to line up with the 10,000 sats that people end up using as a fee when sending from MultiBit HD and getting their transactions stuck...

EDIT: turns out the lowest is actually 0.00000 mBTC/KB  the next step up is 0.02500 mBTC/KB or 2500 sats...

You're betting via API's... the site already knows you are likely using the Dicebot... not many people are going to take the time to handcraft JSON and POST requests to roll dice when you can just load up the website and bet via the front end

Also, it isn't like the site owners don't know about and/or allow the Dicebot... they actually have to pay Seuntjie to get their site added into the Dicebot!

Yep, that is exactly how you create an "array" (in LUA they are "tables")...

And just a FYI, the convention in LUA is to index Arrays from 1... don't start counting at 0 like you would in C or Java etc

Firstly, don't call your array "chance"... that is a built in variable that the bot uses to send the chance value to the dicesite


This will pick a "random" value from the chanceArray... the #chanceArray value is the number of items in the Array... so you can add more values or take some out and the code will still run without generating an "Index Out of Bounds" type error

Glad to hear you got it all working... hopefully some of what I said helped and wasn't too confusing

I was under the impression that transactions with the yellow hazard symbols should only be showing if the transaction in question is still waiting for a confirmation and has not been dropped from the mempool. If it is still showing, then it might still be trying to confirm. How old is that transaction, and have you checked to see if it is still showing on block explorers like blockcypher or blockr? Any chance you can post the txid?

Finally, your idea to simply spend from the seedless wallet first should achieve the goal of eventually having all your coins contained within the seeded wallet... it might just take a bit longer

Seems you have enabled the "Replace-By-Fee" option in preferences? (or the person sending a transaction to you has)... this enables the transaction sender to resend the transaction with a higher fee if it gets "stuck" due to network congestion and a fee that is too low.

So, either:

A. If you sent it, letting you know that you can re-send the transaction with a higher fee if you find it has become "stuck".

or

B. If someone sent it to you... warning you, not to trust this transaction until it gets at least one confirmation, as there is a chance that it could be replaced (with the coins sent to another address) by the transaction sender.

I expect that you will be disappointed... 

Yes, you are correct, no need to create a third wallet... just send the entire contents of "my-seedless-wallet" to an address contained in "my-seeded-wallet".

You can do this as a normal transaction. Just create a receiving address within my-seeded-wallet (or re-use an old one if you like)... then open my-seedless-wallet and send all the coins to that address. Just make sure to use a good fee!

Where exactly is the proof of this?  

I haven't actually seen you show any proof that you got given one hash shown as the "Next Bet: Server Seed SHA256 Hash" value... then you made the bet and then the provably fair tab showed a completely different hash in the "Last Bet: Server Seed SHA256 Hash" section...

I've seen a lot of 20pt red font crying "scam"... but no actual proof.

Meanwhile... I went to ParaDice.io... and to start with I see this:



See the Next Bet hash? Then I make my roll... result is 27.22...



we go back to "Fair?" tab and we see:



Hash is now showing as the "Last Bet" hash... and I can see the last bet seed was "ANW11iJuvI8vmiCy2koi8Bcacl-27.22109999999999985220711096189916", which has the roll result 27.22...

The SHA256 for that seed = cb2b7a48508555c1373db0fd2aded04125c6949f452565323c3b974af283bd5d

which is exactly what they showed before and after my roll... so it all checks out.

Yeah... the OPs usage of transaction information from the 3rd Party service is very confusing... It would appear that this service is taking a fixed 0.001 BTC from the transaction values (possibly as a contribution to mining fees? ), so the values aren't the same when looking at the actual transactions on the blockchain.

177AnkPzv12EWThJEQq4iSDC3W5EZUtfPR: (Wallet 1)
0.17546656 BTC sent to this address vs. 0.17446656 BTC received.
0.009 BTC sent to this address vs. 0.008 BTC received.

1NdagsP6LGW4mLhujZ8HoLs8QjybncBawv: (Wallet 2)
0.008001 BTC sent to this address vs. 0.007001 BTC received.
0.184 BTC sent to this address vs. 0.183 BTC received.

OP is saying both of those addresses, are theirs... but they are contained in separate wallets... and that they then attempted to send from Wallet 2 (the one containing "1Ndag" address)... to Wallet 1 (containing the "177Ank" address).

Following the deposits to the 2 addresses, I see the transaction from Wallet 2, that sends 0.00536672 BTC to 1LDFuin4Hbue4yYAkYNPd1jTZp8qNYRYBj, and puts the remainder (0.17732902 BTC) into 1EJFi2ivgcjTpXqg6Kz2st91h4qyf7weLF (which I am assuming is a change address in Wallet 2).

Following this, the entire balance of Wallet 1 got sent out in a transaction... sending 0.020857 BTC to 15sBvzePpehx9kUvWrG9PJ1ry3e7LMTYqz and 0.15349413 BTC to 1EVj5PEbY7Miky8CpEtTrtZoaMfXpvgqDv.

The OP then attempts to send 0.13399774 BTC from Wallet 2 to Wallet 1... it uses part of the coins from the 1EJFi2ivgcjTpXqg6Kz2st91h4qyf7weLF change address, but fails with the extremely low fee, so it is still unconfirmed.

I had initially thought that is was the transaction that emptied Wallet 1, that the OP was claiming was not the one they sent... but upon re-reading it all, they seem to saying that it is the 0.00536672 BTC to 1LDFuin4Hbue4yYAkYNPd1jTZp8qNYRYBj that they didn't send?

This statement leads me to believe that the OP does not understand about change addresses and how their wallet spends from them... and may be the source of some of their confusion.

Because some people seem to fail at understanding the various "Provably Fair" techniques... here is a quick run down:

1. "Nonce" method:

Server seed is "fixed"  (server seed hash shown as proof) and Client Seed is "fixed" and has a nonce (basically an incrementing counter) added to end. Once you reveal the server seed, you can then validate all previous rolls, and server seed will then be changed and a new server seed hash provided.

Roll result is (usually) calculated by combining server seed, client seed and nonce and generating a HMAC-512 hash and then taking first X digits from the hex result (converted to decimal)

Server can theoretically calculate all future roll results (for the current server seed + client seed pair), BUT CAN'T CHANGE THEM... That would break the server seed hash result.

DuckDice uses this method.

---

2. random Client Seed + random Server Seed method

Server seed changes every roll (server seed hash shown prior to each roll as proof), client has the option to change the client seed every roll if they want...

Roll result calculated by combining server seed + client seed and generating a HMAC-512 hash and then taking first X digits from the hex result (converted to decimal)

Server cannot know what any given roll result will be in advance unless the client is using a static seed and never changes it.

Crypto-Games.net uses this method

---

3. Server seed + Roll result method.

Server seed can change every roll or be fixed.

Roll result is pre-generated by the site before bet is made (method for generating roll result may be unknown/unpublished, but it is in the best interests of the site if it is properly random, otherwise someone could predict the patterns and ruin them)

Server seed + roll result are combined, SHA256/512 hash calculated and provided prior to bet being made as proof. NO Client Seed is used or required.

Once bet is submitted the server seed + roll result are shown (along with the previous hash for verification purposes)... new hash for next seed/roll result is generated and provided.

Server knows reach roll result BEFORE you place a bet, BUT CANNOT CHANGE IT, because that would break the server seed hash.

ParaDice.io is using this method.

---

In my opinion, ParaDice.io probably shouldn't call the hash that they generate from the combined Server Seed + Roll Result, a "Server Seed Hash"... as technically, it isn't just a result of hashing the Server Seed... it is the result of hashing the Server Seed AND the pre-generated roll result combined. This may be causing some confusion.

Additionally, their provably fair system, is pretty cumbersome for the players... You can't go back and check historical bets and view the provably fair data for them... you would need to manually copy and save each "Server Seed Hash" prior to placing a bet... and double check it after each roll, which is just annoying

In any case, in ALL of these methods, even the ones where the server is pre-generating the result like ParaDice.io... the server cannot possibly change anything that the hash is related to, after it has been provided to the player. The maths of SHA256 (and 512 as applicable) make it, for all intents and purposes, impossible for them to modify anything... as (ironically) pointed out by MafiaCoin in his "Scam" accusation, if they change anything, it breaks the hash calculation.

Can you confirm that your address is: 177AnkPzv12EWThJEQq4iSDC3W5EZUtfPR

If so, I don't understand what you're saying by you "sent out" the transaction... as the transactions are sending coins TO that address?? Did you purchase coins from a bitcoin seller/service? Or were you just transferring coins from one wallet to another?

In any case, if you did not create transaction a84b7f3d4df8e3a298395e69a7e6f5c1bbeeaca87f0d7e12f462c23e8713a68a then it would appear that the private key to 177AnkPzv12EWThJEQq4iSDC3W5EZUtfPR has been comprised, as the coins that were originally placed into that address have been spent... is that address under your control, and if so, what wallet is it in?

Until you figure out what has happened, I would refrain from sending any more coins to 177Ank address... when your current transaction is confirmed, you should immediately send them to another address (preferably in a different wallet, as your whole bitcoin Core wallet may have been compromised)

You haven't mentioned what version you are upgrading from. There were some upgrades in Electrum that changed the wallet file formats etc. so be wary if you are jumping several versions.

If you backup the wallet files for your seedless wallet, and have your backup seed, there isn't too much that can go wrong that you can't fix. You can just use the backup wallet file and seed to recover.

However, the ideal scenario, as mentioned by Coin-Keeper, would be to consolidate all your coins from the seedless to the seeded wallet. That way, all you require is your seed words backed up safely somewhere... In the event of total wallet loss (ie. your computer exploded and you had to buy a new one and reinstall everything from scratch), You just enter your seed words and all your addresses, transactions and coins would be recovered.

The wallet files (in Windows) end up in %APPDATA%\Electrum\wallets

%APPDATA% on Windows7/8/10 is usually something like C:\Users\<username>\AppData\Roaming

Note: the AppData directory may be hidden by default in Windows Explorer.

"Unconfirmed Parent" means that the transaction is attempting to spend coins from a transaction that is unconfirmed.

ie.

You receive TransactionA - Status Unconfirmed
You attempt to send TransactionB, using coins from TransactionA (still unconfirmed)

TransactionB will now show as "Unconfirmed Parent" as it's parent transaction(s) (TransactionA) is still unconfirmed.

You'll also see that status, if someone sends you coins from an unconfirmed transaction.