Firstly, it does not look like you attempted to use "Child Pays For Parent" properly... both of the outputs for your unconfirmed transaction are currently "unspent". CPFP works by spending an output from the unconfirmed transaction, using a big enough fee to cover the new transaction AND the unconfirmed transaction and make it attractive to miners to want to include both transactions in a block. (Presently, you'd need to be making a total fee of around 180 sats/byte according to https://bitcoinfees.21.co/) Secondly, you can't use Replace-By-Fee at the receiving end.... RBF can only be used by the transaction sender... ie. the party that actually sent the transaction, which was Glidera, not you. Glidera sent your deposit with a 100 sat/byte fee. The bitcoin network has been swamped for the last couple of days... literally ten's of thousands of unconfirmed transactions... granted, a lot of them are spam transactions with super low fees, but currently, btc.com is showing some 21Megs (or ~21 blocks) worth of transactions that are all HIGHER than 100 sats/byte. They are likely to get processed before your transaction. I even tried to use the ViaBTC TX Accelerator, but it seems everyone else is using it as well... "Submissions are beyond Limit", as they only allow 100 submissions per hour. Conclusion: You, like the 50,000 other people with unconfirmed transactions, are probably going to be waiting a while for your transaction to confirm. My suggestion is to just keep trying the ViaBTC TX Accelerator every hour until it gets accepted. Even after that, it will still need ViaBTC to mine a block, so is likely to take a few hours, but it is better than nothing.
|
|
|
... Also in the newer versions you can bump the fee for a transaction after it has already been sent Only if the transaction is marked "replaceable"... which, I think by default, only occurs with what Electrum defines as "low fee" transactions... otherwise you have to go into the "tools -> "preferences" -> "fees" and select "Always" from the dropdown for "Propose Replace-By-Fee"... Also, only the Sender can try and bump the fee... if you're receiving bitcoins and they're unconfirmed due to low fee, your only option is "Child Pays For Parent"...
|
|
|
Electrum allows you to pre-generate addresses... assuming the 50 or so it pre-generates isn't enough... You could always manually edit the gap limit in the config file so it pre-generated more... To get a giant copy/pastable list, you can just use listaddresses() in the console (note, this includes ALL the addresses including change addresses and already used addresses) There are probably other console commands that might be helpful, but I've only just started to delve into the Electrum console environment
|
|
|
The trick to importing a Mycelium seed into Electrum is that when you have the dialog window that lets you enter the seed in, you need to click "options" and then tick "BIP39 seed" (as Electrum uses a custom seed algorithm by default that isn't 100% BIP39 compatible) I can confirm that this works... as I've personally done it note: you will only be able to access the first account from the Mycelium wallet this way... if you have other accounts, you would need to do the convert mnemonic to private key method following the correct derivation paths using a tool like: https://iancoleman.github.io/bip39/
|
|
|
I suggest you go and read about change addresses... what they are and how they work. Basically, when you go to send some coins to a person, Bitcoin requires that you "spend" whole inputs... you don't just extract the fraction that you need and send it. So it goes something like this: 1. You receive a payment for 1 BTC into Address A. 2. You want to send 0.1 BTC to your friend... 3. Your wallet will take your 1 BTC from Address A as an input and break it up creating 2 new outputs... 0.1 for your friend and 0.9 that comes back to you. 4. The wallet then sends, as one transcation, 0.1 to your friends address, and sends 0.9 into ChangeAddressB, controlled by your wallet. |----> 0.1 FriendAddress Address A 1.0 BTC ---| |----> 0.9 ChangeAddressB
This is the reason why you see this: Of the 2 transaction below (details from wallet), I made the "1LDFuin4Hbue4yYAkYNPd1jTZp8qNYRYBj -0.00567098" They did recive it. (sorry I said it was not me, forgot) TRUE 2017-04-07T15:50:22 Sent to 1LDFuin4Hbue4yYAkYNPd1jTZp8qNYRYBj -0.00567098 ec62fe6efdc749bf453fe5c1736d7cb514fe8c9c567de9f95a0a3bf04b5b01bc This one I did not make. TRUE 2017-04-07T15:50:22 Sent to 1EJFi2ivgcjTpXqg6Kz2st91h4qyf7weLF -0.17732902 ec62fe6efdc749bf453fe5c1736d7cb514fe8c9c567de9f95a0a3bf04b5b01bc
I do not understand why they have the same transaction ID.
They are not "2 transactions"... it is only one transaction that has 2 outputs... ie. "the 0.1 for your friend and the 0.9 change"... or in this case... 0.00567098 for your Friend, and 0.17732902 change. My next question is why did my wallet let me send the below transaction? It was synced with the blockchain.
4/23/17 07:06 Unconfirmed. Sent to (no label) 177AnkPzv12EWThJEQq4iSDC3W5EZUtfPR -0.13400000
Below is what showed because of my very low trans action fee:
Status: 0/unconfirmed, in memory pool
Date: 4/23/17 07:06
To: 177AnkPzv12EWThJEQq4iSDC3W5EZUtfPR
Debit: -0.13399774 BTC
Transaction fee: -0.00000226 BTC
Net amount: -0.13400000 BTC
Transaction ID: c8effd35b1f05b0ff74bb1946df9adfcba685495e9bb5f243f72c0755e38f182
Transaction total size: 226 bytes
Output index: 1
I guess I am just out my coin, could some one explain what happened or what I did wrong.
That transaction is your wallet attempting to send funds to the 177Ank address, using the 0.17732902 BTC that went to your "change address" 1EJFi2ivgcjTpXqg6Kz2st91h4qyf7weLF from transactionID: ec62fe6efdc749bf453fe5c1736d7cb514fe8c9c567de9f95a0a3bf04b5b01bc From what you are showing, I am assuming you are using Bitcoin Core. By default I believe it allows spending of "unconfirmed" change. (Settings -> Options -> Wallet -> "Spend unconfirmed change"). So, even though ec62fe6efdc749bf453fe5c1736d7cb514fe8c9c567de9f95a0a3bf04b5b01bc was unconfirmed at the time (it is now confirmed), Bitcoin Core would allow you to spend the 0.17732902 change, to create the next transaction if required. FYI, It looks as though someone is re-broadcasting this low fee transaction (c8effd35b1f05b0ff74bb1946df9adfcba685495e9bb5f243f72c0755e38f182)... it is showing up on various blockexplorers again... possibly your wallet is rebroadcasting it?
|
|
|
That is relatively normal for all HD wallets. Address re-use is not recommended for privacy reasons. However, there is nothing stopping you from re-using old addresses if you want. If you look at the "Addresses" tab in Electrum, you can see all the addresses that the wallet has generated (used, unused and change addresses).
|
|
|
There is always a possibility that the seed has been compromised... the probability of it is likely to be relatively low, assuming you have taken all the necessary precautions against malware etc... It just depends on your personal level of paranoia, which is likely related to how much BTC you have stored using that seed From my experience, Electrum won't even let you reveal the seed once it has been imported ("Wallet" -> "Seed" is greyed out)... so my understanding is that the imported seed (if it is not an Electrum generated seed) is just used to calculate the master private key and then Electrum imports that (encrypting it in the wallet file, even if the wallet file itself is not encrypted).
|
|
|
Then yes... you want: https://iancoleman.github.io/bip39/ I have used that successfully for converting seeds to private keys... You may also want to look at the offline version of: https://www.bitaddress.org/ The github and zip links are at the bottom of the page, if you don't want to be typing private keys and passphrases into some random server
|
|
|
That isn't what I asked. Them locking your account for allegedly abusing faucets and multi-accounting is not what I'm concerned with. I want to see proof of this claim: yes. I catch scammer! He change hash seed after bet.. no history bets.. before bet and after bet , result is different I have not seen ANY proof that this site is somehow changing hashes after bets are placed to cause players to lose. You have claimed "fake seed" multiple times, but offered zero proof.
|
|
|
OK thanks so to bo more specific i want the bot to do
... wait 2 seconds ... wait 2 seconds ... wait 10 seconds ...
Firstly, why would you want the bot to wait around so much? Most people use the bot to try to increase the betting speed??!? something like this should run through your high/low steps... ( NOTE: this code has NOT been tested)... EDIT: Hah, didn't realise there was another page... so only just saw chilly2k's code, which is pretty much identical to what I came up with... The only real difference, being that my code has the profit check stop() included... great minds think alike I guess bethighArray = {true, true, false, false, true, true, true, false, false, false} stepCount = 1
bethigh = bethighArray[stepCount]
basebet = 0.00000001
nextbet = basebet chance = 49.5
startBalance = balance profitTarget = 0.001
function dobet()
runProfit = balance - startBalance
if (win) then stepCount = stepCount + 1 if stepCount > #bethighArray then -- check profit if runProfit > profitTarget then stop() else --reset stepCount = 1 end end nextbet = basebet bethigh = bethighArray[stepCount] else nextbet = previousbet * 2
end
end
|
|
|
Yeah he did 8 sats a byte on one of the payments. No wallet should do this.
If you have 20+ sats a byte you can use the transaction accelerator option from viabtc.com
but if you go under 20+ sats a byte nogo.
So all wallets should force you to pay 21 sats a byte or higher.
1. That is possibly the most ridiculous thing I have read today... "All wallets should use X fee so people can use a Third Party Acceleration service to attempt to prioritise their low fee transactions"??!? 2. You're wrong... the minimum required fee is 10 sats/byte: With the Transaction Accelerator for delayed transactions, users can submit any TXID that includes a minimum 0.0001BTC/KB fee to ViaBTC.
In any case, users should just take Danny's advice and use proper wallets that either set proper fees automagically... or let the users use proper fees... ... Use blockchain.info or a better wallet like xapo if you're interested in using online wallets as you can get an idea of what fee you should pay and xapo pays the fee on your behalf which is better.
Actually, I was wrong above... this is the most ridiculous things I have read today... For one, Xapo is a terrible service and is not a proper wallet... you have no access to your private keys... Also, if Xapo is paying the fee on your behalf, how can you get any idea of what fee you should pay?
|
|
|
p.s. why are we even talking about the size! the only thing that you need to know in (the user friendly) Electrum is how much to pay as fee per kilobyte. just set that amount and let Electrum decide the size and set the total fee for you. you don't need to worry about all that extra stuff His whole issue was questioning why Electrum was trying to use such a large fee in relation to the amount of BTC being transacted... Understanding why this is happening is very important. It will enable the OP to be more wary of accepting a lot of tiny dust sized payments and then wondering why Electrum is trying to use a 0.0017 fee to transfer 0.04 BTC... because fees are directly related to size. I think the issue with setting the BTC/kB fee and using the slider, is that if you get the slider in the wrong place you could potentially end up using a sat/byte fee that is 1/10 of what it should be! Personally, I think that if you are not just going to "use Dynamic Fees" (and people really should 99% of the time), then calculating the actual fee to be used and just entering that directly into the "manual fee" box, is probably safer than using the somewhat confusing "max static fee" in the preferences that is in BTC/kB and the slider... especially because all the recommended fees (from bitcoinfees.21.co and btc.com) are all shown as sats/byte... not BTC/kB. But, hey... that's just me... find what works for you and go with it
|
|
|
Using electrum 2.7.9.
I think that may be the reason why... I'm on 2.8.2... and I see this: Note: this value may not be the final size of your transaction... as if you change the fee, it might change the total amount of BTC that needs to be used and that may change the inputs that Electrum will use to construct the transaction... However, it is a good starting point to work from to get an idea of approximately how large your transaction is going to be so you can calculate your manual fee a little more accurately
|
|
|
It worked! I've got the full balance back Thanks HCP! And thanks HI_TEC99 for the walkthrough. Now I need to decide on a new wallet to replace MultibitHD. What do you guys suggest? Am I safe to just keep using Electrum? Yay! #greatSuccess! Glad we managed to help... Honestly, just use Electrum. Sure, it doesn't have the flashy "modern" GUI of MultibitHD, but it works, is actively developed, widely used... and has a lot of really useful features like Replace-By-Fee and Dynamic Fees that should help prevent (in most cases) transactions from getting "stuck". The one thing I will mention, is that if you didn't "sweep" your private keys into an Electrum HD wallet and you just imported them into a 'normal' Bitcoin wallet, then those coins are NOT backed up by a 12 word seed. You will need to retain all those private keys until such time as the coins are spent or you send them into an address in a HD wallet.
|
|
|
When you're setting it up, click the "preview" button... Electrum should show all the inputs it is going to use and also list the size in bytes of the transaction, that should allow you to make the correct fee calculations if you go the manual method.
|
|
|
Unfortunately no... they are not just providing SHA256 checksums of the downloads. The downloads have been signed using OpenPGP and you need to check the PGP Signature... On the download page is the "signature" file... ends in .asc and matches the download... https://download.electrum.org/2.8.2/electrum-2.8.2-setup.exe.ascPut the .asc file in the same place as the setup.exe If you installed that gpg4win app, you will need to load up the "Kleopatra" app, create yourself an OpenPGP keypair, then "Lookup Certificates on Server" and find ThomasV's certificate (search thomasv@electrum.org) and import the certificate with the fingerprint matching the link on the download page ( https://pgp.mit.edu/pks/lookup?op=vindex&search=0x2BD5824B7F9470E6)... Then you go "File -> Decrypt/Verify Files..." Select the .asc file and click Decrypt/Verify. After whirring away for a few seconds you should get a result saying that the file could not be completely verified... click show details and you should see something like: "Signed on 2017-03-22 06:42 by thomasv@electrum.org (Key ID: 0x7F9470E6)." That Key ID should match the end of the ThomasV fingerprint: 0x2BD5824B 7F9470E6And to answer your next question... no, I don't know why they used such a clunky overly complicated procedure to enable people to confirm file integrity... It would pretty much stop any "normal" user from even bothering to check.
|
|
|
The issue is that your transactions are in a chain of unconfirmed transactions starting here: 7375a6efb93190c7d806990dbc3823859d21d2dd9a6b59e31e65ec2a8d636948Until this transaction confirms, none of the following transactions can confirm. It was sent with a 50 sat/byte fee... which is currently about 1/3 to 1/4 of the recommended fees... You can try using the ViaBTC TX Accelerator and hope that they can push this transaction through (if/when they mine a block) which should help the others move along as well... or at least allow you to then submit the next transaction in the chain to the accelerator and so on until they're all confirmed
|
|
|
Can you preview the transaction and see how many inputs are being used to create it? I suspect you are using something like 10-15 inputs (faucet payments?) and the overall transaction size is like ~1500 bytes instead of the "normal" ~200 bytes... so a recommended fee of around 100-120 sats/byte ends up ballooning out to 0.0017 BTC. Your options are (in recommended order): 1. Suck it up and send the transaction with the recommended fee (you should double check what the fee is as a sats/byte value and compare with bitcoinfees.21.co and btc.com fee estimates. 2. Switch Electrum to manual fees and manually calculate what the fee should be, using your transaction data size and current recommended sats/byte fee values. 3. Switch Electrum to manual fees, manually calculate at least a 10sat/byte fee (based on your transaction data size), wait until the mempool is quite empty (like under 10K unconfirmed transactions) and then send your transaction. Once sent, submit your transaction to the ViaBTC TX Accelerator and start praying. If you have indeed been collecting a lot of dust sized payments from faucets etc... I suggest you see if you can get your payouts grouped into larger amounts like 0.001 minimum before receiving payment to help prevent this problem occurring again in the future.
|
|
|
You can't restart the bot once you call stop(), the only way for it to start up again is to enter start() in the console window like you do to initially start the script running... So, instead of issuing the stop() command, just track your profit amount, when it reaches the target you're happy with, use the invest() command and then reset back to initial script settings and continue NOTE: I'm not sure if this will work with any site... I've never used the invest() command, but there seems to be invest() code for just-dice in the dicebot code, so I'm assuming it works ... startBalance = balance runProfit = 0 profitTarget = 1.0 -- Set this to how much PROFIT you want to make before you invest, not the balance! ....
function dobet()
runProfit = balance - startBalance
if (win) then --do win stuff else -- do loss stuff end
if runProfit >= profitTarget then ching() alarm() print("Your Balance is " .. balance) print() print("TARGET ACHIEVED!!!") print() print("You Won " .. runProfit .. " for this Session") print()
print("Investing: " .. runProfit) invest(runProfit) -- invest winnings -- reset back to beginning and continue startBalance = balance runProfit = 0 chance = 90 bethigh = true nextbet = basebet
print(" ") end
end
|
|
|
|