Quote from: etheraffle on May 24, 2018, 09:45:00 PM

Quote from: sjyi on May 24, 2018, 04:43:20 AM

Dev:

Came across this article regarding Solidity. https://medium.com/@Hibryda/why-solidity-isnt-solid-3341af77fc1c

This is not about etheraffle, but about Ethereum's Solidity. Was wondering about this statement from the whitepaper "Provably Fair Everything occurs in the public domain." I know this is not my first encounter of "provably." There are other projects with such a claim. But with etheraffle having completed so much work, I thought you maybe in a better position to answer this question. Have you carried out proving the fairness of etheraffle? Is the "provability" based on analysis of theorem prover or based on the fact that all the transactions are recorded on the blockchain?

I know this question may go beyond the scope of this project, but it may be directly related due to the fact this project is based on Ethereum.

Thanks for your time and info.

Hi Sjyi!

With regards to provability, ours comes from the fact that the entire of the raffle functionality takes place on chain. This, in addition to the transactions also being etched in to the chain where our fairness comes from. Not only can you see how our random numbers are generated (by lightning no less!) but also how they are stored, how a users numbers are compared to the winning numbers, and how in the event of a win the prizes are calculated using the actual odds which are baked into the smart-contract. You can literally read the code that's running on chain and see what it's doing. We are hiding nothing.

Better still, because of the recursion in the smart-contract, you can see that none of the above requires any any human involvement at all. All the other blockchain lotteries out there obfuscate these processes, and or require a person (and so a centralized, single source of failure) to make happen. We do not. It's all laid out there, in the contract, for anyone to go and look at.

Thanks for your explanation. The fairness of Etheraffle can be "proved" by recordings of all operational aspects through the public ledger. And also due to "no touch" flow fairness can be maintained.

Quote from: etheraffle on May 24, 2018, 09:45:00 PM

Quote from: sjyi on May 23, 2018, 03:14:18 AM

I know setting up the development/test environment could take an effort, but if you're willing to take on remote test, I'm willing. I'm starting to work with truffle.

Very interesting! How familiar are you with Solidity development?

As it happens, we don't use the Truffle/Ganache frameworks due to the large overhead. The current contract re-write that the update hinted at earlier is now in a far more functional programming style (which strictness lends itself to blockchain security). And so because much of the contract has now been converted to "pure" or "view" functions they are much simpler to unit test directly in Solidity itself (or in Go when automating). Those functions remaining that do have side affects (mainly pertaining to Oraclize) are also simpler to unit test directly in Oraclize's forked Remix compiler.

Good to know that truffle/ganache frameworks come with a large overhead. I have extensive system design/develop/testing/implement experiences but am new to Solidity. As I have brought up many developers progressively regardless of their self proclaimed ability/knowledge, I also apply that to myself. Assign a simple task and progressively assign more demanding tasks with each successful assignment completion.

As I witnessed this project to be well planned and backed by "provably" capable development team, I would be honored to be associated with the project.