Short answer: No, Yes and No

It won't lock you out. Also, as the wallet is not encrypted, you can also try running one of the password recovery scripts on it... so, no need to worry about it being locked out. If you're concerned, just make a backup of the wallet file somewhere.

Electrum will not have set a default password. It doesn't do that. You will have had to have entered something twice to get it to generate the wallet. It doesn't enforce any rules on password length or complexity, so you could have just put 1234 or abc or password or even just a space.

If Electrum isn't asking for a password when you open the "default wallet"... and you can view the text in the wallet file, it sounds like your wallet isn't encrypted... however the "seed" and "xprv" that you can see in the wallet file are encrypted using the password for the wallet... That is why it asks for your password when you want to view the seed or private keys.

If you do not have the 12 seed words that Electrum forces you to write down and re-enter when creating a wallet, then you're probably not going to be able to regenerate the wallet. If you don't have your password, getting access to the private keys or the ability to send coins is going to be very difficult.

You may want to try using btcrecover or one of the password recovery services that are offered here on btctalk to try to find the password.

I assume you have already tried your "normal" passwords or passwords that you think you may have used around the time you created the wallet?

In the interests of knowledge sharing and learning... are you guys able to provide more details as to the processes and logic involved with "cracking" this puzzle? For instance, I'm not sure where amaclin got this:


Where did this script come from? was that part of the raw transaction from the receiving or sending of funds? 

Following on from that, is there some sort of weakness in the way that the multisig address has been setup (hence the colour coded 02 and 03?) that might enable one to obtain ownership of the coins?

I'd like to learn more

No, it wasn't the ViaBTC accelerator... If it had been that, the block would have been mined by ViaBTC

That is how the accelerator works... by submitting your transaction there, ViaBTC prioritise your transaction in their system and will try to include it in a block that they mine... so if they don't mine a block, their accelerator won't help at all.

Guess you just got lucky 

I guess the transaction got rebroadcast... in any case, it looks like AntPool have included it in a mined block, so... happy days

The transaction is still visible on Blockcypher and I can see it in the mempool on my full node, so it hasn't been completely purged as yet.

At this stage, one of two things are going to happen:

1. The transaction will confirm (maybe even money chance given the "lowish" fee used ~95 sats/byte)
or
2. It will get dropped from the mempool completely, and it will be like your transaction never happened, and your wallet should allow you to re-spend those coins.

I tried submitting the transaction to the ViaBTC tx accelerator, and it went through, so hopefully they will mine a block and your transaction will confirm.

Your other options are to try a "double spend" and redo the same transaction with a much higher fee (I don't think MultiBit HD will let you do this as I don't think it supports "Replace By Fee")... or you could try a "Child Pays For Parent" transaction if you own either of the addresses:

1AQapK1AGpHqwqyUvyPkcBKvmqEgqBaxRE
12ebnyuH41wxuQvMZxtwUabKJfDD387nmB

that are receiving outputs from your transaction. Google "Child Pays For Parent"... basically, you spend the unconfirmed coins that the address received with a fee large enough to cover both transactions and a miner might include both to claim the large fee.

You want to run two counters then... one for monitoring double wins, and one for monitoring X wins... If either one reaches the target, then reset everything and reset both counters. This would ensure that you don't get the situation that Seuntjie was talking about where the X wins one keeps kicking in... Something like this:

Just FYI, the MultiBit devs removed the "client fee" (aka BRIT) from version 0.3.0 onwards: https://multibit.org/help/hd0.1/how-brit-works.html

So the only fees being set by MultiBit HD will be the bitcoin transaction fess (aka Miners fees)... The default value of the slider in a clean 0.5.1 install is "mBTC 0.50 000" per KB apparently:



But when I try to send a transaction for 100 mBTC, it tells me I have insufficient funds "missing 10050000 satoshis"... so I'm not sure if it is calculating the fees correctly... it might be setting it to 50k sats because there are no inputs for it to attempt to spend so it can't calculate the transaction size properly? 

Unfortunately, it sounds like you don't have a problem with Electrum wallet, you have a problem with security

If what you are claiming is true, that all the coins were transferred from your addresses, then someone has managed to get hold of the private keys or seed words for your wallet. Are you able to post the transactions IDs?

Also, if you have been hacked, it is quite likely that you have some sort of malware on your PC... I would cease all bitcoin related activities on this machine until you are confident that it is no longer compromised. You should either scan your PC with AntiMalware tools (Try this guide) or to be completely sure, format your computer and reinstall the OS from scratch.

It might seem dramatic, but it guarantees the malware is gone and is what I would personally do...

Have you been collecting a lot of small payments from faucets?  If so, it is likely that the data size of the transaction is very large (even if the value of the transaction is low) and Electrum is trying to use a large fee to pay for it, based on the current "average" fees...

DannyHamilton wrote a really good summary of exactly how this all works here: https://bitcointalk.org/index.php?topic=1882413.msg18710514#msg18710514

If this is the case, you may need to go in to preferences and use the "edit fee manually" option, so you can specify a flat fee (hopefully you can make it more than 10 satoshi/byte, then you can use the ViaBTC TX Accelerator to get it confirmed, because if the fee is too low, you transaction make take days to confirm.)

However, without knowing how many transactions you've received, or the size of them... and how much you're trying to send... it is difficult to tell exactly what is wrong.

Ummm what?? 

You realise that to be able to transfer coins in off-chain transactions, you first need to front the coins in an on-chain transaction right? You don't get to magically start sending coins to people because you feel like it... and the LN participants can't just issue coins to people from nothing.

I thought the difficulty in implementing the LN was due to the malleability issue (one of the things which SegWit addresses) ??

I would think the part you're looking for is here: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#master-key-generation
and possibly the section above: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions

Electrum uses "m/0/n" doesn't it for BIP32 HD wallets and addresses: https://bitcointalk.org/index.php?topic=274182.0

So, I would think that the first derive(0) puts you at m/0 in the tree... and then the 2nd one starts generating the child keys that match up to the addresses.

Now who is being an idiot hmmm??? 

Do you actually understand the concept of "Provably Fair" and the basic fundamentals of the dice game and random number generation?  They CAN'T change anything because 1. There is nothing to actually change and 2. There is no need to change anything.  Random numbers are random numbers... not quite sure how you can change that??  Unless you're suggesting that all the dice games are rigged, don't generate random numbers and are somehow able to circumvent the maths involved in SHA256/SHA512 cryptography... 

We all know that it is mathematically impossible for everyone to beat the house in the long term, it's baked into the system using "House Edge" and the maths of probabilities and large numbers. The only thing a strategy is really useful for is minimising your individual risk... note: NOT eliminating, as that is impossible... but minimising...

And no, this was not to introduce some betting scripts... Someone mentioned it might be a good idea to try coding it up for the dicebot... so I did because I enjoy the challenge... and I've had several people contact me previously with regards to creating custom dicebot scripts for whatever crazy strategy they've come up with... I was just thinking out loud that I might be able to trade my dicebot script coding skill for some spare change so I can waste it all gambling

I did some research into "max expected loss streaks"... and found websites like this one that show a formula for calculating the max expected loss streak as:


where win% is a decimal from 0.00 to 1... ie. Percentage/100, so that 80% win would be 0.8, 1% would be 0.01 etc.

Via another reference (that I can't locate at this time), ln() function can be replaced with log() function and you can use:


Putting some example numbers in, we would get:

Log(1,000,000) / -Log(1-0.8 ) = 8.58 or ~9.

So you could expect a loss streak of 9 in 1,000,000 rolls at 80% of winning.... which would at first seem to be well under the max sustainable by your max Bankroll...  HOWEVER, you seem to have confused your numbers and units... at the start you're talking 0.00000100 mBTC basebet and USD$1,000,000 and the max as 470k (no currency unit specified)....  

If we assume, you actually meant 0.00000100 BTC (ie. 100 satoshis) as your starting point, and we converted your USD$1mil that would be ~800 BTC at current prices. This would reduce your sustainable max losses down to 12 losses (at which point, you just lost a 362.79 BTC wager, and your total losses are 435.35 BTC), the next required bet would be 2176 BTC, which you don't have.

Still, your max expected loss streak is only 9... so that should theoretically be doable... HOWEVER (yes, more bad news)... most, if not ALL casinos, be it online or bricks and mortar have "Max Bet" and/or "Max Payout" rules. I highly doubt you will find a casino that lets you wager 60 BTC at a 1.24x payout (~80% chance)... And for a lot of them, even 10 BTC at 1.24 would be getting close to their max.

So now you're down to maybe being able to make 10 losses before you hit the max bet/max payout limit... and given that the formula is just an "estimation" of the "expected" max loss streak... doesn't mean it can't or won't go higher... I've actually had a scenario where the max expected streak was calculated as 62, and I encountered 67 losses.

Also note that even if you hit the win at the 10BTC bet... your overall profit would only be 0.4 BTC... do you really want to be risking ~$10,000 to make ~$400?

I'm not sure increasing by .1 would enable you to get out of "debt" tho... that is my only concern with this strategy, I noticed a couple of times that you can end up in a bit of a vicious cycle, where you win on the first bet after backing out a level, increase, move in and then lose the cycle, then win on the first bet after backing out, increase, move in... lose the cycle etc etc...

For that cycle to break, you need a bit of a lucky streak where you hit a couple of the lower chance rolls (ie, corners, streets and splits) almost consecutively...

In any case @CiderWaffles... thanks for the heads up on the strategy... I like trying new and interesting strategies other than straight Martingales with different payouts/increases...

Also, trying to code different strategies in the dicebot can be a challenge and helps exercise the brain I'm actually thinking I might try and sell my dicebot coding skills, coding custom scripts for people for a minimal fee to help cover my time and "testing"

Yes...  you can see here:


according to the spreadsheet, I should have received 0.0057 for my eligibile posts on week 19, and I received 0.0157 on 6th April as per notaek's post.

I suggest you double check your 6th April Payment, as it seems you had no posts for that week (Week 19) and you got paid 0.

Does this site look at all familiar to the starcasinobitcoin.com website??   

The only difference being a few poorly edited graphics... oh and the fact that the links on vegascasino.io actually work and it isn't a total scam

vs.

(I took the liberty of adding some edits to the graphics for starcasinobitcoin myself )

Nice try Jose... hope you didn't pay too much for the domain name and webhosting...

Just to reiterate: starcasinobitcoin.com IS A SCAM


It was discovered here: https://bitcointalk.org/index.php?topic=1879375.msg18677538#msg18677538

There is nothing preventing you from re-using any of the addresses that Jaxx generates for you.

While it is true that Jaxx (and most of HD wallets) will automatically generate a new address when the previous one receives a payment, the previous address doesn't disappear or stop working. You can continue to receive payments to it. This is (should be?) true of pretty much all wallets.

Note: As an aside, generally speaking, address re-use is not recommended if you care at all about maintaining the pseudo-anonymity of Bitcoin.

Have you tried the suggested solution in the MultiBit help if you are getting Connection Error messages?

NOTE: I would advise making sure you have appropriate backups of everything before you start deleting files

I am fairly sure that the setting you are referring to, simply allows you to specify the block explorer that MultiBit will use when you drill down into the "Details" section of a transaction listed on the "Payments" screen.

So, it has no effect on either fees used when making transactions nor the speed at which any of your transactions will be confirmed.

The MultiBit support site seems to say the same thing: https://multibit.org/help/hd0.1/payment-settings.html