I really like the idea of a bitcoin lottery and I played yesterday. As of right now I will not play again. Why?
YOUR SITE SUCKS.
For a for-profit business to have no way to ask a question and no contact link is just not acceptable. I know you want to sit on your ass and collect money, but in the real world people have questions and if you have customers you have to answer those questions. It is called "customer service", and it is important.
The funny thing is I got a payment out of the bet, but there is no way for me to see the "ticket" that your site "produced".
Topic: BitMillions.com- More than ฿ 1,400 in Prizes - Play with only ฿ 0.01! - page 8. (Read 21646 times)
February 15, 2013, 12:51:26 AM
February 15, 2013, 12:25:30 AM
Have you considered making it easier to use free plays? Right now it seems frustratingly difficult because you have to spend ฿0.10 just to use one free play, giving you 11 bets, which on average will win you close to two free plays, so you'll get more free plays faster than you can use up the ones you already have!
February 13, 2013, 10:09:37 PM
So if I try to send a 0-day-old Satoshi by itself, the current rules dictate it would take 456,621 years to finally be confirmed!
Kind of, but not really, for two reasons:
1) If any output of a transaction is less than 0.01 BTC then it isn't allowed to be free, no matter what the priority. This is to prevent 'dust spam'.
2) Even transactions which don't have enough fees will be confirmed within a few days because there are some miners who don't enforce the fee rules.
February 13, 2013, 05:39:27 PM
It seems as though packaging these smaller inputs with larger inputs allows them to be sent fee-free. If you ever want to consolidate a small amount at a single address, send a larger amount to that address, then send them both back to the address you wanted to consolidate the small amount at. Use the larger amount as a vehicle to transport the smaller amount, for free. 
That's right. A transaction is free so long as it's less than 10,000 bytes and the average (input age) times (input size) is more than about 0.6 bitcoin days. (The code tries to make the threshold 1 bitcoin-day, but allows 250 bytes per input, whereas since most public keys these days are compressed they only take up 148 bytes each in a transaction, causing transactions to be roughly 60% of the size the code expects).
So if you're trying to consolidate 66 single satoshis (the most you can fit into a 10k transaction), you'll need to bring an input with 67*0.6 =40.2 bitcoin days along with it (since the individual satoshis contribute effectively nothing to the transaction's priority no matter how old they are, being so small). That can be a 1 day old 40.2 BTC input, or a 1 hour old 1000 BTC input, or any other combination which gives at least 40.2 bitcoin days.
The transaction you linked to included a 13 BTC input that was over a month old, so it alone contributed more than enough bitcoin days for the whole transaction.
So if I try to send a 0-day-old Satoshi by itself, the current rules dictate it would take 456,621 years to finally be confirmed!
February 13, 2013, 05:04:57 PM
It seems as though packaging these smaller inputs with larger inputs allows them to be sent fee-free. If you ever want to consolidate a small amount at a single address, send a larger amount to that address, then send them both back to the address you wanted to consolidate the small amount at. Use the larger amount as a vehicle to transport the smaller amount, for free.
That's right. A transaction is free so long as it's less than 10,000 bytes and the average (input age) times (input size) is more than about 0.6 bitcoin days. (The code tries to make the threshold 1 bitcoin-day, but allows 250 bytes per input, whereas since most public keys these days are compressed they only take up 148 bytes each in a transaction, causing transactions to be roughly 60% of the size the code expects).
So if you're trying to consolidate 66 single satoshis (the most you can fit into a 10k transaction), you'll need to bring an input with 67*0.6 =40.2 bitcoin days along with it (since the individual satoshis contribute effectively nothing to the transaction's priority no matter how old they are, being so small). That can be a 1 day old 40.2 BTC input, or a 1 hour old 1000 BTC input, or any other combination which gives at least 40.2 bitcoin days.
The transaction you linked to included a 13 BTC input that was over a month old, so it alone contributed more than enough bitcoin days for the whole transaction.
February 13, 2013, 03:04:24 PM
Love the site, very well done. Only one thing I'm a bit confused over: Is there a reason you decided to have the tickets pay out for each play? The current method is going to end up filling wallets with a lot of small inputs, making it harder to spend without long delays and/or high fees. Perhaps a separate address to purchase a ticket which sends your total winnings after the ticket fully matures? This saves you money, and the player as well in the long run.
I had the same concern, but look at how nicely the small transactions (all the way down to 0.000003!) were sent without a fee in this transaction: https://blockchain.info/tx/0895a6fa923d399f5079c5a444a70a7543b5c34ebe4a5d21ae522350042b311e?show_adv=trueIt seems as though packaging these smaller inputs with larger inputs allows them to be sent fee-free. If you ever want to consolidate a small amount at a single address, send a larger amount to that address, then send them both back to the address you wanted to consolidate the small amount at. Use the larger amount as a vehicle to transport the smaller amount, for free.
February 13, 2013, 02:41:05 PM
Jaques, unfortunately bbit is a scammer, he applied for our beta tester launch promo and when we sent him the 1 FREE BTC to play, he kept it for himself, refused to play or to return the BTC.
1. First he sign up to participate in the beta testing
2. Before we sent the BTC to try the system, he claimed to be a winner and confirmed to have received the prize
3. After we sent him the BTC, he claim that thought it was a FREE BTC GIVE AWAY, refused to use the BTC to play and to give it back.
Read https://bitcointalksearch.org/topic/looking-for-100-beta-testers-to-try-bitmillionscom-get-1-to-play-for-free-140349 for more information.
Is sad to see people like that in the community.
1. First he sign up to participate in the beta testing
I'll help!
1HYPdQXk3bURyXoznRseCp7XRd1FcHnPmy
1HYPdQXk3bURyXoznRseCp7XRd1FcHnPmy
2. Before we sent the BTC to try the system, he claimed to be a winner and confirmed to have received the prize
I won 8 BTC it works!
3. After we sent him the BTC, he claim that thought it was a FREE BTC GIVE AWAY, refused to use the BTC to play and to give it back.
Read https://bitcointalksearch.org/topic/looking-for-100-beta-testers-to-try-bitmillionscom-get-1-to-play-for-free-140349 for more information.
Is sad to see people like that in the community.
February 13, 2013, 02:14:18 PM
why not?
February 12, 2013, 02:22:35 AM
For security createrawtransaction is not accesible from the application layer, so I can not re-create the transaction to adjust fees.
You're able to run createrawtransaction from somewhere. Can't you call it repeatedly there with different fees until it's right?
I guess I could change a few things to do that... I will try to calculate it by the number of inputs & outputs first... if that doesn't work I guess I will have to go that way.
Thanks!
February 12, 2013, 12:43:52 AM
For security createrawtransaction is not accesible from the application layer, so I can not re-create the transaction to adjust fees.
You're able to run createrawtransaction from somewhere. Can't you call it repeatedly there with different fees until it's right?
February 11, 2013, 11:51:26 PM
I can't believe it, for some reason I missed the part that I needed... thanks!
Your transaction has 100 inputs and 1 output, so will have size 14800+34+10 +- 100 = 14844 +- 100
Thanks!
But... createrawtransaction returns a string. Count the length of the string to find (twice) the size of the transaction. Then adjust the fee, and repeat, until the fee is suitable for the length.
For security createrawtransaction is not accesible from the application layer, so I can not re-create the transaction to adjust fees.
February 11, 2013, 11:41:58 PM
I tried to find documentation on this, but what able to do so... thanks for the info!
Could you please tell me where can I find it on the bitcoin.it wiki?
Could you please tell me where can I find it on the bitcoin.it wiki?
https://en.bitcoin.it/wiki/Transaction_fees
The problem I have is that I don't know the Transaction Size at an application level, I just know the number of inputs & outputs, and I need to determine the TxFee based on that... any recommendations?
[Edit] I custom build the transactions with createrawtransaction method on bitcoind at another layer of the application stack.
[Edit] I custom build the transactions with createrawtransaction method on bitcoind at another layer of the application stack.
http://bitcoin.stackexchange.com/questions/1195/how-to-calculate-transaction-size-before-sending
transaction with 'in' inputs and 'out' outputs has size
(in*148 + out*34 + 10) plus or minus 'in'
so long as you're using compressed public keys.
Your transaction has 100 inputs and 1 output, so will have size 14800+34+10 +- 100 = 14844 +- 100
Its actual size was 14846.
Each input adds 147, 148, or 149 to the size, pretty much at random. The average contribution per input is 148 bytes. It's incredibly unlikely that all 100 inputs will contribure 149 bytes. The transaction size is in the range 14744 to 14944, but spread out with a binomial distribution centred on 14844.
But... createrawtransaction returns a string. Count the length of the string to find (twice) the size of the transaction. Then adjust the fee, and repeat, until the fee is suitable for the length.
February 11, 2013, 09:50:57 PM
The rules for transaction fees are well known:
I tried to find documentation on this, but what able to do so... thanks for the info!
Could you please tell me where can I find it on the bitcoin.it wiki?
Note that transactions up to 10,000 bytes can be free (depending on the size and age of the inputs), but over that there's a minimum fee of 0.0055 BTC (0.0005 BTC per 1000 bytes or part thereof), so it might be worth breaking your transactions up into a series of smaller ones.
The problem I have is that I don't know the Transaction Size at an application level, I just know the number of inputs & outputs, and I need to determine the TxFee based on that... any recommendations?
[Edit] I custom build the transactions with createrawtransaction method on bitcoind at another layer of the application stack.
February 11, 2013, 09:21:30 PM
But looks like didn't have enough txFees and we still waiting for this transaction to get confirmed:
http://blockchain.info/tx/71d791a4666bdad7b484f07f9299840b99a524e98823c3b6761137592df8cd00
We made it almost 6 hours ago and still doesn't confirm.
http://blockchain.info/tx/71d791a4666bdad7b484f07f9299840b99a524e98823c3b6761137592df8cd00
We made it almost 6 hours ago and still doesn't confirm.
The rules for transaction fees are well known:
Note that transactions up to 10,000 bytes can be free (depending on the size and age of the inputs), but over that there's a minimum fee of 0.0055 BTC (0.0005 BTC per 1000 bytes or part thereof), so it might be worth breaking your transactions up into a series of smaller ones.
The transaction you sent is 14846 bytes long, and so needs a fee of at least 15*0.0005 = 0.0075 BTC. You only included a fee of 0.001 BTC so it's not surprising it's taking a long time to confirm. What client did you use to make that transaction? It seems not to be following the network rules for fee size.
February 11, 2013, 08:25:41 PM
No problem, Thanks for the update! BitMillions for life!
February 11, 2013, 08:22:29 PM
Still waiting for the BTC from this win...
https://bitmillions.com/tickets/2e7e4725fc9ac4819afecd89e1a78657fcf5d293b3e5c37b2ab9bf4f92cdd3e0:0
Any ETA?
https://bitmillions.com/tickets/2e7e4725fc9ac4819afecd89e1a78657fcf5d293b3e5c37b2ab9bf4f92cdd3e0:0
Any ETA?
Since we couldn't send a transaction with 750 inputs, we needed to consolidate all the inputs to been able to send your payment.
Please check on: http://blockchain.info/address/1ETya2BCpwgTuz88ubiLPf2kUvMpUymhBq
But looks like didn't have enough txFees and we still waiting for this transaction to get confirmed:
http://blockchain.info/tx/71d791a4666bdad7b484f07f9299840b99a524e98823c3b6761137592df8cd00
We made it almost 6 hours ago and still doesn't confirm.
All the other transactions are already confirmed, so as soon as that transaction confirms, I will be able to process your payment.
Also we will have the Pool # 3 in Hot Storage, that will prevent this problem from happen again.
Please apologies for the delay, as soon as we have the consolidated funds confirmed, we will issue the payment and post it here.
[EDIT] Payment Sent! Sorry for the delay... it should not happen again.
http://blockchain.info/tx/f7263295b490656ca7b6345cabb0ae9a423058557d952dcc929d90cc9415bfc3
February 11, 2013, 05:25:00 AM
I played a bitcoin, wish me luck? 
https://bitmillions.com/tickets/2149699da87f0b36196e2571264aba845c9af13e821109bbf7e8950465bf0e0c:0
https://bitmillions.com/tickets/2149699da87f0b36196e2571264aba845c9af13e821109bbf7e8950465bf0e0c:0
February 10, 2013, 08:43:24 PM
Thanks for point it out this Dooglus, but note that since the price reduction, the high roller bonuses we ajusted to:
I guess the problem with the cache still make you see something different.
Yes, I removed the A in CAL to make it fit, it suppose to be something temporal, but I never got to change it... I will change it after fixing the pre-compile cache issue.
Also is import to note that you get 10 FREE PLAYS when playing anything higher than 1 BTC, I think makes much more sense to play 1 BTC and you will get 111 plays ( 18 1/2 Hours of Playing! )
I guess the problem with the cache still make you see something different.
Also, the most recent draw numbers are all messed up. Is it meant to say 'CALCULATE'? It's kinda ugly:
Maybe an 8 letter word would work better? TH-IN-KI-NG? Or just write the word without breaking it into 4 parts.
Maybe an 8 letter word would work better? TH-IN-KI-NG? Or just write the word without breaking it into 4 parts.
Yes, I removed the A in CAL to make it fit, it suppose to be something temporal, but I never got to change it... I will change it after fixing the pre-compile cache issue.
Also is import to note that you get 10 FREE PLAYS when playing anything higher than 1 BTC, I think makes much more sense to play 1 BTC and you will get 111 plays ( 18 1/2 Hours of Playing! )
February 10, 2013, 02:41:01 PM
Good point, I hadn't thought of the idea of buying a single ticket that lasted for a significant time.
They actively encourage you to do so with their 'high roller' bonuses:
Incidentally, the 'play for' column is wrong in a few cases. 20,000 tickets will play for 20000/144 = 138.9 days, not 143 days.
Also, the most recent draw numbers are all messed up. Is it meant to say 'CALCULATE'? It's kinda ugly:
Maybe an 8 letter word would work better? TH-IN-KI-NG? Or just write the word without breaking it into 4 parts.
Jump to: