Author Topic: The way to resolve "The Last Evil Delegate Problem" in DPOS  (Read 12750 times)

0 Members and 1 Guest are viewing this topic.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
Well thank you.  I think that works without too much complexity.  I had a similar thought, but it had the actual secret number shared amongst 3 people.  Then I thought that added new vectors of collusion so gave up on the idea.  I'll have to give this some more thought.  FreeTrade = RealGenius.
I speak for myself and only myself.

Offline FreeTrade

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
Eureka!

Wow, what's that?
I think I've got it, but not sure what I want to do with it yet.

You can tell me secretly, I won't tell others.  :D
Maybe I have things to do with it.

Okay, here it is, but don't tell the others . . .

https://bitsharestalk.org/index.php?topic=7989
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline Chuckone

  • Sr. Member
  • ****
  • Posts: 314
    • View Profile
Those who get remembered as great achievers are usually visionaries that influence and inspire people around them. I've had the chance to discuss with some corporate big shots in the past, and most of those at the top aren't usually the most brilliant, but they have a vision, a solid work ethic, they're charismatic and they know how to surround themselves with top talents and give them a common goal.

From what I've seen, there's a whole bunch of very talented people in here. I guess a lot could be achieved if all that talent was focused on common goals...

Offline CLains

  • Hero Member
  • *****
  • Posts: 2606
    • View Profile
  • BitShares: clains
Remember that Baritus guy who developed Argentum, Digitalcoin, Securecoin and even build a whole exchange pretty much by himself? Protip: Don't be like him.
Ui, not even I knew about that .. learn sth. new every day(tm)

There are a million people like Baritus in this space. It is a disease masquerading as noble.

The psychology is this: Most intelligent people who are good programmers have these two features; 1) they have been spending an inordinate amount of time in an asocial manner, 2) they always knew better than everyone else in their peer-group how to get things done.

This means that they lack the incentive to reach out and collaborate on two levels, 1) that they are not social in the first place, and 2) that they believe they can do better alone. This of course is a horrible combination when you lift these guys into competition with the global elite.

Top achievers, of course, realize very early that such dispositions are flaws that must be overcome. They learn to delegate tasks to other people. They learn to reach out to people and value collaborations.
« Last Edit: August 28, 2014, 12:58:39 am by CLains »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Remember that Baritus guy who developed Argentum, Digitalcoin, Securecoin and even build a whole exchange pretty much by himself? Protip: Don't be like him.
Ui, not even I knew about that .. learn sth. new every day(tm)

Offline CLains

  • Hero Member
  • *****
  • Posts: 2606
    • View Profile
  • BitShares: clains
Come'on FreeTrade tell us your thoughts.  You can't go around teasing like that.  Shame shame.

Well it is a problem that I've been ruminating on for months, and I have been working on a competing/complementary/co-operating lottery DAC. So maybe you can understand why I'm not ready to put it out there just yet.

Why don't you just set up camp with Hackfisher at Virginia? I don't understand.. You guys got the whole world now if you could just pool your resources and kick yourselves into exponential overdrive.

Remember that Baritus guy who developed Argentum, Digitalcoin, Securecoin and even build a whole exchange pretty much by himself? Protip: Don't be like him.

Sure he was hard working,
sure he was talented,
sure he was honest,
sure he focused on quality products.

Then the moment something more shiny came to market he was soon forgotten.
Shit like Quarkcoin and Megacoin raced past him due to superior collaborations, marketing, and design.
« Last Edit: August 27, 2014, 09:41:33 pm by CLains »

Offline bytemaster


Can block time be put under 10 seconds if you reduce the number of delegates ?
block time is more an issue of network latency and from my understanding has nothing to do with the number of delegates
however, security does ... a transaction is fixed (as in stone) after 51% of delegates confirmed it (in subsequent blocks)
that corresponts to a checkpoint basically

I think you could probably go to 5 seconds for a gaming DAC. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc

Can block time be put under 10 seconds if you reduce the number of delegates ?
block time is more an issue of network latency and from my understanding has nothing to do with the number of delegates
however, security does ... a transaction is fixed (as in stone) after 51% of delegates confirmed it (in subsequent blocks)
that corresponts to a checkpoint basically

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile

Can block time be put under 10 seconds if you reduce the number of delegates ?
I speak for myself and only myself.

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile

In fact, a colluding delegate could just ignore transactions when they know they have a loser.  It doesn't even have to be a missed block.  Wouldn't this be simple to do ?  So you now have to expect transactions to go in certain blocks and figure out all the heuristics for this?  Isn't that what is required for bytemaster's missed blocks == house rake approach to work ?

It really isn't missed blocks, it is just not accepting transactions and pushing them off to next block.  This is a harder attack to discover unless you start timestamping transactions etc.  I think this might be required to detect this attack ?

You can keep the "winning/loosing" a secret until after the ticket has been included.  So this is not an issue.

You can reveal winning/losing after ticket has been included, but that requires extra blocks which adds latency in the game if I understand correctly.  Ideally gaming transaction is put on same block as RNG revelation.  Otherwise we add 10 seconds to every game round.

Yes, But I think 10s latency is acceptable for most of the chance games. For real time game, hmm. I think it's still a long way to go.

BTW, for some counterparty betting chance games, they may not depend on any 3rd RNG, including the one from DPOS.
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile

In fact, a colluding delegate could just ignore transactions when they know they have a loser.  It doesn't even have to be a missed block.  Wouldn't this be simple to do ?  So you now have to expect transactions to go in certain blocks and figure out all the heuristics for this?  Isn't that what is required for bytemaster's missed blocks == house rake approach to work ?

It really isn't missed blocks, it is just not accepting transactions and pushing them off to next block.  This is a harder attack to discover unless you start timestamping transactions etc.  I think this might be required to detect this attack ?

You can keep the "winning/loosing" a secret until after the ticket has been included.  So this is not an issue.

You can reveal winning/losing after ticket has been included, but that requires extra blocks which adds latency in the game if I understand correctly.  Ideally gaming transaction is put on same block as RNG revelation.  Otherwise we add 10 seconds to every game round.
I speak for myself and only myself.

Offline bytemaster


In fact, a colluding delegate could just ignore transactions when they know they have a loser.  It doesn't even have to be a missed block.  Wouldn't this be simple to do ?  So you now have to expect transactions to go in certain blocks and figure out all the heuristics for this?  Isn't that what is required for bytemaster's missed blocks == house rake approach to work ?

It really isn't missed blocks, it is just not accepting transactions and pushing them off to next block.  This is a harder attack to discover unless you start timestamping transactions etc.  I think this might be required to detect this attack ?

You can keep the "winning/loosing" a secret until after the ticket has been included.  So this is not an issue.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile

In fact, a colluding delegate could just ignore transactions when they know they have a loser.  It doesn't even have to be a missed block.  Wouldn't this be simple to do ?  So you now have to expect transactions to go in certain blocks and figure out all the heuristics for this?  Isn't that what is required for bytemaster's missed blocks == house rake approach to work ?

It really isn't missed blocks, it is just not accepting transactions and pushing them off to next block.  This is a harder attack to discover unless you start timestamping transactions etc.  I think this might be required to detect this attack ?
I speak for myself and only myself.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile

Since player puts their amount on blockchain and it is encrypted, there becomes a problem with the player holding out their wager.  I suppose you force the player to reveal all their wagers to be able to unlock their account funds?

If 2 delegates in a row collude, you can have the first guy withhold because it affects the outcome of the next one.  So  delegates A&B are colluding, and this is the round where they are adjacent.  Delegate A can withhold or not withhold, but they can also look at how their result affects B.  So if delegate B doesn't provide a winner, then A can just publish the block.   So it makes the attack even less detectable as it can be carried out while only holding out blocks where an incorrect winner is awarded.  With 101 guys its like 1/50 rounds that 2 guys are adjacent.  If 5 collude blech math is hard, but the opportunity to drain the house bank becomes quite credible.

I thought about allowing the block to be published later with the RNG but it makes the above attack even worse.

I believe bytemaster said the missed block doesn't get paid, but then you have to figure out how to attribute what was supposed to go wtih what block etc, so even that becomes a headache.  Usually transaction would float over to next block.  Now you can't do that, you have to figure out when a transaction appears likely to have been meant for previous block.

It isn't even just missed blocks, delegates can exclude transactions selectively etc.

I speak for myself and only myself.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
Come'on FreeTrade tell us your thoughts.  You can't go around teasing like that.  Shame shame.

Well it is a problem that I've been ruminating on for months, and I have been working on a competing/complementary/co-operating lottery DAC. So maybe you can understand why I'm not ready to put it out there just yet.
   

Yes I understand but my question would be why tell us you figured something out in the first place? :)  Although it is a good motivator...

Bytemaster -  The problem with the wager being lost if a delegate excludes is that it would never ever be acceptable for that to be a rule.  The server screws up so you lose your wager ?  One bad delegate could chase off half your user base.

The delegate would have to pay up the wager too, or that is a rule to be exploited to hurt the network.  So now if delegate has to pay up on a missing transaction, then transaction fees have to be increased to make up for this.  Maybe it could work out, no real clue.

Assuming delegates aim for 99% uptime, this would amount to a 1% chance of losing or a 1% rake.

Not all chains will have 101 delegates.  We have to assume chains may have as few as 10 or 20 ?  It would be easy to attack a network on a user-satisfaction level by becoming elected then dropping a lot of blocks.  From a user's perspective what is the value in all this provably fair/trusted talk when all a delegate has to do is not send out a block.

If the delegate doesn't also lose the wager amount by having it burned, then this won't work.  It is not incentivized properly.  We should look at BitsharesX to see what average missed block % is.  To incentivize it properly then delegates need to be paid more so they can be punished more when they don't send out blocks.  I'd need to bang on a spreadsheet to see if it could make sense. 

Perhaps the answer is actually lowering the # of delegates.  I was thinking that a small chain might not have enough behind it to attract 101 delegates.  So with 25 delegates, now everyone gets paid 4x more and maybe that makes it easier to incentivize properly.
I speak for myself and only myself.

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
and it forces delegates to get their job really serious... 

Offline bytemaster

Come'on FreeTrade tell us your thoughts.  You can't go around teasing like that.  Shame shame.

Well it is a problem that I've been ruminating on for months, and I have been working on a competing/complementary/co-operating lottery DAC. So maybe you can understand why I'm not ready to put it out there just yet.
   

Yes I understand but my question would be why tell us you figured something out in the first place? :)  Although it is a good motivator...

Bytemaster -  The problem with the wager being lost if a delegate excludes is that it would never ever be acceptable for that to be a rule.  The server screws up so you lose your wager ?  One bad delegate could chase off half your user base.

The delegate would have to pay up the wager too, or that is a rule to be exploited to hurt the network.  So now if delegate has to pay up on a missing transaction, then transaction fees have to be increased to make up for this.  Maybe it could work out, no real clue.

Assuming delegates aim for 99% uptime, this would amount to a 1% chance of losing or a 1% rake. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
Come'on FreeTrade tell us your thoughts.  You can't go around teasing like that.  Shame shame.

Well it is a problem that I've been ruminating on for months, and I have been working on a competing/complementary/co-operating lottery DAC. So maybe you can understand why I'm not ready to put it out there just yet.
   

Yes I understand but my question would be why tell us you figured something out in the first place? :)  Although it is a good motivator...

Bytemaster -  The problem with the wager being lost if a delegate excludes is that it would never ever be acceptable for that to be a rule.  The server screws up so you lose your wager ?  One bad delegate could chase off half your user base.

The delegate would have to pay up the wager too, or that is a rule to be exploited to hurt the network.  So now if delegate has to pay up on a missing transaction, then transaction fees have to be increased to make up for this.  Maybe it could work out, no real clue.
I speak for myself and only myself.

Offline FreeTrade

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
Come'on FreeTrade tell us your thoughts.  You can't go around teasing like that.  Shame shame.

Well it is a problem that I've been ruminating on for months, and I have been working on a competing/complementary/co-operating lottery DAC. So maybe you can understand why I'm not ready to put it out there just yet.
   
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline FreeTrade

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
If the wagers are secret until the user claims them that prevents delegates from excluding winning wagers.

I like this idea - it fixes the potential issue of delegates deep-sixing other people's jackpots.
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline bytemaster

If the wagers are secret until the user claims them that prevents delegates from excluding winning wagers.
If wagers are automatically lost if the delegate fails to produce a block, that prevents a delegate from getting a second chance and doubling his odds.

With these two rules in place you can have a secure dice roll with 1 confirmation (10 seconds) unless one person controls two delegate slots.

If someone controls 2 delegate slots back-to-back then they have 10 seconds to do a proof-of-work search to find a winning ticket and submit it. 

So the question is how many delegates can be controlled by one person.  The answer should be less than 50 and could probably be less than 25.   So you are looking at a 4 minute delay to make sure that no one person can get so many delegates in a row.

However, now you have to worry about colluding delegates.  By waiting 101 blocks you can be sure that if ONE of them is honest then the result is "random".  If you only wait 25 blocks then you are trusting that 25% or more of the delegates are honest. 

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
Come'on FreeTrade tell us your thoughts.  You can't go around teasing like that.  Shame shame.

It is an interesting thing.  From a user's perspective you have to worry about the Delegate colluding with the network to cheat the user.  From the network's perspective you have to worry about a player colluding with a Delegate.

A delegate colluding with a player is a far bigger issue, because there is a significantly greater pay off for the cheat.  However that is not what user's are concerned over, so it is a bit of a wash from a developer's perspective.

One could keep track of  the wagers that were on the missed and unmissed blocks.  Eventually it should become apparent if someone is cheating.  Then they are removed as a Delegate and one of the trusted Delegates could come up with other delegates.  Every now and then let in a new delegate from an untrusted source.

There may be some crypto-function where all the RNG's could be signed on some multi-sig like function the previous round.  I wish I knew more about high level crypto constructs and their applicability.  If the RNG had some like way to reveal itself with a majority, then the solution might lie there. 

If you stretched the game cycle to include multiple cycles you can have player present their RNG hash with wager.  Block producer puts out their RNG on same block as RNG hash.  Player then reveals their true RNG.  If player withholds, then they lose their wager.  Real simple, what would be wrong with this ?  It turns average action turn into 25 seconds ..  Meh.  Actually thats not true as client can display results before it is accepted on blockchain.  This still allows the player to collude with DAC.  So DAC needs a majority of some set of people who control the RNG to reveal it, removing the power from one delegate's hands.
« Last Edit: August 10, 2014, 10:37:01 pm by gamey »
I speak for myself and only myself.

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
Eureka!

Wow, what's that?
I think I've got it, but not sure what I want to do with it yet.

You can tell me secretly, I won't tell others.  :D
Maybe I have things to do with it.
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani

Offline FreeTrade

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline FreeTrade

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
where can i find something about RNG DPOS? would like to think about it.

would it not possible to let 101 delegate draw the numbers and everydelagte will produce a random number betwenn 1 and 101 the average number is the delegate which numbers are used?


Here is a draft white paper:
https://docs.google.com/document/d/1KkaAnuM0a_YU2yMaeDSDiyNUv96c9TrYrCjKadC01yA/edit

We need deterministic way to reach consensus, otherwise the consensus might be broken. With DPOS, I realized that there always will be one guy who can affect the random result before the last second.

The first time I was try to resolve this, I have a idea that one block is from two source delegate:

Quote
There are two independent queue of delegates, each have 101 delegates with the same 10s interval steps.
In every delegate slot, two delegates from two source list, need to produce and broadcast two blocks (one is normal  block data like now with secret and transactions, another one block data contains only secret ).

The other normal client will receive both of these two different block and merged them into one block before inserting to the final shared chain.

After I wrote the last sentence, I found that one of the two source delegate could be bad, and choose to receive  another source broadcast block to it first, which means, competing for the last position of random chain factors, and then attack intentionally by missing blocks, this is why I have to give up this approach, and call it ""Last Delegate being Evil Problem""
« Last Edit: August 08, 2014, 03:03:06 pm by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bytemaster

I believe you can get it down to a CONSTANT time. 

The core problem is that if a delegate intentionally chooses to miss a block he gets to go again (doubling his chances).

I would instead make the game one of:  if no block is produced then everyone loses.   Consider this the "house edge". 

A delegate can no longer use skipping a block to double his chances.  The only thing a delegate can do is make everyones' chances to go 0.

Delegates that don't produce blocks get fired so there is no profit in them skipping a block.

There still remains the issue FreeTrade brought up:  a delegate could skip a block to harm someone else who would have won the jackpot.  If paying out the jackpot would dilute shareholders then this could in-theory be profitable to the delegate.  However this couldn't happen consistently without it really harming the market value of the network.

The solution here is to simply limit the winnings to a jackpot that doesn't dilute shareholders.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline FreeTrade

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
Wouldn't the jackpot just get awarded in the next block?

No, the winning draw would never be made public. No-one would be any the wiser.
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline Riverhead

Wouldn't the jackpot just get awarded in the next block? I'm assuming the network has some way of telling if the winner received their funds. However, your point is well taken.  A bad actor delegate can mess with the system by tampering with blocks.  Perhaps some lessons can be taken from TCP/IP's guaranteed delivery/ack protocol to help with block manipulation?

Offline FreeTrade

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
Another 'evil' delegate problem you might want to consider . .

The last delegate may want to discard a result that is too favorable to someone else.

Let's say there is a large jackpot, and the delegate has a large stake in the DAC . . . maybe the penalty to him for discarding a winning jackpot result is smaller than the penalty for awarding the jackpot (money supply inflation, losing the marketing effect of the jackpot).
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
hackfish does not want to wait for 101 delegates to get his randomness .. he wants the randomness as early as 1 block .. but that cannot be truely randomnes as a selfish delegate could miss that 1 block intensionally if the random number is not in his favor .. however, wouldn't then the next block/delgate select the random number which might be trustworthy ..
this increases the luck of the selfish delegate by factor 2.

So hackfish prosposes to let the randomnes decided WHICH delegate (within the next N delegates (equally distributed) - excluding the own(selfish) delegate) should pick your random number ..

I really like that idea very much! only disadvantage is that the delay (until you finally get your random number) is NOT constant and depends on "N" (above)

+5% for that proposal hackfish!

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
then 101 delegate draw a random number and the number who is most drawn will be the number?

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
where can i find something about RNG DPOS? would like to think about it.

would it not possible to let 101 delegate draw the numbers and everydelagte will produce a random number betwenn 1 and 101 the average number is the delegate which numbers are used?
the average number is not  good, the probability of each number is not equal.

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
where can i find something about RNG DPOS? would like to think about it.

would it not possible to let 101 delegate draw the numbers and everydelagte will produce a random number betwenn 1 and 101 the average number is the delegate which numbers are used?

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
I prefer  change   evil to selfish
In fact, as a normal user of DAC, we believe that every delegate is selfish
we believe every delegate would choose to miss block if they can profit.
we need set rules to  punish  miss block if possible.

yes, not blaming the evil, so we need to resolve it mathematically within consensus.
The ultimate of this solution can effectively reduce minimum ticket draw time from 101 blocks to 3 blocks and no one will choose to be evil intentionally.
« Last Edit: August 08, 2014, 02:43:59 pm by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
I prefer  change   evil to selfish
In fact, as a normal user of DAC, we believe that every delegate is selfish
we believe every delegate would choose to miss block if they can profit.
we need set rules to  punish  miss block if possible.

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
In some sense, this have something in common with shuffle.

If the delegate can not predict the draw block, his attack cost is always larger than attack return from the perspective of probability
« Last Edit: August 08, 2014, 03:28:44 am by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
In DPOS RNG algorithm, an evil delegate can only choose to throw away an unfavorable random result by intentionally missing block on his slot turn.

This could only be a problem, when the ticket draw interval is less than 101 blocks, because delegate can predict which block he will produce. Then he can choose to buy ticket which will draw in that block.

If the ticket draw interval is larger than 101 blocks, which means there will be at least one shuffle in that period, then the evil delegate can not predict which block he will produce. Then his only strategy is to guess or put tickets in each of the 101 blocks. If guess, his chance is 1/101, the *expect* return he can get back by attacking is the price of that ticket when he lose, because the delegate after him will continue to replace him and draw randomly. If he choose to put ticket in each blocks, his attack cost is (101 * block_ticket_sale), but what's the expected return, still the ticket sale he put in one block, he will lose.

Maybe for some games 101 blocks draw interval is too long for their requirement, and need shorter draw time, the solution is as following:

Ticket result will be drawn by 2 delegates:

The first delegate's random number is only in charge of producing a number X, which is between 1 to 3, and that X will determine the Xth block after him will draw the result random for the ticket. The 2th delegate could be the evil guy who is trying to attack, but he can not predict who will produce the right drawing block before 4 blocks, his attack cost is (3 * block_ticket_sale), but his expect return is still only 1 block_ticket_sale. The only thing game rule need is to set the draw interval 1 block before the first delegate.

Note: block_ticket_sale means all the ticket sale the evil delegate buy in one block.

 
« Last Edit: August 08, 2014, 02:42:50 pm by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.