Just a note to let you know that I've generated a new pull request. My previous fix for the chart reset only fixed the "Exception" being generated, but then I noticed that the chart scale wasn't resetting correctly until you reached 1000 bets and it did the recalculations.

So, if you were using DOGEs and betting like 1000 per roll with appropriate Y Scale... and then switched to BTC and were betting 0.00001000, the scale would be stuck at the DOGE values for Y Min and Max and your BTC bets would just look like a flat line for 1000 rolls

I did some research and it appears that by setting the YAxis min and max back to "NaN" (which is their default value on chart creation), the Auto-scaling kicks in and everything works as one would expect

That is because if you try to send the whole 0.0011, the wallet will need to include other UTXO's to cover the fee... and as your other UTXOs are small, it needs to include a lot of them to be able to do that. That is why I suggested trying to just send 0.00100000.  That way, you have 10000 satoshi's to use as a fee... but I suppose even that wouldn't work, you'd need to send like 0.0009 or something.

Anyway, it looks like you managed to send it all... 44996bc2b9235fc374649c2f6b596547f8bf8e3c1073ef5fb68f8249a50809f5

as predicted, this transaction with all the dust UTXOs was HUGE by btc standards... Size: 3766 bytes... but you managed to get away with a 77 sat/byte fee... so it "only" cost: 0.00291648 BTC 


I hope you (and others following this thread) have learned a valuable (and expensive) lesson... try not to accumulate dust, it'll end up costing you more to move than it is worth... especially if fees keep going up!

The LN was designed for exactly this reason... to move micro payments offchain.


Do the math... at best case his 24 inputs will only require 148bytes (if they all use compressed key addresses)... 24 inputs * 148 bytes + 34 bytes output + 10 bytes = 3596 bytes....even using btc.com's estimate of only 75 sats/byte... that still equates to 269700 satoshis (0.00269700). bitcoinfees.21.co is saying 180... which would make it 647280 sats (0.00647280)....


It isn't insanely high... you are trying to take up 0.3% of a whole 1M block for your one transaction... it is almost 15x the data size of a "normal" transaction (3596 bytes vs 226 bytes). Fees are based on data size of transaction, NOT bitcoin value.

STOP collecting dust... or accept that you are going to end up paying a large chunk of your faucet payments to move that money around.

For the record, there are only around 10K unconfirmed transactions in the mempool... if you want to gamble and try and transfer using a fixed fee, now is probably your best time (or even wait until it drops even lower, like under 5K)...

If your wallet (Jaxx?) doesn't support manual fees, then export your BIP39 seed, import it into Electrum, use manual fee and put in something like 50000 satoshis to make sure you hit the 10satoshis/byte minimum, mark it RBF (Replace By Fee), send it all in one go and then use the ViaBTC TX Accelerator to try and push your transaction through.

Username: HCP123

also, yay for allowing 2FA via the bot

That all depends on how much of the total balance you want to spend.

If you only want to spend 0.001, then you should be able to use just 1 input and 1 output (as your largest UTXO is 0.011)... and you'll end up with a transaction around 200bytes and can probably pay "just" 30000 sats fee (~150 sats/byte)...

However, if you are wanting to send all of it... well that is 24 inputs and 1 output...

worse case (Uncompressed key addresses) is: ((24*180) + (1*34) + 10) = 4388 bytes
best case (compressed key addresses) is:  ((24*148) + (1*34) + 10)) = 3596 bytes

Using the ((Inputs * 180 bytes) + (outputs * 34 bytes) + 10 bytes) formula for a guess at transaction size... Either way, with current recommended fees being well over 100 sats/byte, you're going to be looking at something like 500,000 sats (0.005) to send your 0.01 with "recommended" fees... yes, ~HALF of your balance as a fee.

Your other option is to wait until the mempool count is really low, like at least under 10,000 unconfirmed transactions... stick in a fee of at least 10sats/byte and try using ViaBTCs TX accelerator... and then just wait and hope.

In the meantime, I suggest you stop collecting dust... it is only going to make things worse for you... see if the people sending you these amounts can collect them into a minimum payout amount of like 0.001 or higher.

I think the OP might be misunderstanding what a change address actually is...

Using change addresses doesn't mean that after you receive BTC's to AddressA that you can then send them from AddressB. If you think about it, the blockchain has no knowledge of AddressB getting coins, so how are you supposed to send from it?

As mocacinno explained, a change address is where the "unused" portion of an output is sent if you don't use the whole thing when spending it.

Bitcoin requires that you spend the WHOLE output at once. You can't just use part of it like with a normal fiat bank account.

Think of it like breaking up a chunk of gold. You got a chunk of gold (AddressA) that is 0.0002. But you want to give 0.0001424 to someone (AddressB)... so you break that chunk off and you end up with a small chunk (0.0000576) left. That small chunk has to go somewhere, so you use a change address (AddressC) and put it there.

If you're trying to mask your money movements and transactions, you might want to investigate either a. Monero or b. Bitcoin "mixers".

Well, if they could fix the malleability issues (aka. get SegWit implemented) then we could have the Lightning Network, which would allow "offchain" transactions... where you transfer coins from your "Offchain" account directly to someone elses "Offchain" account... 3rd party hubs track and validate all the transactions... and settlement occurs when you withdraw/deposit into an actual bitcoin wallet and the transactions end up in the blockchain.

A bit like how if use a coin exchange like Poloniex... when you buy/sell coins, you're just moving stuff around accounts on Poloniex's servers... it doesn't create blockchain transactions until you withdraw/deposit.

It can only be replaced while it still has ZERO confirmations... as soon as the transaction has at least one confirmation, it can no longer (realistically) be modified using "RBF"... so it isn't like a Merchant will suddenly stop accepting transactions from you if you use RBF. It just means you'll need to wait until at least 1 confirmation for them to provide whatever service/product you're trying to purchase. Which is what most merchants do now anyway.

Personally, I like their so-called "strict" rules in the chat... at least there I can have intelligent conversation with other gamblers and talk about life, the universe and purple unicorns... unlike 99% of other sites where it is just a constant streaming wall of "lol", 's and "missed the rain"/"no rain" messages that make it impossible to actually chat with people.

Also, they don't insta-mute people who show up and say "Hi"... they will inform them that single word messages are not allowed and refer them to the Chat Rules... Most users get the hint and go and read the rules and abide by them... others think they can do as they please and ignore the rules. They get muted for a short period of time, not even banned. If the continue to ignore the rules after multiple warnings they'll eventually get permanently muted. This doesn't even block your account, it only stops you from participating in the chat.

To actually have your account blocked you need to be violating the Terms Of Service...

For the record, I got warned about 3 or 4 times in my first two days on the site And I'm still there 9 months later...

I am fairly certain that blockchain.info wallet uses an HD system that generates new addresses each time an address receives funds... https://support.blockchain.com/hc/en-us/articles/210353663-Why-is-my-bitcoin-address-changing-

OP, you might want to check your transaction history in blockchain.info wallet to see what address you actually "received" the funds to... also, you can find all your addresses here:

Settings -> Addresses -> Click 'Manage' next to "My Bitcoin Wallet/Default" -> Click 'Show' next to "Used Addresses" -> Click 'OK' on the warning dialog.


Anyway... the real lesson here is to stay away from Ponzi schemes (and other High Yield Investment Programs aka HYIPs) in the future 

If it looks too good to be true, it probably is... 

The fees look "Ok"... not huge, but not like 10sats/byte or anything... I think the real problem is that your transaction is at the end of a MASSIVE chain of unconfirmed transactions (in reverse order):

edeef69cb97942d490e2961a54f689d55392d1d5a0606f25fa6abce26f662c80
63b8c6d817491014ebc0d93a613938953c9268fe879aa4df0080b208c33c8d7b
9bc76be2f3fd59ad1ce0c979f25e29bc66cf1c9b6e312ed73ddabd30af1121ea
574078779b3fe1864e59d1ee523ea2fecdfda731c22815f66dc9643106a88f19
24c6590c9e0ecda4e540b93289ceb3be2340b08eeead1034356755b6f213e48c
b8eff59bf1420ea5f1e942ccc8a42e2d4077e59c83cd132ce4b3df65cdf95f0d
ab4c0708075a4ffea3d7412a91559cdaf28299b687c94ec354cbf157d62ba2e5
6db892685c8a37f070fb66075b6326a426422cb221cd4b6070db6f5898faa19d
d0893ce9a454e54c2b5bc91969dbb945ecd084310230ad5128320e37964d431b
cacf8172ad1ed7f335a08cd83e37c458d31c8474cd2dab741e6f1d81e6cac17c
c5479691cfb69563d57e85ecf80589ff0d903b4898ebc2940107dbe236a5ec1e
b6834fe82bf72fbcf2b548ce22dd6576568e9d3a3313fe110227f071c5f9f167
6216e06f75201ed3f873043ae6ba1fa641090e7abaf665229de6095bba346c08
efbbd9fc3cad1f4f939c9e75d11bd112d88807cd58f443c9c2faaa73801f165b
4f6d62bf361b598372c540be4e72ad757e2a0c494ec60bb781fa75be8cdbf804
dfcca2299409609fc2d876ecd116312b65e376f88586625a0fe0a8118323b2df
1928e17f2bd27c6e93e14a3fe6c6a96925a6fdd2ada9d0d42a106cff6a1c9c88
f5b83958410052849af7a02b0e904fa4b1d59fc2597ccc05c1377e89fe892971
e3003a2c0a7fcb076cbb7334b0a1d8f68e7ffbaa89f582e07fba593c5372efb6
cde6fd475130b8b7f1f7d92f05af2eb107656de30fc48e4bbc08b3183cc53a70
607a3a3a557fa0d25b4eca42c857c714a543841f51b25af15089d9057c11cd6e
f0eefc04730d9a762f28c42d03213132f453a840accd5e4d74acf4fc83f293c1
58ab206a5d4babf677368e16a906a099620836a5bd43c3c5d877bf03e395da83
faa839b2614d8ac437a897ee5a2a5f3c61dcba9dc55b02a130764e4c5ff93f0f
5f31b3c2b3f6f97932f2e4ed8575e4ec87f85f954b1e90271104e0cd4f5b1cfe
fa77ab7911df34a8fb131e09bc7a6c6551e8e4630ba7f49528dc3aae55a23b46 - 1 Confirmation

If you can't be bothered counting, your transaction is #25... So, until all of those other 24 transactions get confirmed... your transaction will be waiting

And bitsler are technically correct, they can't do anything NOW... however, they could avoid all this by trying to batch their transactions and use "Pay To Many" instead of sending them one at a time in a big long chain like this...

Mind you, if they did that, people would moan that withdrawls took too long or claim they were scam because their withdraw didn't process "instantly"

You've never working in software development have you? Most of the time, the customer doesn't even know what they actually need (or want)...

Personally, I don't think that we need fancy sliding bars with pretty colours... the 4 options they currently have (Priority, Normal, Economic and Low-Prio) combined with a 5th "Manual" option (probably best to be hidden by default and only enabled via advanced settings) would be my idea of the a "good" solution.

It would allow those who want to "Keep it simple" to do that... and for those that want more control to be able to specify their own level of fee/risk. Everybody wins.

Electrum already has "Replace By Fee" implemented... and I'm fairly sure that I have seen it in action once or twice... but I've never used it myself. Granted, it doesn't actually work "instantly"... and isn't even guaranteed to work at all... but is better than having your transaction sit around for days.

Your other option is "Child Pays For Parent"... basically you use the output of the first unconfirmed transaction in a second transaction with a MASSIVE fee (big enough to pay for both the first and second transactions) and the miners will include both to claim the "prize"

It isn't really the wallet trying to put it as a high priority. It is because there are multiple dust transactions included that push the transaction data size up (in MrCash02's case to 962 bytes, a "standard" transaction is around 226 bytes). As fees are determined on a satoshi per byte basis. The more bytes you have (ie. the more space in a block your transaction takes) the more you will pay in fees.

This is why a transaction for 100 BTC that has 1 input and 1 output can be sent with a fee of only 0.0005 BTC (~160 sat/byte at 226 bytes) and confirm fairly quickly. But a transaction for only 0.01 BTC that has like 10 inputs (ie. a bunch of faucet dust) and 1 output will need a fee of around 0.0016 BTC (~160sat/byte at 1024 bytes) to confirm in the same timeframe.

People need to realise it is NOT the "value" of the transaction that determines the fee required... it is the "data size" (ie. how many inputs and outputs)

Actually... that does strike me as being a bit of a flawed system... It would appear that they are manipulating the server_seed hash they give to you before a roll and this actually prevents them from being able to prove that they haven't modified the server_seed. All you get is a "random_seed" that was supposedly hashed with the "server_seed" to give the server_seed hash.

Note: I am NOT claiming this is what Rollin does, but what could potentially happen with a setup like this...

What's to stop someone from just pre-generating a couple of different server_seed+random_seed combinations that make the same hashes... Now, a player gets a big "win", and then the casino could just search through their list of server+random seed combinations until they find the one where the server_seed makes that roll a loss... Then, they could just post the loss result, say here is the server_seed that was used... and we can "prove" it because it matches up with the server_seed_hash... provided you add in this "random" number that we just picked out of nowhere but didn't give you up front?

I'm sure the math involved in the hashing functions probably makes the likelihood of hash collisions for server+random seed combinations very very very small... but then, why even use the random_seed in the first place? The chances of someone brute_forcing the server_seed from just the hash are supposed to be just as tiny, aren't they?

Once it is confirmed (especially once it is over the 5-6 confirmations) nothing is going to change that transaction in the blockchain... that is the whole point of the blockchain.  The warning is really for people who are happy to accept zero-confirmation transactions and provide goods and/or services without waiting for at least 1 confirmation.

If the transaction is marked as RBF and IF it still has zero-confirmations, there is a possibility that the person who sent it could then resend the transaction with a higher fee, sending the money back to themselves (or someone else) and hope that a miner includes that transaction in a mined block first.

On the plus side, "RBF" is a useful way for people to be able to help shift stuck transactions... if they had used a stupid low fee of like 10sats/byte and it was stuck in the mempool... they could effectively redo the transaction with a 160sats/byte fee to try and help it get confirmed.

The idea being, if a transaction is RBF and not from a trusted source, DON'T trust it until gets at least 1 confirmation.

Your transaction to your exchange is probably just unconfirmed because the network is crazy busy right now... loads of unconfirmed transactions. I doubt it has anything to do with the RBF transaction. I hope you used a decent fee for your transfer to the exchange.  

Then that is "User Error" and you cannot blame the developers. Much like you can't blame gun manufacturers for people shooting other people "accidentally".

At some point, people need to accept responsibility for their own actions and mistakes.

The way I see it, if someone has a manual fee box, and they specify 1 satoshi/byte and then ignore a warning message that it is a low fee and could take a long time to confirm and go ahead and click "send" then they have no right to complain about long confirmation times and deserve 0.00 units of sympathy.

However, as a relatively intelligent person, I don't see why I should have to have my choices limited because the developers are aiming at the Lowest Common Denominator. Give me advanced options and let me accept responsibility for watching the mempool and waiting until there are less than 3000 unconfirmed transactions before sending my 10 satoshi/byte fee transactions

Using language like "normal", "quick" and "super quick" is a "Bad Idea"™. As that would be setting user expectations without being able to guarantee you could actually deliver. Even the use of "Low-Prio" and "Priority" is a bit iffy as there are no guarantees with BTC.

If you use the "Super Quick" value... and then 30,000 transactions get dumped onto the network that all have double your fee... how "Super Quick" do you think your transaction is actually going to be? Then you will have all the users who don't understand BTC and the blockchain properly, moaning that your wallet is too slow and X wallet is much faster.

And if you think I'm being unrealistic, check out the historical mempool count... There are massive spikes all the time.

Honestly, I think the best solution is just provide "advanced" settings, that would let the user specify. Electrum on the desktop lets you do it... if you want, otherwise you can just use dynamic and it will try and calculate the "best" fee according to their algorithm. The Electrum Android client lets you specify the fees in the settings, but has a minimum of 0.0003 BTC/kB (~ 30 sats/byte) and a max of 0.0003 BTC/kB (300 sats/byte) going in 0.0003 increments (or you just use the Dynamic option, which I believe takes fee estimates from the Electrum server)

Mycelium could easily just incorporate a "fifth" option on the fee level button that says "Manual" and enable a textinput box that would let you just enter an amount. Maybe throw up a toast message warning if it is below what it considers to be "normal".

I've been looking at the code on github, and would give it a shot, but I don't have access to an Android build environment to try it

you realise that at current prices, USD$1 equates to a little over 0.0008 or 80,000 satoshis...  given the current recommended fee of 160sats/byte, that would equate to a transaction size of around 500 bytes... it would only need maybe 3 inputs to get a transaction size close to that...

Have you considered what happens when you start buying a bunch of everyday things with bitcoin? a coffee here, burger and fries there, a beer at the pub, your groceries... you're going to be generating an awful lot of change addresses and a lot of (possibly) dust amounts in these change addresses that will be spent at some point...

Besides, even if fees were "only" 40c/transaction...  last month i had something like 80 transactions during the month...  for those 80, my fiat bank charged $0... maybe you'd be happy with a $30/month transaction bill, but i know which one makes more economic sense.

The future of Bitcoin is not going to be buying coffee with your phone... not unless off-chain transactions become prevalent... which isn't really buying things with Bitcoin on your phone.

except that Apple Pay doesn't cost you $1 every time you use it and doesn't take 10+ minutes (or possibly hours) for your payment to process.... what merchant is going to let you walk out of a shop with $20 worth of goods hoping the payment will go through sometime in the next hour or so?

On the other hand, Apple Pay is also centralised and doesn't provide even pseudo anonymity.

Bitcoin is fast moving away from being a viable solution for every day payments toward being useful only as a method of storing wealth. It is likely to get even further away in the future as block rewards get halved and transaction fees increase even more.

The days of shifting bitcoins around for pennies are long gone... unless you want to wait.

well... you could just set a "risk" factor variable. I've done that before...


assuming I am understanding the strategy correctly... ie. it is more risky to only reset on break even/profit... plus you could theoretically specify even more risk levels like 4 or 5 and play very conservative... although I suspect that you'll just end up digging yourself deeper if you accept multiple 4 unit losses and you hit a bad run?

You could probably track which betting level you are at and only do a riskLevel check when you're betting the six-lines or higher as well...


Note: there are lot's of gaps in my pseudocode here... but you should get the idea... I could probably code a proper script if I could find some spare time

Of course, you can always receive into an address. They dont stop existing after you've used them once

Have you tried entering the old address into a block explorer to see what transactions currently exist for it on the blockchain?  If the coins show there, but not in Jaxx... It could just be that Jaxx isn't syncing all the transactions properly (seems to be a common issue, lots of threads about people needing to "Reset the Jaxx Cache" under Settings, sometimes multiple times to get their coins to display correctly in the wallet).

If the transactions don't show on the block explorer, then they don't exist and nothing you do in Jaxx will fix that.