Oh right, I see what you're saying, unless you were to wait for each transaction to confirm before sending the next one, you would end up with with a massive chain of unconfirmed transactions due to the change addresses from previous (unconfirmed) transactions being used in subsequent transactions. 

Whereas with "n" batches, you would end up with, at worst, "n" change addresses... and obviously no long chain, as you're likely to be sending maybe 2 or 3 transactions at most...

That is quite a substantial saving... and probably explains why a lot of my calculations have been out by a few bytes and satoshis here and there   Thanks Danny, as usual your knowledge on the finer points of Bitcoin mechanics is on point. Cheers for the updated information, I will need to check the wallets/addresses that I have so I can use the correct values in the future to make things a bit more accurate.

I had thought that batch payments would still require effectively (or near enough to) the same number of input and output scripts, resulting in similar amounts of data needed for the transaction. That is to say, instead of a lot of small (data size) transactions, you're sending one giant (data size) transaction, but the total bytes would be roughly the same.

I had forgotten to take into account the saving that can be made from the "fixed" 10 bytes in a transaction. Given that a transaction has a size that is "approximately" (and I know this isn't entirely accurate) [181bytes*Inputs + 34bytes*Outputs + 10 bytes], I guess the 10 byte saving per "batched" transaction will add up if you combine 100 transactions in one. That is an effective saving of 990 bytes... which at fees of ~150sats/byte starts to add up pretty quickly... around 0.15 BTC! 

Thanks for the effort to find the missing puzzle piece

I've modded the DuckDice.cs so that if twofa is not null, it will send it along as the "code" value in the StringContent. Otherwise, it just leaves it out and sends just the user/pass info as before. (ps. left the all important campaignhash untouched )

I've tested it with and without 2FA enabled... and tried to login with correct 2FA value, incorrect 2FA value and 2FA value blank and it seems to behave as expected (ie. successful logins with 2FA enabled and correct value, rejected logins in other cases... and with 2FA disabled on account, it rejects logins on all but blank 2FA value)

Finally, I think I've managed to successfully create a pull request on github... hope I did it right, I've never actually done it before   

Guessing that 2FA with DuckDice hasn't actually been implemented yet? I can't see the "twofa" variable being used in the login code in DuckDice.cs... and while debugging my compiled code I get the following in sEmitResponse after clicking Login:

Does their API actually support 2FA and, if so, what is the appropriate API field name so I can add it in? or is it unavailable/"classified" and will I need to disable 2FA on my DuckDice account to use the Bot on DuckDice?

No, you still have the just 4 options of "Low-Prio", "Economic", "Normal" and "Priority".

However it now seems to show the satoshi/byte rate and an approximate time which I don't recall seeing in previous versions. These are currently (20170408 2245 hrs UTC):

• "Low-Prio": >96sat/byte, ~3 hours
• "Economic": >109sat/byte, ~2 hours
• "Normal": >146sat/byte, ~30 minutes
• "Priority": >180sat/byte, ~10 minutes

I'll keep an eye on these and see if they update... They look roughly in line with what bitcoinfees.21.co would suggest... although btc.com seems to suggest only 40 sat/byte    Would make sense given the mempool count at the moment is less than 5000 unconfirmed transactions...

I suspect that your issues may be caused by the version of Electrum you're using on the phone...

I've just generated a new seed on my phone (Running version 2.8.2) and imported that seed into Electrum on my desktop (also version 2.8.2). The seed was accepted by the desktop version of Electrum as a "Standard Seed" and is showing exactly the same addresses.

I think you may need to update the version of Electrum on your phone, as it seems like your issue has already been corrected by a newer version of Electrum than you are using.

This is normal behaviour for most HD wallets. Address re-use is generally considered to be a "Bad Thing"™... To help with maintaining a level of pseudo-anonymity, you should use a different address for each transaction.

Your wallet will not have forgotten your previous addresses, it just adds new ones. They are all derived from the 12 seed words (Jaxx calls it the "Backup Phrase")... so make sure you have those 12 words written down and stored safely somewhere!

The sending speed of bitcoins is generally not related to the wallet you use, but is more dependent on how "busy" the bitcoin network is and the fees that you use.

- If you sent Transaction A with 150 satoshi/byte fee from MultibitHD and Transaction B with the same 150 satoshi/byte fee from Electrum at the same time, chances are they would both take the same number of blocks to be confirmed.
- If you sent Transaction A with 200 satoshi/byte fee from MultibitHD and Transaction B with 50 satoshi/byte fee from Electrum, you'd probably find Transaction A would confirm first.
- If you sent Transaction A with 50 satoshi/byte fee from MultibitHD and Transaction B with 200 satoshi/byte fee from Electrum, you'd probably find that Transaction B would confirm first.

The end result being, that it doesn't really matter which wallet you use, just use proper fees and your transactions will confirm quickly.

You should try not to use "exact amount" fees, unless you are sure you know what you're doing and have checked that the fee meets the appropriate satoshi/byte fee level that you want.

Remember, fees should be based on the data size of the transaction, not the amount of bitcoins being sent. If you send a transaction for 0.001 that uses say 10 dust inputs, it will be larger in terms of data size (and require a larger fee) than a transaction that sends 1 btc but uses only 1 input.

Is it absolutely necessary that you need to use bitcoins? Have you considered using an altcoin network to achieve your goal?

At the current time, the transaction fees on the BTC network are at the highest they have been. bitcoinfees.21.co is suggesting that the "best" fee at the moment is 200 satoshis/byte. This leads to a fee of 45,200 satoshis for the median transaction size of 226 bytes.  If you send 1000 transactions at that cost, you're going to be paying something like 0.4 btc just in fees!

If you are only sending small dust payments, your fees may far outweigh the amounts you are actually sending! 

Compare that with say, the DOGE network... You can send transactions with a 1 DOGE fee (currently worth ~30 satoshis)... although larger transactions will incur multiple doge fees, the difference in cost between DOGE and BTC is massive.  1000 transactions would only be 30,000 satoshis worth in fees...

Granted, if you did this, your end users would then have "altcoin" instead of BTC... but there are plenty of coin exchanges and services like shapeshift that will enable them to convert back to BTC if they want.

You forgot the "/thread"

A truly classic cartoon... and sadly very true. I appreciate that they are trying to make things "better" for everyone, but human nature being what it is, trying to settle on one common standard and/or platform is going to be a next to impossible task.

Still, if it would happen, I'd be happy... I just spent an entire day this week attempting to get one particular software wallet to accept the HD Seed generated by another software wallet... but for "security reasons" they decided to implement their own seed generation algorithm... To complicate things, the desktop version of the wallet had a nifty little "use BIP39 seed" option, so that worked OK, but the Mobile version did not... and there is no way to convert the seeds (or generate the seed from the xprv).

So my only remaining option would be to send all the coins from my current wallet to the new one and lose all my transaction history.

You cannot combine three scripts in that form. You can only have one chance, bethigh and nextbet value per roll... if you wanted to run those scripts at the same time, you would need to run 3 different copies of the bot at the same time.

The other option would be:

roll 1 - Script 1 values (chance = 1 etc)
roll 2 - Script 2 values (chance = 2 etc)
roll 3 - Script 3 values (chance = 3 etc)
roll 4 - Script 1 values (chance = 1 etc)
roll 5 - Script 2 values (chance = 2 etc)
roll 6 - Script 3 values (chance = 3 etc)
roll 7 - Script 1 values (chance = 1 etc)
and so on...

that would be something like:

Not bad... I avoided the first two games... and my Leicester win was a gimme... Was a little lucky that ManU squeaked the draw with the penalty in the final minute of injury time, but I'll take it... so 3/4 for the predictions and 2/2 for my actual bets...  

Swansea City v Tottenham - Spurs... they're in good form and want to chase down Chelsea.
Arsenal v West Ham - Going to go out on a limb here and go for BTTS.
Hull City v Middlesbrough - Avoid this one, they're both fighting to avoid relegation, it is probably a losing battle for both
Southampton v Crystal Palace - And avoid this one
Liverpool v Bournemouth - Liverpool should win this, but their record against low teams is a bit poor. Liverpool ML (or DNB if you're not 100% sure of the Liverpool win )
Chelsea v Man. City - Could go either way, but I think BTTS is a good option

woooo a full midweek round... I love it!

First four games tomorrow we have:

Watford v West Brom - Both pretty unpredictable... don't think winner/loser is a good option, maybe BTTS because they both leak goals? Will probably avoid betting on this one.
Burnley FC v Stoke City - Neither side seem very convincing at present... maybe under 2.5 if you can get decent odds on it. Will probably avoid as well.
Leicester City v Sunderland - Leicester in great form, Sunderland are just atrocious. Leicester should win this easy.
Man United v Everton - This should be the match of the day... Ibrahimovic is back. ManU need a win to stay with the Top 4. Everton are fiesty. I think BTTS is a good option here.

My suggestion is to stop looking at the Total fee value... and make sure you calculate the fee based on the actual transaction size. If you make sure you are calculating a decent satoshi per byte (or satoshi per kilobyte) value then you should have no problem getting the transaction to confirm.

To answer your original question... Electrum can work offline, is lightweight (so you wont need to download the whole blockhain) and I think it should be able to import Multibit seeds. By default it uses a dynamic fee, but if you go into the settings you can change it to manual to specify whatever fee you like. Having said that, the dynamic fee it will suggest will be based on transaction size, so should be "decent".

Sounds like you're trying to consolidate some "dust"... kudos for actually taking the time to try and get the fee right so it doesn't get stuck!  

One last tip, if you can wait and dont need the coins urgently moved, is to wait until the unconfirmed transaction count in the mempool is very low (at the time of writing it is only around 3000)... and send the transaction then

No idea who the owner is, but they appear have a solid 2600+ BTC in that address... making payments of between 0.1-0.9 BTC to multiple addresses.

For whatever reason, they have chosen not to create a multi-output transaction, (ie. 1 input -> Several Outputs) but have created individual transactions for each output (1 input -> 1 output excl. change).

Given that there a groups of payments with the same value, my best guess would be that they are some sort of coin exchange, and people just happen to be converting/buying the same value of BTC so they end up with the same amounts... ie. several people buying USD$300.00 worth of BTC, several buying $200.00 etc.

Or they could be an investment operator processing withdrawl or payment requests for a number of people who have the same number of shares or whatever, so they end up with the same payout amount...

Or it could just be a very rich person sending money to his friends and family... that is kind of the beauty of BTC... it helps hide a lot of the "who/what/why"

Username: HCP123

Just in case I forget to stock up... always handy to have at least 1 ticket... especially for the monthly wagering contest Lottos... much doges such fun!

I have to disagree... They may have 2 games in hand but their run to the end of the season is packed full of Top Half teams:

Southampton v Man Utd
Man Utd  v West Brom
Man Utd v Everton
Sunderland  v Man Utd
Man Utd  v Chelsea
Burnley  v Man Utd
Man City v Man Utd
Man Utd  v Swansea
Arsenal  v Man Utd
Spurs  v Man Utd
Man v Crystal Palace

compare that with Liverpool's remaining games:

Liverpool v Everton
Liverpool  v Bournemouth
Stoke  v Liverpool
West Brom v Liverpool
Liverpool v Crystal Palace
Watford v Liverpool
Liverpool v Southampton
West Ham v Liverpool
Liverpool v Middlesbrough

If Liverpool can beat Everton in this weekends Derby (and they should)... then their run to the end of the season is relatively easy compared with ManU who have to play all the Big teams (except Liverpool)... and they have to play Away to City, Arsenal and Spurs...

Granted, Liverpool haven't exactly been stellar against the lower teams this season, but I think the prize of Champions League football will give them the drive they need to push on to the end of the season and claim a Top 4 spot.

That is the "recommended" (or more correctly, most publicised) method of achieving what it is that you seem to be trying to do.

The transaction that you generate on the online machine, is really just a text file... no binaries or anything like that... so if you have a nice new USB stick and the only thing on it is the transaction text file, then you should be fine to move backwards and forwards.

If both the offline and online machines are setup with "autorun" (and all that sort of nonsense) disabled, the risk involved of plugging in a USB stick and copying a text file off and then back on are pretty minor. Even the Armory Offline setup involves moving (un)signed transactions back and forth via USB.

On the otherside, I think I can see your point of view. I assume you are copying your Offline private key(s) out by hand, and then manually entering them into your Online machine. That does indeed take away the possibility of an exploit using the USB stick attack vector. However, the extra work involved with doing all this manually, plus the fact that it means you are having to manually track all your inputs and outputs seems to be a lot of work for very little real gain in security.

I thought the solution was to create an unsigned transaction on your "Hot Wallet" machine... transfer it manually (ie. via usb) to the cold wallet machine... sign the transaction on the cold wallet machine... transfer the signed transaction back to the hot wallet and then broadcast it out onto the network.


I'm not sure why you would go to all the trouble of having cold storage in the first place, if you then expose your private keys to the world by importing them into your hot wallet machine? That sort of defeats the purpose of the cold wallet. Unless you intend on NEVER using that key/address again? 


By doing the transfer of just the transaction and signing it offline, you also get the bonus of not needing to full spend the contents of those keys each time you want to transfer some coins...

Given the Mycelium doesn't support BU as far as I can tell... in the event of a hard fork, you'd need to get a BU compatible wallet and import your keys there... all your shiny new BU coins should then show up and you can do with them what you want.

Unless of course the Mycelium team build in BU support in an upcoming update