BitShares Forum
Other => Graveyard => DAC PLAY => Topic started by: HackFisher on March 29, 2014, 02:59:18 pm
-
This thread is to summary the frequent asked questions in the forum.
FAQ:
1. how to do fair random draws?
To be summarized, can have a look of details discussion from #2 to #27.
2. Will Play DAC be with lot of rules and share one chain?
Or, will Bitshare Play allow many different kinds of Play DACs been created on the same network?
To be summarized.
3. What's the role of play shares in Bitshares Play?
Be simple, people own play shares to play the game, or act as DAC owners, or for purpose of mining, they can select whatever role they like. To be summarized
4. Where to get the White Paper?
https://docs.google.com/document/d/1KkaAnuM0a_YU2yMaeDSDiyNUv96c9TrYrCjKadC01yA/edit?usp=sharing (https://docs.google.com/document/d/1KkaAnuM0a_YU2yMaeDSDiyNUv96c9TrYrCjKadC01yA/edit?usp=sharing)
-
I think a properly implemented Lottery DAC is a killer idea. Maybe even better than a bank.
I was giving serious consideration to launching a Lotto DAC about a month ago and the chief problem I couldn't solve elegantly was how to do fair random draws - provable decentralized fairness. I came to the conclusion it would either need to rely on existing lottery draws, or have a benevolent entity with a secret key. Have you come up with a better solution?
The approach I would recommend is to destroy funds spent on tickets/bets, with maybe a 1% fee to ticket processors (miners) . . awarding all prizes from coinbase. Unlimited prize size. Profits are generated through deflation as money supply is gradually reduced.
Also there's a guy working on a cryptocoin casino - on bitcointalk, don't think he's aware of the DAC concept, but is working on something that is essentially the same.
-
Benevolent entity with a secret key (e.g. classic satoshi-Dice) has the chance to cheating by submitting selective transactions.
I would like to introduce future events (e.g. future block's info) as the feed for generating random number, to prevent the miners from collision attack, pow might be added to the generation process.
Your approach of funds/prizes management is simple and feasible, are the prizes awarded calculated in a deterministic way according to ticket sales? I prefer deterministic way to keep that the total supply can self-sustain.
-
Benevolent entity with a secret key (e.g. classic satoshi-Dice) has the chance to cheating by submitting selective transactions.
Yes, this is why it is far from ideal - maybe multiple entities with secret keys to generate a random number.
I would like to introduce future events (e.g. future block's info) as the feed for generating random number, to prevent the miners from collision attack, pow might be added to the generation process.
Now miners, or more likely, pool admins, have a chance of cheating by selective discarding of unfavourable blocks.
Solving this problem of provable distributed randomness is key.
Your approach of funds/prizes management is simple and feasible, are the prizes awarded calculated in a deterministic way according to ticket sales? I prefer deterministic way to keep that the total supply can self-sustain.
I prefer fixed-odds, with a house edge and let probability gradually reduce coin supply. Think more like Keno that a proper lottery.
-
I would like to introduce future events (e.g. future block's info) as the feed for generating random number, to prevent the miners from collision attack, pow might be added to the generation process.
Now miners, or more likely, pool admins, have a chance of cheating by selective discarding of unfavourable blocks.
Solving this problem of provable distributed randomness is key.
You are right, even with pow, miners still have chances to attack, the randomness would be better to be generated out of control of any entity, I'm thinking your approach of provable distributed randomness.
-
>I came to the conclusion it would either need to rely on existing lottery draws, or have a benevolent entity with a secret key.
(By benevolent entity I mean someone who wouldn't cheat - but the market would punish that flaw because the potential to cheat would be there)
Maybe Dan has some ideas on provable distributed fairness - I thought long and hard on it over several weeks and couldn't solve it.
-
With something like mining with heavy hash power applied you are more likely to profit by submitting the block than holding out hoping to win the lottery. After all, what are the chances that you could find 2 blocks before the rest of the network finds 1 relative to your chances of winning with the block you found?
So from my perspective a mining based approach creates a decentralized random factor that is probably good enough.
Without mining I could see something along the lines of each member of the BOD generating a secret random number in advance, revealing the hash of the network. Then after the designated drawing block all members of the BOD reveal their secret key. The secrets are all hashed together along with the hash of one block header of the drawing block.
With this particular structure the BOD would be committing to their secrete numbers long before the hash of the drawing block could be known. The only way to rig the drawing is for the BOD members to collude. If even one member is honest and keeps their information secret then the others are SOL.
The more board members you have the harder it is for them to collude.
You could go so far as to have every ticket purchase include its own secret. Once the purchase window is over, everyone reveals their secrets. The hash of everyones secrets becomes the winning number. Because no valid transactions should ever be excluded from the block-chain for more than 1 or 2 rounds of the BOD we can safely assume that no one could know the random number generated in the end.
-
I have an idea and today I had discussed it with hackfisher.
Here is it:
1.Every Tx has a parameter which is a random public key(e.g. ECDSA).
2.Miner will pack these Txs and generate a new block(e.g. at the 500th block).
3.When block 505 were generated, the DAC client will send the private key generated in step 1 automatically.(505 is just for safe, make sure not to send private key too early)
4.These private keys will also be pack in block 506-510.
4.When block 511 were generated, new private key for block 500 will not be accepted any more.These private keys for block 500(recorded in block 506-510) will be the seeds of the random number generator, using for determine the result of block 500.
Thus, when miner generate a block, they can not predict the result by select Tx, because they don't know the seeds(private keys).The result of block 500 is related with Txs in block 500 and the private key for block 500 recorded in block 506-510(generally ,not all private keys of Txs in block 500).
How about that? More details need further discuss.
-
With something like mining with heavy hash power applied you are more likely to profit by submitting the block than holding out hoping to win the lottery. After all, what are the chances that you could find 2 blocks before the rest of the network finds 1 relative to your chances of winning with the block you found?
So from my perspective a mining based approach creates a decentralized random factor that is probably good enough.
Without mining I could see something along the lines of each member of the BOD generating a secret random number in advance, revealing the hash of the network. Then after the designated drawing block all members of the BOD reveal their secret key. The secrets are all hashed together along with the hash of one block header of the drawing block.
With this particular structure the BOD would be committing to their secrete numbers long before the hash of the drawing block could be known. The only way to rig the drawing is for the BOD members to collude. If even one member is honest and keeps their information secret then the others are SOL.
The more board members you have the harder it is for them to collude.
You could go so far as to have every ticket purchase include its own secret. Once the purchase window is over, everyone reveals their secrets. The hash of everyones secrets becomes the winning number. Because no valid transactions should ever be excluded from the block-chain for more than 1 or 2 rounds of the BOD we can safely assume that no one could know the random number generated in the end.
What do BOD and SOL stand for?
-
You could go so far as to have every ticket purchase include its own secret. Once the purchase window is over, everyone reveals their secrets. The hash of everyones secrets becomes the winning number. Because no valid transactions should ever be excluded from the block-chain for more than 1 or 2 rounds of the BOD we can safely assume that no one could know the random number generated in the end.
Yes, @logxing and I had a discussion about a similar solution this afternoon.
I have an idea and today I had discussed it with hackfisher.
Here is it:
1.Every Tx has a parameter which is a random public key(e.g. ECDSA).
2.Miner will pack these Txs and generate a new block(e.g. at the 500th block).
3.When block 505 were generated, the DAC client will send the private key generated in step 1 automatically.(505 is just for safe, make sure not to send private key too early)
4.These private keys will also be pack in block 506-510.
4.When block 511 were generated, new private key for block 500 will not be accepted any more.These private keys for block 500(recorded in block 506-510) will be the seeds of the random number generator, using for determine the result of block 500.
Thus, when miner generate a block, they can not predict the result by select Tx, because they don't know the seeds(private keys).The result of block 500 is related with Txs in block 500 and the private key for block 500 recorded in block 506-510(generally ,not all private keys of Txs in block 500).
How about that? More details need further discuss.
Each user generate a random public_key together with ticket purchase, and after the ticket transactions are valid, user then publish their private key relate to the pub_key. DAC (miners?) use this private key to generate random numbers. I think This approach is quite similar to FreeTrade's meaning of provable distributed. Random number generated in this way is more reliable, I think, even though it introduce more complicate design:
1. How to select the pub_keys from distributed entities' transactions in this block, we could not identify entity behind address?
2. How to collect enough/required private keys before deadline?
The simplest way would be to use all the private keys already received before deadline, but the transactions to publish this private keys also need to be mined, in another word, has the chance to be filtered by bad miners.
-
With something like mining with heavy hash power applied you are more likely to profit by submitting the block than holding out hoping to win the lottery. After all, what are the chances that you could find 2 blocks before the rest of the network finds 1 relative to your chances of winning with the block you found?
So from my perspective a mining based approach creates a decentralized random factor that is probably good enough.
Without mining I could see something along the lines of each member of the BOD generating a secret random number in advance, revealing the hash of the network. Then after the designated drawing block all members of the BOD reveal their secret key. The secrets are all hashed together along with the hash of one block header of the drawing block.
With this particular structure the BOD would be committing to their secrete numbers long before the hash of the drawing block could be known. The only way to rig the drawing is for the BOD members to collude. If even one member is honest and keeps their information secret then the others are SOL.
The more board members you have the harder it is for them to collude.
You could go so far as to have every ticket purchase include its own secret. Once the purchase window is over, everyone reveals their secrets. The hash of everyones secrets becomes the winning number. Because no valid transactions should ever be excluded from the block-chain for more than 1 or 2 rounds of the BOD we can safely assume that no one could know the random number generated in the end.
Yes, we think alike :D
-
En...maybe we need all of the privates keys(difficult), otherwise miner block 510 still can select *private key* to do attack...
-
I have an idea and today I had discussed it with hackfisher.
Here is it:
1.Every Tx has a parameter which is a random public key(e.g. ECDSA).
2.Miner will pack these Txs and generate a new block(e.g. at the 500th block).
3.When block 505 were generated, the DAC client will send the private key generated in step 1 automatically.(505 is just for safe, make sure not to send private key too early)
4.These private keys will also be pack in block 506-510.
4.When block 511 were generated, new private key for block 500 will not be accepted any more.These private keys for block 500(recorded in block 506-510) will be the seeds of the random number generator, using for determine the result of block 500.
Thus, when miner generate a block, they can not predict the result by select Tx, because they don't know the seeds(private keys).The result of block 500 is related with Txs in block 500 and the private key for block 500 recorded in block 506-510(generally ,not all private keys of Txs in block 500).
How about that? More details need further discuss.
The owners of Txs at block 500 have the option the send their private keys or not, because they can always choose to take their clients offline. But it's hard to really control the final results. When one owner sees some results he likes, other owners will update their keys and alter the results. Then, I will plant lots of Txs at block 500 as my ammunition. When everybody has exhausted their ammo, I am the only one shooting and selecting results.
-
If the miner gets a non-trivial piece of the pot, there is really little motivation for him to select blocks. Say 0.1% of the win.
-
If the miner gets a non-trivial piece of the pot, there is really little motivation for him to select blocks. Say 0.1% of the win.
Here, the prerequisite is that we have distributed mining power. Then, whenever a miner finds a block, he is eager to publish it and make it propagate through the network as quickly as possible.
-
BTW, I meant using the hash that satisfies hash target. Just take the hash itself as the lucky number, or hash of that hash. No Txs should be messed with the lucky number, since they are inherently controllable by miners.
-
I think pow or economics motivation is not enough.
I hope it is safe by nature.
By the way:
public key->hash
private key->random secret number
will be simple.
-
Benevolent entity with a secret key (e.g. classic satoshi-Dice) has the chance to cheating by submitting selective transactions.
I would like to introduce future events (e.g. future block's info) as the feed for generating random number, to prevent the miners from collision attack, pow might be added to the generation process.
Your approach of funds/prizes management is simple and feasible, are the prizes awarded calculated in a deterministic way according to ticket sales? I prefer deterministic way to keep that the total supply can self-sustain.
Getting random elements from future events is a good idea. :)
How about grab some random data from other DAC's block (BTC,LTC,NXT...) and hybrid the data before making the random number?
I think it maybe impossible to be attacked or controlled by bad guys.
-
Future events of blockchain is not so random. It is all about miner :(
-
I mean reading some old random data from other Dacs and using some future elements also ,and then ,hybriding all these data to make out the final random number .
:)
-
I mean reading some old random data from other Dacs and using some future elements also ,and then ,hybriding all these data to make out the final random number .
:)
The algorithm is public. The key is seeds.
We should make sure the result(the winning number) be determined before it can be calculated out.
Actually, we can do this if we use all of the secret numbers(or private keys) to determine the winning number.But this is hard...
-
With something like mining with heavy hash power applied you are more likely to profit by submitting the block than holding out hoping to win the lottery. After all, what are the chances that you could find 2 blocks before the rest of the network finds 1 relative to your chances of winning with the block you found?
So from my perspective a mining based approach creates a decentralized random factor that is probably good enough.
Let's say we have a pool operator with 30% of the hash power, betting heavily on a 50/50 event . . . discarding some blocks could be very profitable - this is the case I wanted to guard against with a generalized solution for provable fairness in decentralized games of chance.
Without mining I could see something along the lines of each member of the BOD generating a secret random number in advance, revealing the hash of the network. Then after the designated drawing block all members of the BOD reveal their secret key. The secrets are all hashed together along with the hash of one block header of the drawing block.
With this particular structure the BOD would be committing to their secrete numbers long before the hash of the drawing block could be known. The only way to rig the drawing is for the BOD members to collude. If even one member is honest and keeps their information secret then the others are SOL.
I agree - this would be better than a single benevolent entity. In addition, the block hash could be used, so that colluding members would also need mining power for an attack. I wonder how we'd proceed if one of the required trusted members stopped co-operating. Also it still leaves open a potential attack route . . . . better if there was none, but perhaps that is a technically impossible requirement.
-
I mean reading some old random data from other Dacs and using some future elements also ,and then ,hybriding all these data to make out the final random number .
:)
The algorithm is public. The key is seeds.
We should make sure the result(the winning number) be determined before it can be calculated out.
Actually, we can do this if we use all of the secret numbers(or private keys) to determine the winning number.But this is hard...
There are future events which are hard/impossible to predict("calculated out" in your words), so they are random to the observers before it happen, but not be determined yet util happen time. They are determined and happen at the same time, can not be calculated before that, but right away being calculated (and no need to calculated) out the same time(because every one knows).
But in some cases, observers can predict the result by influencing the event that will happen, that the case of miner here being as observers. We can add difficulty to the influence process to make their relation more independent, or economic impossible.
So I think future event is still a good option. But if the random event result is determined before it happen, and no one can know(calculate) it before ticket purchase, that would be great too. But the later case here is that, we can not guarantee that we can get it before deadline.
-
With something like mining with heavy hash power applied you are more likely to profit by submitting the block than holding out hoping to win the lottery. After all, what are the chances that you could find 2 blocks before the rest of the network finds 1 relative to your chances of winning with the block you found?
So from my perspective a mining based approach creates a decentralized random factor that is probably good enough.
Without mining I could see something along the lines of each member of the BOD generating a secret random number in advance, revealing the hash of the network. Then after the designated drawing block all members of the BOD reveal their secret key. The secrets are all hashed together along with the hash of one block header of the drawing block.
With this particular structure the BOD would be committing to their secrete numbers long before the hash of the drawing block could be known. The only way to rig the drawing is for the BOD members to collude. If even one member is honest and keeps their information secret then the others are SOL.
The more board members you have the harder it is for them to collude.
You could go so far as to have every ticket purchase include its own secret. Once the purchase window is over, everyone reveals their secrets. The hash of everyones secrets becomes the winning number. Because no valid transactions should ever be excluded from the block-chain for more than 1 or 2 rounds of the BOD we can safely assume that no one could know the random number generated in the end.
What do BOD and SOL stand for?
BOD = Board of Directors
If you don't recognize the other one, I guess you're just SOL. :)
http://www.urbandictionary.com/define.php?term=S.O.L. (http://www.urbandictionary.com/define.php?term=S.O.L.)
-
I mean reading some old random data from other Dacs and using some future elements also ,and then ,hybriding all these data to make out the final random number .
:)
The algorithm is public. The key is seeds.
We should make sure the result(the winning number) be determined before it can be calculated out.
Actually, we can do this if we use all of the secret numbers(or private keys) to determine the winning number.But this is hard...
There are future events which are hard/impossible to predict("calculated out" in your words), so they are random to the observers before it happen, but not be determined yet util happen time. They are determined and happen at the same time, can not be calculated before that, but right away being calculated (and no need to calculated) out the same time(because every one knows).
But in some cases, observers can predict the result by influencing the event that will happen, that the case of miner here being as observers. We can add difficulty to the influence process to make their relation more independent, or economic impossible.
So I think future event is still a good option. But if the random event result is determined before it happen, and no one can know(calculate) it before ticket purchase, that would be great too. But the later case here is that, we can not guarantee that we can get it before deadline.
in short, the safest model:
be determined before it can be calculated outmeans
^ ^
miner generate block,
(Tx and the hash of seed)
gather all random seeds,
everyone can observer result
---------------------------------------------Time Line---------------------------------------------------------->
Current model:
future events, be determined and everyone can observer result Immediately
^ ^
minerA generate block(Tx),
minerB generate another block, the hash of this block determine result.
minerB can observer result before distribute it. So he can select another result which he prefer.
determine and observer at the same time
---------------------------------------------Time Line---------------------------------------------------------->
-
If the "future events" is determined by single person, this random has this problem.
So I think the key point is finally determined by single person(minerB).
-
minerB can observer result before distribute it. So he can select another result which he prefer.
---------------------------------------------Time Line---------------------------------------------------------->
When minerB are going to re-select another result rather than distribute it, he are losing competition advantage to other miners. The process before observe the result takes time because POW are introduced. This is what I mean economic impossible, and POW reduced the miner's influence to the result, time spent is the point.
And try result collision is difficult in a probability space of > 476127 (to get third-prized of double color lottory), given that the miner have maximum to 10x time before other miners have the block for distribution, the possibility is still very low < 1/47612.
-
Understood :D
-
I think the entire process can be boiled down to the following process without a BOD.
1) Anyone who wishes to contribute to the Random Number Generation process publishes the hash of their secret HASH(S).
2) After all HASH(S) has been published all participants have an opportunity to publish S
3) After all participants are given an opportunity to publish their S, HASH( S[0...N] ) is calculated as the chosen random number.
Anyone concerned about the randomness of the result can participate in the process by publishing two transactions. Everyone else can simply choose to trust that the others are not colluding. If there is even one honest individual in the batch then it is secure. If all of the BOD contribute to the process then it can be assumed that there is a high probability that at least one of them is honest.
In this way everyone who wants it to be provably fair 'for certain' can know for sure that it was fair if they pay the minimum transaction fee. Everyone else can simply trust that it is fair and take the risk that everyone else is colluding against them. Given the value of the network is derived from the fairness of this, the BOD is financial stake in the network, and anyone can prove it fair for their own use I suspect it is a perfect system from a fairness perspective. It also allocates the cost of making sure it is provably secure to those who care about it the most.
-
I think the entire process can be boiled down to the following process without a BOD.
1) Anyone who wishes to contribute to the Random Number Generation process publishes the hash of their secret HASH(S).
2) After all HASH(S) has been published all participants have an opportunity to publish S
3) After all participants are given an opportunity to publish their S, HASH( S[0...N] ) is calculated as the chosen random number.
Anyone concerned about the randomness of the result can participate in the process by publishing two transactions. Everyone else can simply choose to trust that the others are not colluding. If there is even one honest individual in the batch then it is secure. If all of the BOD contribute to the process then it can be assumed that there is a high probability that at least one of them is honest.
In this way everyone who wants it to be provably fair 'for certain' can know for sure that it was fair if they pay the minimum transaction fee. Everyone else can simply trust that it is fair and take the risk that everyone else is colluding against them. Given the value of the network is derived from the fairness of this, the BOD is financial stake in the network, and anyone can prove it fair for their own use I suspect it is a perfect system from a fairness perspective. It also allocates the cost of making sure it is provably secure to those who care about it the most.
It's much simpler than POW and I like it.
But as it is hash, there might be risk of last publishing person colliding his own hash for different S. HASH(S[0...N]) will make it a bit more difficult but it still can be done if you have huge computation power like ASIC. I think we can require signing using private key instead of hash which is more secure.
-
I think the entire process can be boiled down to the following process without a BOD.
1) Anyone who wishes to contribute to the Random Number Generation process publishes the hash of their secret HASH(S).
2) After all HASH(S) has been published all participants have an opportunity to publish S
3) After all participants are given an opportunity to publish their S, HASH( S[0...N] ) is calculated as the chosen random number.
Anyone concerned about the randomness of the result can participate in the process by publishing two transactions. Everyone else can simply choose to trust that the others are not colluding. If there is even one honest individual in the batch then it is secure. If all of the BOD contribute to the process then it can be assumed that there is a high probability that at least one of them is honest.
In this way everyone who wants it to be provably fair 'for certain' can know for sure that it was fair if they pay the minimum transaction fee. Everyone else can simply trust that it is fair and take the risk that everyone else is colluding against them. Given the value of the network is derived from the fairness of this, the BOD is financial stake in the network, and anyone can prove it fair for their own use I suspect it is a perfect system from a fairness perspective. It also allocates the cost of making sure it is provably secure to those who care about it the most.
It's much simpler than POW and I like it.
But as it is hash, there might be risk of last publishing person colliding his own hash for different S. HASH(S[0...N]) will make it a bit more difficult but it still can be done if you have huge computation power like ASIC. I think we can require signing using private key instead of hash which is more secure.
The last person cannot do anything because the committed to their value of S... they can choose to reveal or not to reveal but they cannot change the value. That is why it is a 3 step process. A SHA256(S) is just as secure or more so than a signature for this application. No amount of mining can help the attacker here.
If you wanted to 'attack' then you could publish a whole bunch of entries into the RNG algorithm and selectively reveal... your secrets to generate different outcomes. Given the combinatorics of the situation I suppose someone that made 64 submissions could have 2^64 different attempts at manipulating the outcome. To mitigate this particular type of manipulation the trustee reveals their secret last.
Now we just have the problem of the last trustee having 64 entries into the RNG and thus selectively publishing his secret. It seems the only way to prevent cheating is for all participants that participate in step 1 must also participate in step 2 or else lose a surety bond. If not every participates in phase 2 then the process must restart.
This means that an attacker could delay the selection of the Random Number so long as they were willing to give up their bond.
-
Now we just have the problem of the last trustee having 64 entries into the RNG and thus selectively publishing his secret. It seems the only way to prevent cheating is for all participants that participate in step 1 must also participate in step 2 or else lose a surety bond. If not every participates in phase 2 then the process must restart.
This means that an attacker could delay the selection of the Random Number so long as they were willing to give up their bond.
Yes, I meant collision in step 2. As the number to be generated is in a limited range, I think it'll be achieved for an ASIC. To make things worse, the cheater can collide before hand preparing several S1,S2,S3 for the same hash. To prevent this, we may need to use current block's hash in step 3 to avoid prepared collision. Also I doubt surety bond would work. On the one hand, it's too little compared with what the cheater can get. It can avoid loosing anything by publishing the original S in the last second if collision failed. On the other hand, for an honest node, it's too much if any delay happens like network issue or computer issue.
-
Maybe I was wrong if the hash collision is as difficult as bitcoin address hashing. In that case it's easier just to collide for an address with large amount bitcoin. :) If that's true, I think the way you describe will work perfectly.
-
I am not sure what you mean by collusion in step 2... in step 2 the only attack is 'not revealing your number'... which if we cause this step to reset to step 1 unless everyone reveals then you cannot gain anything. The most you can do is go another round. However, if everyone who failed to reveal their number paid those that did from a surety bond then you could delay the selection on the winner, but you could not force yourself to get a win.
It would be annoying, but profitable for the network to collect these surety bonds and it would be costly on the attacker to 'keep it up' long term.
This means I would probably stick with letting the BOD do the drawing because they have a 99% uptime guarantee and are generally trusted. As long as a single one is honest you are ok.
-
I mean prepare multiple S values for the same hash(S). But as I mentioned later, if it maybe same difficult as collide a private key for a bitcoin address. So just ignore the previous reply if it's same difficult as bitcoin address hashing.
-
I mean prepare multiple S values for the same hash(S). But as I mentioned later, if it maybe same difficult as collide a private key for a bitcoin address. So just ignore the previous reply if it's same difficult as bitcoin address hashing.
Roger.. yes this would be sha2 or perhas 512 since bitcoin has weakened sha235
-
I'm not sure my calculation is right:
Given that the probability space of the lottery Game is N. Given that no requires that all participants that participate in step 1 must also participate in step 2, we need a role to observe who did participate, which could be a bad miner.
Suppose there is one attacker(miner or who select all the publish S in step 3) , and who have several secrets(S) total to M for selection/combination, There will be 2^M attempts. The probability of collision failure is ( (N-1)/N ) ^ |2^M|, which could be very small, in another word, the attacker could probably attack successfully.
Then, if the last trustee is introduced, who can selective publish their only one secret(which mean he only have 2 attempt to collision) at last. Now we have two entity in RNG, miner and trustee, we still should guarantee that bad miner and trustee are not collude.
So the perfect way might be to require "all participants that participate in step 1 must also participate in step 2", which could really distribute the entities who do *not* have the attempt to collude.
-
Well, if I'm an attacker, I can participant as 10 participants and choose not to reveal some of their S. In this way, I'm trying to collide the result. As the target range is relatively small, there're chances that I can win. Furthermore, if I failed, I can choose to publish all the S in the last second. The surety bond can't prevent this. We need to find a firm way to [require "all participants that participate in step 1 must also participate in step 2"].
-
Well, if I'm an attacker, I can participant as 10 participants and choose not to reveal some of their S. In this way, I'm trying to collide the result. As the target range is relatively small, there're chances that I can win. Furthermore, if I failed, I can choose to publish all the S in the last second. The surety bond can't prevent this. We need to find a firm way to [require "all participants that participate in step 1 must also participate in step 2"].
Yes, if the firm way to [require "all participants that participate in step 1 must also participate in step 2"] is found, then there is no need for participants observation, all honest nodes will check/valid the result according to ticket purchase block(step 1).
-
I think there is a natural balance, that's the philosophy.
If we are going to really distribute the randomness ahead of time, that is not enough for us to get that randomness, we still need to depend on the randomness process of collecting/communicate them later.
Got one advantage, but lose the another one.
-
This means I would probably stick with letting the BOD do the drawing because they have a 99% uptime guarantee and are generally trusted. As long as a single one is honest you are ok.
Think this is probably the best approach put forward so far, but still feels like there might be a better trustless solution.
-
This means I would probably stick with letting the BOD do the drawing because they have a 99% uptime guarantee and are generally trusted. As long as a single one is honest you are ok.
Think this is probably the best approach put forward so far, but still feels like there might be a better trustless solution.
Yes, agree, I think I missed the bright ideas from bytemaster.
How about the ticket transactions vote for some from BOD, and not too many so could easy be collected.
Just some ideas from here: http://www.dc.uba.ar/inv/tesis/licenciatura/2010/lerner (http://www.dc.uba.ar/inv/tesis/licenciatura/2010/lerner)
How about this way:
When the block round of ticket purchase begins, all the participants select fixed number of players out from BOD, this player provide hash/pubkey together with this block.
After the block is done, the next block these player could publish the priv_keys to generate the random number for that ticket purchase block.
The key point is that, the players are fixed and 99% online, so would be very easy for collecting, BOD thus act as CO-PRNGP Player service.
The leaving problem is only how will the tickets choose limit number the players, e.g. top 10 voted. all might be too many for collecting.
CO-PRNGP algorithm from that paper:
1) Each player i :
1.1) Chooses a random number ri := RandomNumber(csprng-seed-bit-length)
1.2) Computes cri := H(ri)MPF – Sergio Demian Lerner 44/83
1.3) Broadcasts cri (a commitment to ri )
2) Each player i:
2.1) Broadcasts ri
2.2) For each j, verifies that cri := H(ri)
2.3) Computes S = H(r1;r2;..;rn)
2.4) Uses S as seed for a common CSPRNG.
2.5) Use CSPRNG to generate the symmetric algorithm (CGC) common parameters.
2.6) Uses the CSPRNG to generate c distinct suitable encodings of the real cards in a deck to be
used as open cards. The generated cards are saved in the Open-Deck list.
2.7) Computes dhi := H(Open-Deck).
3) The first player broadcasts dh1.
4) Everybody verifies having computed dhi equal to dh1. If a player detects a mismatch, the protocol aborts
-
Yes, agree, I think I missed the bright ideas from bytemaster.
How about the ticket transactions vote for some from BOD, and not too many so could easy be collected.
Yes, I think while finding a trustworthy entity to make the draw might be workable, a problem it introduces is that the entity might be leant on (by government or criminals). So some decentralized way to choose a trusted agent would be important if going this way.