BitShares Forum
Other => Graveyard => LottoShares => Topic started by: bitmeat on May 23, 2014, 04:52:10 pm
-
If the random number is going to be controlled by FreeTrade, I suggest implementing something like the provably fair method from prime dice:
https://primedice.com/
Check the "verification" section. A "secret" is used for all the bets, then the client is able to generate their own seed to put in the mix, then the next day the secret is revealed to prove there was no foul play.
This increases confidence in the system as exhibited by the total of BTC that was wagered on that site (at the moment of writing 372,454 BTC)
-
Thanks for this. The RNG is an area I'm still unhappy with, even having given it much thought so I very much welcome proposals for improving it.
My current proposal is that I will sign the blockhash that first appears on the network with a pre-determined key. The signed hash will be used to generate the random numbers is a pre-determined way. Without any choice over the key, nor the block, nor the signing method, I'll have no control over the signed hash and thus the numbers.
Of course, there are two possible attacks I might undertake - Firstly, I might prefer blocks that are favourable to my bets to sign, and so market participants should verify that blocks that appear first on the network are the ones that are signed. Secondly, I might generate blocks myself, but discard unfavourable blocks - this would require a large amount of the hashing power and would incur the cost of discarding blocks. I think it would leave an obvious betting pattern and would be uncovered by statistical methods.
I don't think it would be rational for me to undertake either of these attacks even if I were so inclined. However, I'd still like to remove either or both as a possibility so that less trust/verification is required.
-
ChanceCoin uses the hash of the block which includes the bet and the next set of NY lottery numbers (picked every 4 minutes) to resolve the bet.
It's an interesting idea that I think we could adopt aspects of, but it has two problems as currently implemented-
1. Vulnerable to attack by bitcoin pool operators using inaccurate timestamps - (or discarding blocks if rewards become sufficiently large)
https://bitcointalk.org/index.php?topic=528023.msg6409544#msg6409544
2. This is the code being used to fetch the numbers - I can see a few problems with doing it this way, but they are fixable.
String lottoUrl = "http://nylottery.ny.gov/wps/PA_NYSLNumberCruncher/NumbersServlet?game=quick&action=winningnumbers&startSearchDate="+lottoDate+"&endSearchDate=&pageNo=&last=&perPage=999&sort=";
String lottoPage = Util.getPage(lottoUrl);
Modifications
----------------
Problem 1 - If adopting this strategy a trusted entity would be required to broadcast a guaranteed accurate time at which the block had first been seen.
Problem 2 - a trusted entity would fetch and relay the drawn numbers to the blockchain to avoid every client hammering the ny.gov site, and to be able to take action when this servlet is inevitably pulled.
Overall this would require less trust and easier verification than my original proposal.
-
My current thinking is that the least trust/verification approach is that
1. Central entity (eg FreeTrade) accepts the first block received that is built on the existing chain as final, and immediately broadcasts the time at which the block is first seen. This immediately becomes a checkpoint.
2. Waits for next set of NY lottery numbers (every 4 minutes) and then broadcasts these together with the blockhash to the network as a transaction.
3. A block including this transaction resolves winning bets and pays winners in blockchain.
-
I've described a concept for creating "fair" random seed here: https://bitsharestalk.org/index.php?topic=5368.0 .
This allows anyone to make sure others are not cheating.
If this is combined with the shares paid for the lottery as a bond => this will make sure everyone is sharing the secret (or the bond is lost, it may even be included into the jackpot).
Don't know if it will make sense in your case but I see it as viable solution.