The chance depends on how many addresses there are.


The ECD curve doesn't matter. We use 160 bit addresses, and that's the space we're looking for collisions in. If two different privkeys give the same address they can still spend each other's funds, since we pay to addresses, not to privkeys or pubkeys.

I decided to try out the non-deposit bonus thing.


I already had around 0.040 BTC from poker freerolls etc. and the bonus added 15.62xxx something to my balance. I played a little 'circle' and now it says:


Then I decided to try the live casino to see how that works. I click 'live dealers' then 'europe' but my bonus has disappeared and all I have left is my old poker winnings:



Does the bonus not work for 'live dealers'?  When I read about the bonus it told me I could clear the wagering requirements by playing "any of our games".

Is this of any use to anyone?


I think it's too small to be spendable, but would rather someone use it if they can.

I would call pevpot provably fair, because the only "trusted source" of randomness is coming from the guy who mines a particular block, and he *cannot know* the effect of his blockhash on the result of the lottery until an hour or two after he has committed to it.

The only problem here is that I am assuming that hardware doesn't exist that is capable of running a chain of a five billion pbkdf2 operations end to end in less than an hour.


Just use their order in the Bitcoin blockchain. No need for timestamps. Sort by block number first, and position within block second. Nobody can dispute that ordering. You can get the ordered list of transactions within a block:



It seems to me that it is OK to use an external source so long as that external source commits to its decision before it could know the effect of its decision. For example, at Just-Dice I could use random.org to pick the server seeds and it wouldn't matter because at the time of server seed selection I know neither the client seed nor how the player is going to play.


I don't think the first option is viable. Nobody will play a lottery where the operator can cheat undetectably.

The 2nd option is better, but if you can somehow make it that the external source can't cheat either, that would be best. That's what pevpot's 5 billion iterations is about - preventing the miner from knowing how his block affects the result.

Your chance of staking per unit time is proportional to the size of your stash, yes.

If you have 1000 CLAMs you will stake 1 CLAM about once per day on average.

If you have 0.01 CLAMs you will stake 1 CLAM about every 100,000 days (or 274 years) on average although you might get lucky and stake on your first day of trying.

Not really. People send these tiny transactions as a form of cheap advertising. Just scam the blockchain for the 10,000 most "interesting" addresses (most active, highest balance, most famous) and send them some dust from your vanity address. Personally it leaves me with a negative association ("factom == spammer") but I guess it must work, or they wouldn't keep doing it.

Either way, you can't assume a connection between factom and the thief just because because factom sent some dust to the same addresses that hold the stolen coins.


You don't put cold wallets online. Because they are cold.


That's because you can't see trust feedback if you aren't logged in. Presumably the search engine spiders don't log in when crawling the web.

I didn't use their wallet for a long time, but from what I remember you do something like:

1) import/export
2) unencrypted
3) look for the bit which says "priv"
4) go to the clam debug console, and "importprivkey XXX" where XXX is the "priv" part of the unencrypted export

I think you are missing the point. Proof and trust are incompatible. We prove the game is fair so that you don't have to trust anyone.

I can tell you that Pythagoras' Theorem is true and show you it stated in a trustworthy publication, or I can prove it to you. Once I have proved it to you, you know it is true even if you don't trust the publication that stated it. Proof removes the need for trust.


I would say that you have two holes in your proof. Either one of those two entities could be dishonest - you cannot prove that they aren't.


It's hard to follow. I think it could use some proofreading and possibly renumbering. What is a "lottery block" exactly?


I think you need to specify which version of mt_rand you're using. Its output changes depending on the version of PHP. Better would be to use something more standard so we don't have to install PHP to verify results.

It sounds as if we don't have to trust blockcypher.com at all, because the random beacon has the final say in who wins. In fact why do we even need to use blockcypher.com? What do we lose by simply using the random beacon at block_time + 10 minutes alone to pick the winning ticket? Hash the beacon, divide by 10, and the remainder is the winner. What does simplifying the draw to such an extent take away? I think your currently described system is entirely dependent on the government beacon to decide the winner, so why bother with all the extra complication? If the beacon site is cheating, they can make any ticket win under either system, and if they aren't then both systems are equally "fair".

Or did I miss something?

But an IRC backdoor would only work on online machines, not cold wallets. Are exchanges still not keeping the majority of their bitcoins offline?

Just how bad is the advice?

http://wizardofodds.com/games/video-poker/basics/#toc-PlayingStrategy lists three strategies for video poker:

 * Jacks or Better simple strategy (return of 99.46%)
 * Jacks or Better intermediate strategy (return of 99.52%)
 * Jacks or Better optimal strategy (return of 99.54%)

The optimal strategy is a list of 36 rules which would take considerable effort to memorise, for not much gain over the intermediate strategy, which is a list of 25 rules. And that doesn't give you much gain over the simple strategy, which is a relatively simple, mostly intuitive list of 16 rules.

So are we talking "worse than this simple strategy" bad?

Edit:


OK, so that is horrible advice. Even the simple strategy recommends holding 3 to a royal (rule 7). "Chase the gutshot" isn't even in the list:



I think it is reasonable to have the computer recommend simple strategy, which isn't perfect, but is close enough. But to have it give really bad advice doesn't seem acceptable.

The made a big fuss about introducing the freerolls, and were much quieter about cutting the payouts. I think that makes sense. Why make a big deal about what is effectively bad news for the players?

    "Hey guys, big news! We're cutting the payout on all the freerolls!!!"

It does feel a little rough that they cut the pot sizes just as people were qualifying to play in the bigger freerolls. It's a kind of bait and switch. I was playing lots to earn points to qualify for the bigger pots, and just as I reach them they vanish. But I was playing with free money, so would feel like a jerk complaining about it.

I've not played at FJ, but from what OP wrote, the "max bet" button actually places bets on all the bets which include the number you pick.

So he didn't just bet the maximum on number 1, he also bet the maximum on "1 and 4", and "1 and 2" and "1, 2, 3", and "1,4,7,...,34", and "1-6", etc. Maybe even on the red/black, hi/lo, odd/even that "1" is in, too.

No, but you can put:

    splitsize=10

in clam.conf in the same folder as your CLAM wallet.dat and it will only split to size 10 or more.

You need to restart for changes to that file to take effect.

Wow, talk about an over reaction!

OK, fine! Don't strip non 0-9A-Za-z characters from the address before attempting to validate it!

Just kidding.

Do you have any interest in me taking over the operation of the site from you? Or would you rather it just go away?

I'm a day late to this, but I received the same:



The link goes to hxxp://141.105.69.206/dn/?e=V2tjNWRsb3llREZqTUVKdVlsZEdjR0pETldwaU1qQTk=

It's a Russian IP address:


The link goes to a Windows executable which contains malware:



Someone scanned the same binary yesterday with virustotal, and only 2 antiviruses detected anything:



Repeating the scan today shows that many more antiviruses now recognise the malware, suggesting it's some new variant:



Edit: a betcoin customer helpfully posted a couple of links to articles about this on the site:


I wonder why there are no official warnings from the site on this thread.

Also, what happened? How did 'they' get everyone's account name and email address? Were funds stolen?

Sorry for the necro-post, but reddit is talking about this thread, and nobody in this thread seems to be close to the truth...


This is wrong. It fails to take into account the birthday problem.

When there are 10^10 addresses, there are roughly (10^20)/2 pairs of addresses.

Consider when there are 5 addresses, A through E.

To check for a collision, you need to compare AB, AC, AD, AE, BC, BD, BE, CD, CE, DE - that's 10 pairs of addresses (5*4)/2, or roughly (5^2)/2.

So your answer is off by a factor of roughly 5 billion.

Since there are 2^160 possible addresses, we need around 2^80 of them to have a 50% chance of a collision.

http://diyhpl.us/~bryan/papers2/bitcoin/bitcoin-birthday.pdf does a better job of approximation, but comes up with a similar answer.


No. You can say that the odds of being hit by lightning are 16,540,000,000,000,000,000,000,000 times higher than of finding a collision, but your statement isn't true.

A simpler example that we can picture more easily than all those zeroes:

 * I have a 1 in 2 chance of coin coming up tails.
 * I have a 1 in 20 chance of rolling a 6 on a 20 sided die.
 * so tossing "tails" is 10 times more likely than rolling a 6.

From this, using your logic, I am just as likely to toss "tails" 10 times in a row as I am to roll a 6.

But we can see that this isn't true. Tossing "tails" 10 times in a row is a 1 in 1024 event. Rolling a 6 is still only 1 in 20.

No. I'm not sure how you got this wrong.

1. Make an address:



2. Fill in form:



3. Submit form, get deposit address:



I'm guessing you copy/pasted the private key from bitaddress instead of the Bitcoin address? Or you didn't copy the whole address?

Actually, I just tried using "15EbrqLqRttTHW2wsebCuRd7ojgCeL9uH3 " (with a space on the end) and got "Got validation error: Invalid value for win_address". So maybe that's what you did wrong. Don't copy/paste any extra spaces around the address.

Ryan: you should strip non 0-9A-Za-z characters from the address before attempting to validate it.

tl;dr: waaah, this free money you are giving us is unacceptable

I'm surprised how much they're giving away to be honest. It must be costing them a small fortune.

It's tricky getting people to switch poker sites, and even trickier to get them to risk their own money once they've come for the freebies. It will be interesting to see how much action there is at betcoin.tm once the free money dries up.

I don't know if you've seen this thread before, but the longest losing streak at 49.5% on Just-Dice back when we accepted Bitcoin was 32:

  https://bitcointalk.org/index.php?topic=610339.msg7060900#msg7060900

Interestingly, the 2nd longest was 5 bets shorter, at 27.

I would be interested to know if anyone has ever seen a longer losing streak at 49.5% than 32 in a row.

Roughly speaking, the odds against 10 in a row is one in a thousand, 20 in a row is one in a million, and 30 in a row is one in a billion.

So that 32 in a row is a one in four billion shot. The losing streak ended with bet number 594,791,171 and that counter includes all bets, not just those at 49.5%.

Edit: here's a screenshot of the 27-streak:

I don't think this is as easy as you think it is to get right. I'll respond further when you post the algorithm, below.


I don't think it's possible using Bitcoin. Maybe using an Ethereum smart contact you could do something like this, where the contract takes care of paying out the winner and only the winner. As I understand it, if you have access to the bitcoins to send them to the winner, you also have access to the bitcoins to send them to yourself, or to someone who blackmails you, etc.


pevpot.com is a +EV BTC lottery. The site pays out more in prizes than it takes from players. The difference comes from sponsors who advertise on the site.

"EV" means "expected value" by the way.

You should really take a look at the pevpot thread since it is a great example of how to make a provably fair lottery, and the thread is a decent example of how to work with the forum community to improve the site.

Ultimately, however, we are left having to trust RHavar to pay out the correct winner each week, and not to steal the coins for himself. But at least we can be confident that the winner was fairly selected - we can verify the result for ourselves, and know that nobody was able to manipulate the result. (Well, everyone is able to manipulate the result, but it takes so long to calculate the effect of each manipulation that by the time your calculation finishes it is too late).


The idea is that players will flock to the site to play the +EV game, which will make the site attractive for advertisers, who will fund the +EV-ness of the site. I'm not sure how well it's working out, since I'm pretty much the only sponsor, and that's mostly only because I was given 1 BTC by the guy who won the first draw, and asked to use it to sponsor future draws.


If the aim is to make it impossible for you to cheat by buying tickets, why are there any secrets?

If knowing the secret seeds would help a player cheat then knowing them would also help you cheat.

And if knowing the secret seeds would not help a player cheat then they don't need to be secret.

I didn't look much deeper into your algorithm, but I see you are using timestamps, which is usually problematic. Who decides the time at which a ticket was purchased. Transactions don't have timestamps, and different peers on the Bitcoin network will see transactions at different times. Are we going to take blockchain.info's word for when they first saw the transaction? If so, that's a point of trust. Or are we using the timestamp of the block containing the transaction? Then we're relying on the miner of that block. When there's 5000 BTC at stake it might be worth discarding a few 25 BTC blocks if their timestamp means we lose the raffle. And so on... But the 'secret' thing stands out as a bigger concern first.