Think I may need to make some more adjustments at this level before going higher.  I noticed that those large wins take quite a while for it to generate the payout transactions, think I either need to adjust the coin selection algorithm or get the wallet access there threaded better so it doesn't hold up everything else quite so much when generating large payouts if it's going to happen often.

Since the game has now handled over 11,000 bets and seems to be running fairly stable I have bumped the max bet limit up to 50 TRC.

Identicons for bitcoin addresses have been discussed before:

https://bitcointalk.org/index.php?topic=122240.0

In short it works fairly well as an extra checksum but it has much less entropy than the full address so matching the first few address characters and the icon is not that hard.  It depends on your use case how useful it really is, it can help with easily identifying mistyping of addresses (but so can the built-in checksum), but doesn't necessarily prevent spoofing one address with another similar one.

I suppose I should try and take the effort to rebase it off a current vanitygen.  Was kind of hoping to get more familiar with github at some point and do it as a proper branch/pull request for vanitygen but it never really happened and I guess no one else picked it up and ran with it either.

The oclvanitygen I'm currently using checks both the uncompressed and the positive and negative compressed versions of each key it computes.  Since the majority of the processing time is getting the keys to check this results in about 3x the addresses checked for the same amount of processing power.  At some point a while back I posted the .cl file I was using in the vanitygen thread but I never did completely modify oclvanitygen to do the rest of the calculations properly, I just run it in verbose mode with hardware error checking disabled and use a helper script to pull out the proper keys.

Those GPU numbers were measured at the original clockrate (725 core, 1000 mem) although usually I run it slightly underclocked for efficiency.  I generally point it at one of the vanity pools (vanitypool.thruhere.net which accepts compressed solutions or vanitypool.appspot.com which doesn't but sometimes has more work) when there is work that is worth more than bitcoin mining.

You don't necessarily need the whole pool software to do it manually, just need to pass a base public key into oclvanitygen (at least I think that works with the current version, mine is somewhat modified currently)


Each extra character makes it take ~58 times longer to find.  I'm getting ~100MK/s with a somewhat modified oclvanitygen and a 5970, been pushing extra keys that it spits out that I'm not really looking for into my keypool, makes following transactions more interesting to read    http://www.cryptocoinexplorer.com:3750/tx/408371594efb4b9ab448a622eb7e4a423a2daf919de31743da689fa591594906

You might want to look into split vanity address generation so that any buyers you find can be sure that you don't know/can't share the private key for the address you generate.


Also might want to rethink or add a disclaimer on that 15 character length, getting >10 characters for a specific name is not fast.  I've been waiting about a week now on a set of trcDice addresses and that's only matching 8 characters (granted the bounty on them is low enough that I may be the only one working on mining them)

Not sure I see why it would make any difference.  The number can be chosen so the odds are exactly equal with a "more than" or a "less than" bet.  Since the lucky hash creation includes the output number it's not like any bets even in the same transaction will share a hash (thus allowing betting in a given range).  At a first glance it just seems like it would make the calculation/verification more complicated without really adding any value.  Is there some other reason for the request or is it just cosmetic?

Yeah, found another small problem, those payouts are on their way.  Coin selector was running short on inputs that passed the double-spend protection rules and gave up, I've adjusted it to keep retrying in that particular case now so there might be a little delay but not more than a couple minutes.  Will also get better as the change transaction sizes even out and it has more to work with, right now the wallet is the main bottleneck in payout speeds that can't be threaded well without more coins for the coin selector.

Yeah, it won't have a page for any affiliate address until it's finished processing the first bet through it, just to avoid cluttering up the server too much with addresses that don't get used.

Ah, that's a good point as well, that sort of statistics is something else that affiliates can use to add value to their own particular play addresses beyond just look/marketing.  Generally I would prefer to concentrate on keeping things running smoothly and leave the marketing to the affiliate system for affiliates to earn their share.  I do like the way that page is looking so far, perhaps for now I'll stick with just basic information that can't be calculated otherwise on the output pages and if you come up with something that can't be figured out with the existing data given I can see about adding it to the output across the board.

Stats as in aggregate stats like the Satoshi Dice thread in the technical section here or more a list like on the Satoshi Dice site itself?  The recent bets would be the list it shows now, I could add lists for recent big/rare wins fairly easily.  I suppose aggregate stats wouldn't be too hard either, the only thing I would worry about there would be if/how to include affiliate addresses.

Yes it will, but more slowly on that one than on most since the winning payout is that much bigger.

Is the key it doesn't like in hex format or a wallet format?  I've tested more extensively with the hex format, I know it's somewhat picky about it being the right length and needs to be padded with 0s if it's short.

Sorry all, it does appear my local terracoind added me to its ban list.  I'm adjusting its parameters and restarting it, should get payouts moving again shortly.

If you take a look at the details page for any of the bets you can see how the outcome is calculated.  The bets from yesterday (like http://greenishblue.info/terradice/8b94569a6e5d2d94d8e4b81e791445b8db6e6ecfb3f92596f70d5a834a685660-1.html) will have the secret revealed so that the outcome can be verified while ones from today will just have {secret} displayed until the day is over and it moves on to the next secret in the list.

Note that while writing this I attempted to verify that bet and found there is an extra newline in the middle of the hash that makes it somewhat more difficult to calculate/check.  I have adjusted that so it will be a single line in future bets, but when checking older ones you will have to insert a newline between the secret and the ":" to get the same hash.  This doesn't affect the randomness, just makes it somewhat harder to verify the fairness of the results.

Well if the tx was accepted by the pool in the first place it would have to be running some custom software.  I assume it would try and relay it normally but it would only be accepted by peers that were following the same relaxed rules as itself.  I have played with nonstandard transactions in the past sending them through Eligius to get mined and it does seem that though they are accepted and eventually end up in a block that I do not see them get propagated very far elsewhere on the network before being mined.  I assume that it would work fairly similarly for transactions with fees below minimum.

It uses the same method as Satoshi Dice to determine the payout address, so as long as the transaction(s) that are being used in the bet payment come from an address in the wallet it should work.  If it's a group wallet though it is possible (or even likely) that payouts will end up somewhere else.  I don't see any missing payouts right now, you can track them in the block explorer and see where the payout ended up, it always includes the bet transaction as part of it (to protect against double-spends).  It also supports sending to another address similar to Satoshi Dice, if you include a payment of exactly 0.0054321 to another address in the same transaction as the bet any winnings will be sent to that address as well.

Any payments to 1H95NEPFHYHmehBCqpoF2QY7ytmBEsZXMz will go directly into the game and bump up the max bet amounts (which are based on available funds), for now I have it capped at 20 TRC but it seems to be running happily so far.

Unfortunately I don't have a bugfix for bad luck...

I just added TRC to the LiteDice list, you can find TerraDice at http://greenishblue.info/terradice and make your own affiliate with the same rules as the LiteDice ones at https://litedice.greenishblue.info.  I am still doing some testing, the maximum bets will stay fairly low until it has gotten some more testing volume through it but it should be stable enough to try out and play with in small amounts.  The play addresses will probably be replaced with more standard ones once they finish generating (although the current set is kind of fun) but these ones will continue to payout (at least for a while) even if they disappear from the list.  Any problems with lost payments just drop me a PM (so as to not completely hijack this thread).