Author Topic: The way to resolve "The Last Evil Delegate Problem" in DPOS  (Read 12620 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.