Author Topic: JDS (Just Dice Style Shares) Dry Run #1  (Read 9195 times)

0 Members and 1 Guest are viewing this topic.

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
I really like this adjustment.... the primary challenge is deciding who goes next in the event of a missed block.  You would have to "shuffle all remaining delegates".  Then what happens when the "short list" of delegates are all inactive. 

I will choose to shuffle bottom n not top n. Then n is not based on block index but slot index. Then missed delegates will still stay in top but time slot will pass and the one after it will take the chance. Of course I will need to find block signee in the list to determine the slot index the current block is on.
Weibo:http://weibo.com/zhangweis

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
Before I find a better way, I'll simply adjust the blocks to wait as below:

The more you bet, the more you wait.

If you're betting small, you get the result after 2 blocks. If you're betting bigger, you may need to wait for 3,4,...,50 blocks for the result.
Weibo:http://weibo.com/zhangweis

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
I really like this adjustment.... the primary challenge is deciding who goes next in the event of a missed block.  You would have to "shuffle all remaining delegates".  Then what happens when the "short list" of delegates are all inactive. 

Start out with 100 delegates...
Shuffle the top 100
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 99
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 98
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 97
...
Shuffle the top 1
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 100

This would prevent a delegate from controlling everything while still keeping things random.

However you still have the probability that 2 delegates can collude to "always win". 

If "by chance" they see their two delegates back to back they can place a winning transaction. 

Your security is always going to be proportional to the number of individuals required to collude and what your tolerance is for that.

Hmm. You're right about the tolernce of number of individuals required to collude. As long as random is decided including the last delegate's secret, the delegate can know in advance the next delegate and if it's in  its control, they have the chance to collude.

Well, it's not acceptable for delegates to collude and it's also not acceptable for more than 2 blocks as fast feedback is key for this DAC. I'll look for other solutions like the one suggested by FreeTrade.
Weibo:http://weibo.com/zhangweis

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
I really like this adjustment.... the primary challenge is deciding who goes next in the event of a missed block.  You would have to "shuffle all remaining delegates".  Then what happens when the "short list" of delegates are all inactive. 

Start out with 100 delegates...
Shuffle the top 100
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 99
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 98
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 97
...
Shuffle the top 1
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 100

This would prevent a delegate from controlling everything while still keeping things random.

However you still have the probability that 2 delegates can collude to "always win". 

If "by chance" they see their two delegates back to back they can place a winning transaction. 

Your security is always going to be proportional to the number of individuals required to collude and what your tolerance is for that.

In case "short list" are all inactive we can simply choose from delegates who have already produced blocks or start another round. Actually I use "50" in a round to avoid this (50 inactive will hardly happen) and also to avoid colludes as the remaining delegates are always >= 50.

Edit: I mean 50 in a round but selection is from 100 top delegates:

Start out with 100 delegates...
Shuffle the top 100
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 99
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 98
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 97
...
Shuffle the top 51
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 100
« Last Edit: September 27, 2014, 11:57:36 pm by zhangweis »
Weibo:http://weibo.com/zhangweis

Offline bytemaster

If you randomly select a new delegate each round then a delegate can take over all block production if the get two back to back slots by mining their secret.

Yes, you're right. Delegate can generate bunch of secrets and pick one which is appropriate to make him next one. Then we may still need more than 1 delegate in 1 round but the next delegate will still be decided based on this block's random. Let's say 50 delegates in 1 round and each delegate can produce only 1 block in 1 round. We can achieve this by excluding delegates who have already produced blocks in this round in next delegate choosing.

I really like this adjustment.... the primary challenge is deciding who goes next in the event of a missed block.  You would have to "shuffle all remaining delegates".  Then what happens when the "short list" of delegates are all inactive. 

Start out with 100 delegates...
Shuffle the top 100
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 99
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 98
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 97
...
Shuffle the top 1
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 100

This would prevent a delegate from controlling everything while still keeping things random.

However you still have the probability that 2 delegates can collude to "always win". 

If "by chance" they see their two delegates back to back they can place a winning transaction. 

Your security is always going to be proportional to the number of individuals required to collude and what your tolerance is for that.
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 zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
If you randomly select a new delegate each round then a delegate can take over all block production if the get two back to back slots by mining their secret.

Yes, you're right. Delegate can generate bunch of secrets and pick one which is appropriate to make him next one. Then we may still need more than 1 delegate in 1 round but the next delegate will still be decided based on this block's random. Let's say 50 delegates in 1 round and each delegate can produce only 1 block in 1 round. We can achieve this by excluding delegates who have already produced blocks in this round in next delegate choosing.
Weibo:http://weibo.com/zhangweis

Offline bytemaster

I don't think you can have secure random numbers in 2 blocks without some massive complexity like FreeTrade suggested. 
You cannot randomize delegate selection every block (it was done in rounds for a reason). 
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 callmeluc

  • Hero Member
  • *****
  • Posts: 552
    • View Profile
BTS_自扯自淡

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline bytemaster

I prefer something like crosschain bitUSD but don't know whether it's easy to do. I want to make jds simple and will try to remove market related parts at least from UI.

Cross-chain trading would allow JUSD <-> XUSD and both would be "BitUSD" in the concept, just backed by different chains.   
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
looks better now .. thanks for the hint

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
it's not compiling:
clang and gcc :(
I'm using debian/gcc and tried building from a clean env. and the compilation works. Can it be a bug from fc version? Can you try to get latest fc code?
Weibo:http://weibo.com/zhangweis

Offline bytemaster


The DAC heavily used code from HackFisher https://github.com/bitsuperlab/bitshares_play/tree/dice. Thanks HackFisher. As the goal of this DAC is simple and quick, it's not integrated into Play for the moment.

To better avoid delegates cheating, I plan to randomly select next delegate from top 101. This means only 1 delegate in one round. But that is not a priority and can be implemented later.

If you randomly select a new delegate each round then a delegate can take over all block production if the get two back to back slots by mining their secret. 
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 zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
I prefer something like crosschain bitUSD but don't know whether it's easy to do. I want to make jds simple and will try to remove market related parts at least from UI.
Weibo:http://weibo.com/zhangweis

Offline bytemaster

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.