JDS Dry Run #2

[islandking]

Is there any update on this project?

[zhangweis]

There's a bug in the code and it should be:

Code: [Select]

      void chain_database_impl::update_active_delegate_list( const full_block& block_data,
                                                             const pending_chain_state_ptr& pending_state )
      {
          std::vector<account_id_type> active_del;
          if( block_data.block_num % BTS_BLOCKCHAIN_NUM_DELEGATES == 0 )
          {
             // perform a random shuffle of the sorted delegate list.

             active_del = self->next_round_active_delegates();
          } else {
              active_del = self->get_active_delegates();
          }
             auto rand_seed = fc::sha256::hash(self->get_current_random_seed());
             uint32_t block_index = block_data.block_num % BTS_BLOCKCHAIN_NUM_DELEGATES;
             size_t num_del = active_del.size();
uint32_t signee_delegate_index = -1;
if (block_index!=0) {
    //from 0 to where the block signee, we need to swap them to tail to ensure they can only particapant once in a round.
    public_key_type block_signee;
    block_signee = block_data.signee();
    //get delegate's active key
    for (uint32_t i=0;i<num_del;++i) {
        auto delegate_record = pending_state->get_account_record( active_del[i] );
        FC_ASSERT( delegate_record.valid() && delegate_record->is_delegate() );
       
        if (delegate_record->active_key()==block_signee) {
            signee_delegate_index = i;
            break;
        }
    }
}
             for( uint32_t i = signee_delegate_index+1; i < num_del; ++i )
             {
                for( uint32_t x = 0; x < 4 && i < num_del; ++x, ++i )
                   std::swap( active_del[i], active_del[[b]i+(rand_seed._hash[x]%(num_del-i))[/b]] );
                rand_seed = fc::sha256::hash(rand_seed);
             }

             pending_state->set_property( chain_property_enum::active_delegate_list_id, fc::variant(active_del) );
      }


[zhangweis]

You are making sure that a delegate can only participate in a round once on average. 

This means that a delegate does not know in advance when he will go...but when he does get to go he can mine his secrets to make sure he gets to go next....

So you have to wait until at least N delegates have gone before you can be secure.   You gain nothing by shuffling every time. 

If you want to gain something then you need delegates to commit in advance to 101 secrets to be revealed in time and then shuffle every turn.  A delegate would not be able to mine their secret on their turn because they have pre-committed to the next 101 secrets.

It's not 1 delegate in one round but still 50 delegates a round and shuffle the rest delegates after each block.

[zhangweis]

You are making sure that a delegate can only participate in a round once on average. 

This means that a delegate does not know in advance when he will go...but when he does get to go he can mine his secrets to make sure he gets to go next....

So you have to wait until at least N delegates have gone before you can be secure.   You gain nothing by shuffling every time. 

If you want to gain something then you need delegates to commit in advance to 101 secrets to be revealed in time and then shuffle every turn.  A delegate would not be able to mine their secret on their turn because they have pre-committed to the next 101 secrets.

Correct me if I'm wrong as I'm not so familiar with the code.
For mining, you can see from the code that I'm shuffling the rest delegates after the signing delegate. The signing delegate will be excluded in this round and he can't mine before hand because his secret will only be used in next round and he needs to know all the other delegates' secrets to mine. This works like below:
1st delegate of shuffled top 100 signs the block, shuffle the rest 99 delegates.
2nd delegate of shuffled top 100 signs the block, shuffle the rest 98 delegates.
3nd delegate of shuffled top 100 signs the block, shuffle the rest 97 delegates.
...
50th delegate of shuffled top 100 signs the block, shuffle the rest 50 delegates.
1st delegate of shuffled top 100 signs the block, shuffle the rest 99 delegates.

From my understanding, every delegates commits their secrets by showing hash of secrets. Then reveal their secrets in the their round. I checked the code of chain_database_impl::update_delegate_production_info and wallet::sign_block to understand the way secret works.

[bytemaster]

You are making sure that a delegate can only participate in a round once on average. 

This means that a delegate does not know in advance when he will go...but when he does get to go he can mine his secrets to make sure he gets to go next....

So you have to wait until at least N delegates have gone before you can be secure.   You gain nothing by shuffling every time. 

If you want to gain something then you need delegates to commit in advance to 101 secrets to be revealed in time and then shuffle every turn.  A delegate would not be able to mine their secret on their turn because they have pre-committed to the next 101 secrets. 

[zhangweis]

We have already established that you cannot shuffle after each block.

Can you give more details on this as this is really important for this DAC? Or can you review the changes I made to chain_database_impl::update_active_delegate_list:

Code: [Select]

      void chain_database_impl::update_active_delegate_list( const full_block& block_data,
                                                             const pending_chain_state_ptr& pending_state )
      {
          std::vector<account_id_type> active_del;
          if( block_data.block_num % BTS_BLOCKCHAIN_NUM_DELEGATES == 0 )
          {
             // perform a random shuffle of the sorted delegate list.

             active_del = self->next_round_active_delegates();
          } else {
              active_del = self->get_active_delegates();
          }
             auto rand_seed = fc::sha256::hash(self->get_current_random_seed());
             uint32_t block_index = block_data.block_num % BTS_BLOCKCHAIN_NUM_DELEGATES;
             size_t num_del = active_del.size();
uint32_t signee_delegate_index = -1;
if (block_index!=0) {
    //from 0 to where the block signee, we need to swap them to tail to ensure they can only particapant once in a round.
    public_key_type block_signee;
    block_signee = block_data.signee();
    //get delegate's active key
    for (uint32_t i=0;i<num_del;++i) {
        auto delegate_record = pending_state->get_account_record( active_del[i] );
        FC_ASSERT( delegate_record.valid() && delegate_record->is_delegate() );
       
        if (delegate_record->active_key()==block_signee) {
            signee_delegate_index = i;
            break;
        }
    }
}
             for( uint32_t i = signee_delegate_index+1; i < num_del; ++i )
             {
                for( uint32_t x = 0; x < 4 && i < num_del; ++x, ++i )
                   std::swap( active_del[i], active_del[rand_seed._hash[x]%num_del] );
                rand_seed = fc::sha256::hash(rand_seed);
             }

             pending_state->set_property( chain_property_enum::active_delegate_list_id, fc::variant(active_del) );
      }

Edit: get_active_delegates() will return top 2*BTS_BLOCKCHAIN_NUM_DELEGATES delegates.

[bytemaster]

Changes:

Improved UI:
It shows progress and how many blocks to get result for each dice in progress.

Improved security against delegates collusion:
The more amount you dice, the more blocks you have to wait for the jackpot. The block count calculation is roughly like below:
jackpot blocks = min(MAX_WAIT_BLOCKS,payout / delegate income)
MAX_WAIT_BLOCKS is currently set to 50.
Say, if you dice 100JDS with payout 20, and the delegate's income of the current block is 200, you'll need to wait for 10 blocks for the result.   
All the dices in the same block are sorted by payout and accumulated for the calculation of packout blocks.
Say we have 3 dices:[50@10, 100@2, 500@2].
We get payouts [500, 200, 1000] and they're sorted as [200,500,1000].
For 100@2, the accumulated amount is 200 and jackpot is 2 blocks.
For 50@10, the accumulated amount is 200+500=700 and jackpot is 4 blocks.
For 500@2, the accumulated amount is 200+500+1000=1700 and jackpot is 9 blocks.

The plan is to shuffle delegates after each block to improve security.

Original dry run info.:

We have already established that you cannot shuffle after each block. 

[Shentist]

Dice competition draft plan:

To encourage the participation of dry run testing, I'd like to host a dice competition for each dry run from dry run 03.

Very cool!!

One hole is that you can apply for many accounts, and dice all money with each of them. Any idea how to avoid this? Should we limit the participant number to something like 50? Or should we limit 1 account every forum account? Neither can prevent this.

1. you could limit it to forum user with accounts older then 2 month
- if you "operate" multiply accounts on this forum - you deserve the chance to do it in more then one try

what about to apply a little bit of change?

1. 1.000.000 JDS are the starting pricepool of the dry runs
2. after the first 50 participating people the winningpool will increase for each 5 people with 100.000 JDS and the first 10 will still recieve the shares

but with how many people could you count? how many people were in the dry run of DNS? do anyone now the numbers?

[Gentso1]

AGS funds come a donation address and thus can't be moved. We are trying to come up with a way to claim AGS stakes without importing the private key, into a DAC.

https://bitsharestalk.org/index.php?topic=9318.0

Thanks for this, the thread on mirror chains showed a promising solution. Hopefully it will be able to be put into the toolkit directly.

[xeroc]

AGS funds come a donation address and thus can't be moved. We are trying to come up with a way to claim AGS stakes without importing the private key, into a DAC.

https://bitsharestalk.org/index.php?topic=9318.0

[Gentso1]

Can you also comment on this thread? https://bitsharestalk.org/index.php?topic=8916.new#new

A lot of concern about putting private keys into new DACs to claim distribution. Since this thread is about the previous lotto DAC you may already be following.

Sorry I don't follow much about this DAC. The last time I checked it, it seemed not based on BTS code but some POW code.
I can understand the concern about putting private keys to claim distribution. I think the cold storage solution can solve this elegantly but as it's not fully ready I have the idea that we can have the private keys to sign something like "claim JDS to JDSxxxxx" to move the fund to another (newly created) account.

AGS funds come a donation address and thus can't be moved. We are trying to come up with a way to claim AGS stakes without importing the private key, into a DAC.

[zhangweis]

Dice competition draft plan:

To encourage the participation of dry run testing, I'd like to host a dice competition for each dry run from dry run 03.

Very cool!!

One hole is that you can apply for many accounts, and dice all money with each of them. Any idea how to avoid this? Should we limit the participant number to something like 50? Or should we limit 1 account every forum account? Neither can prevent this.

[zhangweis]

i just wanted to make the same/similar proposal.

could you say something to the amount of shares of the initial genesis distribution? You wrote you wanted a similar allocation then DNS is this still in effect?

so 5 Bn with starting and 5 Bn through delegate dilution?


i will try to help on the dry run, but never did before something to build the sources from github.

That's great you have the same head as mine. The distribution plan hasn't changed and 5Bn as start with rest 5Bn through delegate dilution. Actually I copied the delegate pay code from DNS.  .
Building is something tricky but believe me I was also not experienced in this but with 3I's instructions, I made it in the 3rd try. It's better to use ubuntu with same version stated in BUILD_UBUNTU.md as I had been stuck at some 3rd party library version issue.

[Riverhead]

Dice competition draft plan:

To encourage the participation of dry run testing, I'd like to host a dice competition for each dry run from dry run 03.

Very cool!!

[Shentist]

i just wanted to make the same/similar proposal.

could you say something to the amount of shares of the initial genesis distribution? You wrote you wanted a similar allocation then DNS is this still in effect?

so 5 Bn with starting and 5 Bn through delegate dilution?


i will try to help on the dry run, but never did before something to build the sources from github.