If that's what happened then when he re-enters the seed to verify it Electrum would reject that.
Assuming he then tried typing in the seed from the screenshot and didn't just re-enter the newly displayed seed without realising it was different... Anyway, if he has a screenshot of the seed, then there really isn't a way for him to have created a "different" wallet using the seed from the screenshot... so it would appear that the only logical explanation is that all this time, the user has been using a completely different wallet with a different seed (possibly one that already existed on their computer) without realising it. |
|
|
|
Woah! that makes it impossible to recover if they aren't supporting the app any longer.
No... that is incorrect. Mycelium uses BIP39/44... so you can restore your seed to ANY wallet that uses BIP39/44 and you will get your wallet, transaction history and coins. |
|
|
|
|
Ok... once again... one of the coins you are trying to spend is UNCONFIRMED... and the transaction creating it does not appear to have propagated well... this missing transaction with the missing coin has a fee of 1 sat/byte... hence why it hasn't confirmed and seems to have been dropped by most of the network.
Your current transaction with the large size and the 71 sat/byte fee CANNOT be confirmed until this missing transaction is confirmed.
At this stage, your best bet is to just wait until ALL your transactions are dropped... "abandon transaction" and/or zapwallettxes and then start all over again.
|
|
|
|
they should warn use about the cost of useing that fml.
They do... they have a big giant page telling you all about 2FA when you create the wallet:  It mentions fees and that you can check the costs after setup... if you click the little blue shield, you can see the payment options... It also mentions you can get your coins out at no cost by restoring from your seed and disabling 2fa functionality |
|
|
|
|
"rescan" basically looks through every block in the blockchain looking for transactions that relate to addresses in your wallet. It then puts these transactions into your wallet transaction history.
Also, it's possible you have coins in "change" addresses, these will not show in your list of addresses (ie. file -> receiving addresses)... as they are "hidden" in Bitcoin Core. However, the rescan should pick them up and find all the appropriate transactions and display your correct balance once it has finished.
|
|
|
|
|
You coins are probably NOT on address 1Pc8DMSSEnPfJNovxb8rAe4D8G9Ee9Q89Q
They are probably on a different address in the ElectronCash wallet. Have a look at the "Coins" tab in ElectronCash ("View -> Show Coins") and see what address(es) your +0.716602227 BCH are actually on. Then check THOSE address(es) on blockchair
|
|
|
|
|
Based on your explanation... this would appear to simply be a "change" address. Note that "change" addresses will NOT show if you click "file -> receiving addresses".
Goto: "Help -> Debug Window -> Console" and type listunspent
Look through the output and make sure that the 1mAo address is displayed with amount 7.58 BTC
|
|
|
|
|
It depends... if you try to send more than the amount in the address, it will need to combine more inputs to make the amount you want to send...
for instance:
Address A has a total of 0.1, received as:
0.01
0.02
0.01
0.03
0.03
Address B has a total of 0.6 received as:
0.6
If you send 0.6 (ignoring fees)... there is a good chance your wallet will send just the output from Address B. However, if you decide you want to send 0.65, it is going to need to add in the coins from Address A to make up the difference.
If you want to be 100% certain, you can just click "preview" and make sure Electrum is using only one input... if it isn't, you can just go ahead and "spend from" a specific address if you want.
|
|
|
|
|
Seems like your button is stuck or something and it is just automatically powering into bootloader mode... try and give the left button a couple of (light) presses to see if it unsticks itself... then try reconnecting... otherwise it sounds like upgrading your MCU did not work as planned... if it is still on "bootloader" screen, then open Ledger Manager and connect your device, it should hopefully reflash the MCU properly.
If that doesn't work, you'll need to contact Ledger Support.
|
|
|
|
It is because you say: nextbet = 0.00001000 and then IMMEDIATELY give the script two options: if balance > startbalance then nextbet = basetbet else nextbet = previousbet*2 end So regardless of which option is true... nextbet is going to get changed... EVERY time... it will either bet basebet or it will be previousbet*2 Your "if currentstreak%6==0 then" statement is not working to stop losing streaks... because it is INSIDE the "if wincounter > 3" block... so that condition is ONLY checked if wincounter > 3... so it will only trigger when you have a losing streak of 6 AFTER wincounter > 3... but you immediately set wincounter to 0 as soon as getting in, so you'll NEVER have the situation where your losing streak is 6 and wincounter > 3. WARNING: This code is mostly untested... I did a quick check and it *seems* to work as desired... use at your own risk!  -- FourWins Strategy for fwalser
-- coded by HCP
startbalance = balance
target = 0.00010000
chance = 49.50
basebet = 0.00000001
bigbet = 0.00001000
wincounter = 0
fourWins = false
nextbet = basebet
function dobet()
if win then
wincounter += 1
if fourWins then
--win while betting big, reset back to base
nextbet = basebet
fourWins = false
wincounter = 0
else
--win while basebetting, check if we have had 4 wins
if wincounter > 3 then
wincounter = 0
fourWins = true
nextbet = bigbet
else
nextbet = basebet
end
end
else
-- we lost
if fourWins then
-- bigbetting, see if our lossstreak is 6 losses
if currentstreak == -6 then
-- 6x loss streak, cut our losses and reset
fourWins = false
wincounter = 0
nextbet = basebet
else
-- loss while big betting, double up!
nextbet = previousbet*2
end
else
-- standard loss
nextbet = basebet
end
end
--Profit Target check
if ((balance - startbalance) > target) then
--target profit reached
print("Target reached! STOPPING!")
nextbet = 0
stop()
end
end
|
|
|
|
What are your thoughts about supporting Bitcoin Cash in the future now that Bitcoin fees are going to the roof and Darknet Markets are starting to accept it?
We would rather use other altcoins than Bitcoin Cash. BCH only advantages are
1. There is less traffic therefore it is cheaper to send it.
2. It is less valuable therefore transaction fees are smaller.
3. Interface is almost the same as Bitcoin.
Disadvantages are:
3. Interface is almost the same as Bitcoin.
We do not plan to support Bitcoin Cash now.
Can you imagine the carnage with people sending BCH to ChipMixer BTC addresses... or BTC to ChipMixer BCH addresses??!?  Given the number of threads with people doing exactly this with Exchanges and the like, I would hate to be in ChipMixer support if they started offering a BCH service!  |
|
|
|
|
Was it just a balance of 0 but with transactions showing... or was it just a completely empty wallet with no history?
|
|
|
|
|
Electrum does not store imported BIP39 seeds in the wallet file... Only the generated xprv, thus it is unable to show the seed and the menu is greyed out.
I believe this is done to avoid users thinking they have an Electrum seed, when it was originally a BIP39 seed... (Electrum seeds are not BIP39 compatible)
|
|
|
|
|
Then it's not on that address. Electrum wallets contain multiple addresses... If you're just looking at the "receive" address listed on the receive tab, you're probably looking at an empty, unused address (by default Electrum and ElectronCash use the first "unused" address to receive)
You should look at the "coins" tab to see which addresses the coins are actually sitting on (View -> Show Coins)
|
|
|
|
Electrum will incorporate multiple inputs when the amount you are trying to spend is larger than your largest single input. (Ie. It cannot be spent from only one input) You can use the coin control features of spending from specific addresses if you want more fine grained control. As per Bitcoin protocol, whole inputs will ALWAYS be consumed... You can't leave half an input behind... If you don't send the whole amount, some comes back as change (in Electrum, by default, this will be a "new" address) My advice to experiment with TestNet still stands. It's the only way you're going to fully understand what Electrum will and won't do... As opposed to just continually asking hypothetical questions, go play with the system without any danger of financial loss |
|
|
|
|
Most likely, the old version is likely to be your issue. There have been multiple instances recently of people running older versions having troubles syncing.
You don't have to remove 2.5.2... you can just get the 2.9.3 portable and put it in the same location and then run it.
|
|
|
|
Honestly, there is nothing that can be done. With a 2-of-2, you absolutely need 2 signatures to be able to send funds. If all that GreenAddress provided is an nLockTime partially signed transaction, that isn't going to be of use to you as it will have been signed for BTC (sending to a BTC address) and not for LTC. While the addresses can be compatible, I don't think the transactions are (ie. You can't create a BTC transaction and transmit it in the LTC network). "Cross-chain" transactions involving MultiSig can be extremely difficult to recover from unless you have all the keys  |
|
|
|
|
Show Posts
