Quote from: ZoomRaffle on May 20, 2018, 06:39:18 AM

Quote from: sjyi on May 19, 2018, 03:07:15 AM

Quote from: ZoomRaffle on May 17, 2018, 08:10:21 PM

Quote from: sjyi on May 17, 2018, 04:37:46 AM

Quote from: ZoomRaffle on May 16, 2018, 08:28:47 PM

Quote from: sjyi on May 16, 2018, 05:39:11 AM

Quote from: ZoomRaffle on May 15, 2018, 04:40:53 PM

Quote from: sjyi on May 15, 2018, 02:35:29 AM

Some observations based on my taking a chance on your raffle.

Prior to me entering the raffle, all winning chances were either 50% or higher.

0x61Ec39942476D93C475f91ACA2fAE062d64B250c placed a bet for 0.01 eth 4 days ago on May-10-2018 10:57:44 AM +UTC

I placed a bet for 0.012 eth on May-14-2018 06:01:01 PM +UTC

The raffle drawing took place on 3:07PM. (counting down of 5:00 minutes to 0:00).

There was a dialog box that said "raffle drawing in process. please wait" (something similar to that. I didn't write it down).

After waiting for about 10 minutes of waiting with nothing happening, I walked away.

I came back a few hours later. I saw "You won 0.022 ETH" dialog on left bottom of my screen. When I clicked on it, it disappeared. When I checked my address I saw that no deposit came in.

what happened?

Weve also refunded your bet to your Ethereum address due to the mistake in our web interface.

https://etherscan.io/tx/0x59e002a4e38c74ac9f648ac60c3ce93ba428f27d16bfcde7d7763b416f119b60

Thanks for the refund. Just wondering why you process Odd games differently from Even games. The code segments seem to be identical from Odd and Even game index.

Hello, the reason for that is that we don't want to overpay Oraclize. Here is the deal basically: at the end of the raffle we would clean up all the bets, jackpot and other variables. In EVM (Ethereum Virtual Machine) every time you use delete opcode (which is equivalent to setting a storage to 0) you get refunded 10,000 gas. Because Oraclize callback was doing the cleanup we were losing a lot of refunded gas to Oraclize.

Now we have a different system: we clean up the previous game on the beginning of the next game (first bet of the next game), in order to differentiate between "next" and "previous" game we just decided to separate them into odd and even. So at the start of the odd game the first bet also cleans up the previous even game and vice versa. The result is that our players get a nice gas refund which reduces the transaction price for placing a bet by roughly 50%.

Thanks and hope that this architectural decision on our side makes sense to you.

Your explanation seems to make a lot of sense regarding the refund of gas. But please do refer to "When paying onchain there is no reliable backward-compatible way for Oraclize to give back the gas "change". This is due to how Ethereum works: it is not possible to determine the exact amount of gas that will be used before the transaction gets confirmed, because it depends on the current state. Sending back the unspent gas afterwards would potentially create side effects."

from https://docs.oraclize.it/#pricing-advanced-datasources-call-fee

Are they talking about the samething?

Yes, in a sense. Basically what they are saying is that all the extra gas will not be refunded to us, so in order to minimize costs we need to approximate the gas costs as accurately as possible.

I'm not clear with your explanation vs. what Oraclize is talking about. Oraclize is talking about returning the unused "change" which can't be returned. So setting the correct gas amount would be the best way to "save" on the fee. But you are talking about actual "refund" with a hard number of 10,000 gas. Yet, I could not find any mentions of refund. Would you point out where the refund is discussed?

Alright, I didn't do a really good job at explaining it. Let me try to elaborate a little bit. Let's say we have a contract function that is called determineWinner (just like in our contract). Let's say that this function costs 200,000 gas to execute, but at some point the function clears storage, in other words sets variables to 0. Clearing storage operation costs NEGATIVE gas on Ethereum network: -10,000 gas. So let's say tour transaction is estimated to take 200,000 gas but you clear three storage variables (the number is arbitrary). Then the transaction will execute and only consume 170,000 of gas because 30,000 will get refunded to you for clearing space on the blockchain. See this.

Even though the transaction in the example above only uses 170,000 of GAS, 200,000 of GAS still need to be supplied. The reason for this is because the refund is issued only at the end of a successfully executed transaction. Why does it work this way - because ethereum was designed this way. See this for more details.

"After the message call or contract creation is processed,
the refund counter has to be incremented for the accounts
that were self-destructed throughout its invocation"

"Then the state is finalised by determining the amount
to be refunded, g∗ from the remaining gas, g0, plus some
allowance from the refund counter, to the sender at the
original rate."

By looking at equations 64 and 65 we get a better idea about the order of things:

1) You post a transaction with a gas limit 200,000
2) Transaction gets executed and consumes exactly 200,000 gas
3) But because you freed three elements refund counter now has 30,000 gas
4) You get refunded that gas.

On etherscan it would look the following way:

Gas Limit: 200000
Gas Used By Txn: 170000

Now going back to why this matters in this project. Oraclize initiates our winner determination logic, so all of the refunded gas for clearing the state of the CURRENT game goes to Oraclize. Now if we do not clear the state of the current game in determineWinner and do it later then we do not lose all the refund coming from clearing the state of the game.

In order to achieve that we clear oddGame when evenGame begins and we clear evenGame when oddGame begins. So when the winner is determined, all the bets and jackpot are still hanging in contract storage memory - we do not clear them. But as soon as the new game starts we do and we do it ourselves instead of making Oraclize do it. The result is that we can put a lower gas limit on a call to oraclize.

In fact, after playing with it for a while and not using the on chain ledger proof (potentially unsafe, but proof wastes a lot of gas by doing the freeing of storage), our engineers were able to cut down the oraclize gas cost to 88,000-90,000 units and still preserve the dynamics of the game. For comparison, every dapp on the network uses 3-4 times of that ~ 250,000 of gas.

It is very important for a gambling project because the Oraclize fees have to be eithered paid out of a house pocket (we pay) or player's pocket (you pay). If we pay, then it forces us to have very high minimum bet (like some of the existing competitors), if you pay then it reduces the expected win value on low bets. In any way reducing the gas price for securely generating a random number on blockchain is one of the main areas of development for that area. Sharding and RANDAO are some of the solutions with the most potential at this moment.

Thank you for the detailed information and references. I really do appreciate that. The finer points in this thread would only be observed and addressed with attentive analysis of the application domain. Well done sir! (if I had any merits to give out, this post would certainly receive it.)