Help test DICEonCRACK new feature - Get some free coins!

[nelisky]

Hi, I am back again, creating a TRC funding wallet this time.  Is there particular request or feature that you would like to have tested this time?  But please do note that given the minimum bet size, only a certain number of bets (around 10) can be tested before I go bust....  

As for the minimum bet size, you do realize it is 0.1 TRC generally, only poker is 10 TRC per hand, right?

Sorry, I was referring to LTC bets yesterday, which seems to have a min of 1 LTC per bet, thus I was not able to make many bet before going bust.  As for TRC poker, I was able to bet at 0.1 TRC per hand, as can be seen from your site under "Last Bet".  Sorry, I just notice that the TRC Poker does indeed have a min. bet of 10 TRC.  But please note that I was able to bet with 0.1 TRC per bet as per BTC pokers.  This can be seen from the "Last Bet" result on your site.

Please also note that I was not able to make bets with "less than 10", i.e. 1 or 2 or 5, those bets seems to be refunded right away, even when I change the exitpoint parameter to x100.  This applies to all strategy, simple, martingale, busto, elagnitram.  I did note that a few such bets did go thru as per your site under "Last Bet".  All the "Refunded" bets are with "less than 1 or 2 or 5".

You can, in fact, place bets on Poker for under the Bet Size, I kind of lead you the wrong path here. There's a minimum wager of 0.1 TRC and no bets below that will be processed, but what the Bet Size means for poker is how much each full hand costs. So when you play 0.1 you'll get the winning hand multipliers applied to that, plain and simple. If you had placed a bet of 1.5 TRC you would play 2 hands, one for 1 TRC (Bet Size) and 1 for the remainder balance, 0.5 in this case. 10 TRC would be 10 hands, etc.

Less Than 1, 2 and 5 are refunded due to the site's Win Cap, currently 1000 TRC. If you bet, for example, 0.1 TRC in a less than 5 game that pays 13041.664x, a single win would render you a prize of 1304.17 TRC, more than the site will pay out for any single bet. This takes precedence to Exit point, as otherwise you would get 1300 TRC of prize but only get paid 2x your deposit, or 0.2 TRC.

Thank you so much for all the testing! I'm addressing the other issue you posted about earlier now.

[SalvorHardin]

You can, in fact, place bets on Poker for under the Bet Size, I kind of lead you the wrong path here. There's a minimum wager of 0.1 TRC and no bets below that will be processed, but what the Bet Size means for poker is how much each full hand costs. So when you play 0.1 you'll get the winning hand multipliers applied to that, plain and simple. If you had placed a bet of 1.5 TRC you would play 2 hands, one for 1 TRC (Bet Size) and 1 for the remainder balance, 0.5 in this case. 10 TRC would be 10 hands, etc.

Less Than 1, 2 and 5 are refunded due to the site's Win Cap, currently 1000 TRC. If you bet, for example, 0.1 TRC in a less than 5 game that pays 13041.664x, a single win would render you a prize of 1304.17 TRC, more than the site will pay out for any single bet. This takes precedence to Exit point, as otherwise you would get 1300 TRC of prize but only get paid 2x your deposit, or 0.2 TRC.

Thank you so much for all the testing! I'm addressing the other issue you posted about earlier now.

Excellent, the explanation for the poker and cap limit is very clear.  However, this does mean that the ultra-low-odd bet (less than 10) for LTC and TRC would be refunded automatically at the current Win Cap.  I presume this would also apply to some of BTC bet options as well given the 25 BTC Win Cap. 

[nelisky]

Excellent, the explanation for the poker and cap limit is very clear.  However, this does mean that the ultra-low-odd bet (less than 10) for LTC and TRC would be refunded automatically at the current Win Cap.  I presume this would also apply to some of BTC bet options as well given the 25 BTC Win Cap. 

Indeed, although 25 BTC win cap would allow for placing a bet of up to 0.0019 BTC which is above the min bet. But Win Cap is not set in stone, it is just a product of demand and security. As the core gets more mature and interest raises we'll be glad to up the limits.

[SalvorHardin]

I did not test the "redeem" command yesterday for LTC bets, so I decide to try it on TRC today.  However, for about an hour now, the docbot keeps telling me "<docbot> Cannot redeem, waiting for transactions to be confirmed".  This is despite TRC blockchain adding more than a dozen confirmation in the mean time.  Of course, I can not check to see whether if some of hundreds of betting transaction are still trying to get 4 confirmation.  So this is just to let you know that I can not seem to redeem the remaining balance by command and the feature is untested (for someone doing hundreds of betting tx).  I will wait for the 8 hour automatic cutoff. 
 
Regarding the Win Cap, I did mention that some of "Less than 10" bet did go thru, despite the Win Cap of TRC 1000.  I believe that there are 6 of them, could be more, because they are not listed on the "Last Bet" page anymore.  But here are some of them, I am not sure whether it's because of strategy chosen, e.g. EXIT, but you can still see them on Last Bet page.


2013-03-03 13:08:17
db3f98ce 
083bd831
Martingale - [EXIT]
0.50001001
less than 1
0.002%
805 iteration
0.50001001
0.00044986

2013-03-03 13:08:17
b2c3077f
f33dafcd
Martingale - [EXIT]
0.50001002
less than 2
0.003%
568 iteration
0.50001002
0.00148189

2013-03-03 13:08:17
a9830ff6
5eab9dde
Martingale - [EXIT]
0.50001003
less than 5
0.008%
358 iteration
0.50001003
0.00271036

[nelisky]

I did not test the "redeem" command yesterday for LTC bets, so I decide to try it on TRC today.  However, for about an hour now, the docbot keeps telling me "<docbot> Cannot redeem, waiting for transactions to be confirmed".  This is despite TRC blockchain adding more than a dozen confirmation in the mean time.  Of course, I can not check to see whether if some of hundreds of betting transaction are still trying to get 4 confirmation.  So this is just to let you know that I can not seem to redeem the remaining balance by command and the feature is untested (for someone doing hundreds of betting tx).  I will wait for the 8 hour automatic cutoff. 
 
Regarding the Win Cap, I did mention that some of "Less than 10" bet did go thru, despite the Win Cap of TRC 1000.  I believe that there are 6 of them, could be more, because they are not listed on the "Last Bet" page anymore.  But here are some of them, I am not sure whether it's because of strategy chosen, e.g. EXIT, but you can still see them on Last Bet page.

If you look at http://cryptocoinexplorer.com:3750/address/1AiNAHGBdB6Mu4UVDWHcukKXacNy19avUy which is the address for the wallet you'll see that the last transaction there is on block 82355 which is the last block processed so far. Take this information with caution as the block explorer tends to lag behind significantly, but until the last transaction has 4 blocks on it you will not be able to redeem.

As for Win Cap, Simple pays based on the individual Bet Size, which is 0.1 for TRC, and Minefield pays based on the actual wager you place. So Win Cap is easily reached with those.

The Martingale based strategies, however, work in a completely different way. Each iteration places a bet that is high enough to add 0.1 TRC to the expected outcome at that iteration, so the most you can win at any point during the game is iteration x 0.1. What threshold changes is how much each bet is, so for less than 5 the bet would be (0.1 / multiplier) x iteration. You can read about Martingale on http://en.wikipedia.org/wiki/Martingale_(betting_system) and the difference between the multiple Martingale bet strategies we offer is explained on http://diceoncrack.com/howtoplay though if this is the first you hear about it things may be a little dense and hard to understand. If that's the case I'll be glad to explain using one of your bets as an example.

[SalvorHardin]

The link provided http://cryptocoinexplorer.com:3750/address/1AiNAHGBdB6Mu4UVDWHcukKXacNy19avUy is very interesting.  Even though my last bet is two hours ago, I can see that the address is still processing transaction from around 4 hours ago, when my balance is around 74 TRC.  It's only adding 1 to 4 transaction to each block (mostly just 1 tx,  occasionally sending itself the balance amount and then out again), so it may take maybe 200 blocks to go thru all the bets I made?  I am not sure what is really going on, but it's unlike what I have seen with the BTC's Blockchain.info or Satoshi Dice's address. 

[nelisky]

The link provided http://cryptocoinexplorer.com:3750/address/1AiNAHGBdB6Mu4UVDWHcukKXacNy19avUy is very interesting.  Even though my last bet is two hours ago, I can see that the address is still processing transaction from around 4 hours ago, when my balance is around 74 TRC.  It's only adding 1 to 4 transaction to each block (mostly just 1 tx,  occasionally sending itself the balance amount and then out again), so it may take maybe 200 blocks to go thru all the bets I made?  I am not sure what is really going on, but it's unlike what I have seen with the BTC's Blockchain.info or Satoshi Dice's address. 

Well, you know that TRC's network is very, very thin compared to BTC. Difficulty is currently ~570 where BTC is 4000000+. Why that means transactions are placed in block in such small batches I don't know, but you will just have to be patient, I guess. It is a very important detail going forward, though, thanks for reporting it. I'm trying to think of ways to prevent the problem from escalating.

[SalvorHardin]

Well, you know that TRC's network is very, very thin compared to BTC. Difficulty is currently ~570 where BTC is 4000000+. Why that means transactions are placed in block in such small batches I don't know, but you will just have to be patient, I guess. It is a very important detail going forward, though, thanks for reporting it. I'm trying to think of ways to prevent the problem from escalating.

So you mean that it's the miners who are withholding the transaction and processing them one per block at a time?  Because based on the last block found, tx ad303ee249... block 82371 2013-03-03 16:05:12  (69.87945897) 70.80530086 TRC, I still have well over 100+ betting tx awaiting inclusion into a block.  This means that I have to wait for around another 150 blocks for the all the remaining tx to be confirmed, which would take around another 7~8 hours at the current difficulty and network hash rate?   So with around 250 bets, it would take 12 hours to go thru all the tx and get confirmation for redemption?

Actually this raises another question, since the hash function dependings on tx id as input, how does docbot and your site determine whether transaction is valid without it showing up in the blockchain for hours and hours?  You make the hash function calculation as soon as the tx is broadcasted?  But does not this create a huge gap for double spending attack given the huge lag in blockchains?

As for the Martingale betting, it's actually quite different from what I expected.  I had thought that it's dividing bet into 0.1 TRC, and then go thru the Martingale sequence, until one goes bust, or win, at which time, the betting returns to 0.1 TRC, then run this iteration until reaching the profit target or bust.  But apparently, your strategy is fixing the winning at 0.1 TRC, then determine the bet size depending on the "less than" multiplier, then run the iteration until profit target reached or bust.  So as you mentioned, the max winning would be 0.1 TRC times number of iteration.  So rather than relying a lucky streak of rolls to reach the profit target, given a fixed 0.1 TRC bet, which would be faster at higher multiple (lower odd bet); with fixed 0.1 TRC winning, one has to survive enough iteration to get profit target = 0.1 TRC x number of wins.

[nelisky]

Well, you know that TRC's network is very, very thin compared to BTC. Difficulty is currently ~570 where BTC is 4000000+. Why that means transactions are placed in block in such small batches I don't know, but you will just have to be patient, I guess. It is a very important detail going forward, though, thanks for reporting it. I'm trying to think of ways to prevent the problem from escalating.

So you mean that it's the miners who are withholding the transaction and processing them one per block at a time?  Because based on the last block found, tx ad303ee249... block 82371 2013-03-03 16:05:12  (69.87945897) 70.80530086 TRC, I still have well over 100+ betting tx awaiting inclusion into a block.  This means that I have to wait for around another 150 blocks for the all the remaining tx to be confirmed, which would take around another 7~8 hours at the current difficulty and network hash rate?   So with around 250 bets, it would take 12 hours to go thru all the tx and get confirmation for redemption?

I wouldn't say they are withholding, it's probably just a propagation issue. But yes, it scales terribly right now.

Actually this raises another question, since the hash function dependings on tx id as input, how does docbot and your site determine whether transaction is valid without it showing up in the blockchain for hours and hours?  You make the hash function calculation as soon as the tx is broadcasted?  But does not this create a huge gap for double spending attack given the huge lag in blockchains?

The hash is on the TX itself, and does not change. So yes, as soon as it is broadcasted. There is a double spending problem, sure, we even suffered some loss recently for it (but have since closed that door) but that's exactly why you can't withdraw without ALL tx being in blocks.

As for the Martingale betting, it's actually quite different from what I expected.  I had thought that it's dividing bet into 0.1 TRC, and then go thru the Martingale sequence, until one goes bust, or win, at which time, the betting returns to 0.1 TRC, then run this iteration until reaching the profit target or bust.  But apparently, your strategy is fixing the winning at 0.1 TRC, then determine the bet size depending on the "less than" multiplier, then run the iteration until profit target reached or bust.  So as you mentioned, the max winning would be 0.1 TRC times number of iteration.  So rather than relying a lucky streak of rolls to reach the profit target, which would be easier at higher multiple (lower odd bet), one has to survive enough iteration to get profit target = 0.1 TRC x number of wins.

That is Martingale for you, with the basic premise that you have a target and every time you lose you adjust the bet to meet the target.

[SalvorHardin]

Well, you know that TRC's network is very, very thin compared to BTC. Difficulty is currently ~570 where BTC is 4000000+. Why that means transactions are placed in block in such small batches I don't know, but you will just have to be patient, I guess. It is a very important detail going forward, though, thanks for reporting it. I'm trying to think of ways to prevent the problem from escalating.

So you mean that it's the miners who are withholding the transaction and processing them one per block at a time?  Because based on the last block found, tx ad303ee249... block 82371 2013-03-03 16:05:12  (69.87945897) 70.80530086 TRC, I still have well over 100+ betting tx awaiting inclusion into a block.  This means that I have to wait for around another 150 blocks for the all the remaining tx to be confirmed, which would take around another 7~8 hours at the current difficulty and network hash rate?   So with around 250 bets, it would take 12 hours to go thru all the tx and get confirmation for redemption?

I wouldn't say they are withholding, it's probably just a propagation issue. But yes, it scales terribly right now.

Ok, so I can assume that it's not a problem from the docbot/IRC side.  Would I face the same delay when betting from the TRC client?  If you wish, I can try to test it from the TRC client tomorrow.  Though presumably the number of bets would need to be sufficiently large, and then see how long for the network to confirm all the bets.  I do not have access to TRC client now, but I can test it when I get to the office tomorrow.  Or would that not be making any difference and thus unnecessary?

[nelisky]

Ok, so I can assume that it's not a problem from the docbot/IRC side.  Would I face the same delay when betting from the TRC client?  If you wish, I can try to test it from the TRC client tomorrow.  Though presumably the number of bets would need to be sufficiently large, and then see how long for the network to confirm all the bets.  I do not have access to TRC client now, but I can test it when I get to the office tomorrow.  Or would that not be making any difference and thus unnecessary?

The bot is actually placing bets as you would with the client. The difference is bets placed that way are always trusted and thus immediately processed / paid. If you were to try to do the same thing with your TRC client eventually the system's heuristics would start delaying the payouts until transactions were included in blocks. I will gladly send you some TRC to try that if you feel so inclined, though, PM me your address.

[SalvorHardin]

The bot is actually placing bets as you would with the client. The difference is bets placed that way are always trusted and thus immediately processed / paid. If you were to try to do the same thing with your TRC client eventually the system's heuristics would start delaying the payouts until transactions were included in blocks. I will gladly send you some TRC to try that if you feel so inclined, though, PM me your address.

Actually, that's an important piece of information.  So betting through TRC client would be even worse than doing it thru IRC/docbot.  To run a sequence of 250 bets, I presume that with docbot, it would take around 2 hours, but waiting 12 hours for confirmation and withdrawal at current network scale and hash rate.  But with TRC client, after making a quick initial succession of bets, the betting would slow down drastically, as I would have to wait 3~5 minutes per bet, awaiting confirmation of bets (or previous bets) to be included into blockchain.  Thus it would take around 10 ~ 20 hours in front of client making bets, without the luxury of signing off and letting docbot handle the rest of withdrawal process.  Now that would be rather unpleasant.  Having to sit in front of BTC client awaiting confirmation of large (and nerve wracking) BTC bet with Satoshi Dice, which can take up to 75 to 90 minutes for confirmation, is bad enough.

Thus given the current state of TRC network, the best user experience would be to encourage them to bet thru the IRC/docbot, especially for the high-roller and high frequency gamblers, as the bet resolution is extremely fast, almost too fast, making the loss of money alarmingly fast.   Though it has to be made clear to clients that it's best to wait for automatic withdrawal to kick in, rather than trying to redeem via docbot command. 

As for testing from TRC client, unless you have specific issues that you wish to test, I think it's best to wait a while and think thru the current situation.  Undoubtedly you would want to think thru what we have learned here and take necessary measures to work with TRC network's limitation.  Once you have new ideas, I can try to test it again. 

Many thanks to you as I have learned a lot about the TRC network today.  I hope what we have discovered here is not the reason for the current large volumn sell-off in TRC at Vircurex exchange now.   

[SalvorHardin]

This is just an observation. 

Although bet resolution thru IRC/docbot is fast and is a workaround thru TRC network's limitation, I can see why the high-roller may have some reservation about using docbot over TRC client.  Since docbot processes the bet and generate the transaction, presumably it can also run the tx id thru the hash function first, knowing today's secret key, and only broadcast the tx id that result in a favorable outcome for the house.  Obviously, this would not be a problem if the high roller use the TRC client and broadcast its own tx id, which the house can only process, but not tamper with. 

[nelisky]

This is just an observation. 

Although bet resolution thru IRC/docbot is fast and is a workaround thru TRC network's limitation, I can see why the high-roller may have some reservation about using docbot over TRC client.  Since docbot processes the bet and generate the transaction, presumably it can also run the tx id thru the hash function first, knowing today's secret key, and only broadcast the tx id that result in a favorable outcome for the house.  Obviously, this would not be a problem if the high roller use the TRC client and broadcast its own tx id, which the house can only process, but not tamper with. 

This is actually a very fair point. However it is provable that no such tampering is happening as the choice of inputs is predictable, the older unspent transactions are used in order until the output value is satisfied, so it can't really be tampered with by the bot.

[SalvorHardin]

Hi, this is just an update on the situation.

13 hours after the last betting tx processed by the TRC network, the docbot still has not send the remaining balance to the returning address.  The betting sequence involves 280 tx, and took 270 blocks, or 10 hours and 20 minutes to be included into the TRC blockchain.  As mentioned yesterday, this means that only 1 betting tx is included per block, despite most of betting completed within 2 hours from the start.  So one should expect to spend 20 hours to play thru a 250 bets sequence, whether by docbot (2 hours betting, 10.5 hours confirming, and 8 hours for docbot auto redemption) or via client (assuming around 3~5 minutes for each bet to be confirmed after initial streams of bets). 

I am wondering whether if the LTC network suffer from the same problem, i.e. taking a long time for all bet to be included in blocks before one can redeem.  Naturally, due to the huge spike in LTC price today, the network hash rate is spiking from around 350~600 M hash/second to 1.2 G hash/second now!  So I presume that there is a lot more nodes for propogation and confirmation.  But do you have any experience regarding large scale LTC betting in short period of time?

[nelisky]

I have done both TRC and LTC betting in large quantities, but the redeem part was never part of those tests so no, I have no experience with the LTC counterpart of this. We're having issues with the processing server this morning, so that has my full attention right now, but I'll run some tests on LTC soon and will let you know.