Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - zhangweis

Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 ... 21
106
General Discussion / Re: JDS Dry Run #2
« on: October 14, 2014, 12:26:16 am »
Quote from: bytemaster on October 13, 2014, 08:22:09 pm
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.

107
General Discussion / Re: JDS Dry Run #2
« on: October 13, 2014, 03:31:21 am »
Quote from: bytemaster on October 12, 2014, 08:59:38 pm
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.

108
中文 (Chinese) / Re: JDS赌王大赛计划草案
« on: October 12, 2014, 08:05:39 am »
Quote from: xfund on October 12, 2014, 04:27:04 am
等ubuntu版本，我技术太菜

Ubuntu基本照到https://github.com/zhangweis/jds/blob/master/BUILD_UBUNTU.md弄就可以。

109
中文 (Chinese) / Re: JDS赌王大赛计划草案
« on: October 12, 2014, 08:04:33 am »
Quote from: rzshenwei on October 11, 2014, 08:27:57 am
抓紧出个win客户端吧
我没有windows编译环境。建议还是自己编译比较放心。争取弄个windows编译环境，编译一个试试。

110
General Discussion / Re: JDS Dry Run #2
« on: October 11, 2014, 02:06:39 pm »
Quote from: Riverhead on October 11, 2014, 12:05:11 pm
Quote from: zhangweis on October 11, 2014, 05:04:52 am
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.

111
General Discussion / Re: JDS Dry Run #2
« on: October 11, 2014, 02:02:49 pm »
Quote from: Shentist on October 11, 2014, 07:35:25 am
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.  8).
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.

112
中文 (Chinese) / Re: JustDice风格的骰子DAC提议(JDS)
« on: October 11, 2014, 01:57:23 pm »
Quote from: ssjpts on October 11, 2014, 12:26:05 pm
继续赞一个！GUI部分可否请3I内部人员协助帮忙？

GUI的话，是需要优化的，如果有渠道让3I内部人员协助，当然最好。
不过我觉得现在的界面太复杂了，比如字体太小等等。我的想法是等v2.0时从头开始写个简单好用的界面。

113
General Discussion / Re: A cross-chain idea derived from escrow
« on: October 11, 2014, 01:53:16 pm »
Quote from: emski on October 11, 2014, 10:21:09 am
You might want to check the following thread: https://bitsharestalk.org/index.php?topic=9075.0 .
There are several similar proposals extensively discussed. However I didn't notice much response. It almost looks like noone is interested or I'm extremely crappy presenter.

As I stated, the whole btsx network needs to watch BTC block chain which makes it impractical. Let me check other proposals.

114
中文 (Chinese) / JDS赌王大赛计划草案
« on: October 11, 2014, 05:08:28 am »
https://bitsharestalk.org/index.php?topic=9758.msg128899#msg128899

计划从Dry run 3开始每个dry run一次骰子比赛。希望大家多帮我测试下，谢谢。可以用dry run 2先熟悉熟悉。

115
General Discussion / Re: JDS Dry Run #2
« on: October 11, 2014, 05:04:52 am »
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.

How to participant:

Of course you'll need to build or get JDS bin. Paste your public key in thread and I'll send you 100,000 JDST to play with. All your dices on this key in this dry run will be sum to make your final dice balance. This can be got from blockchain_get_jackpot_transactions for each block.

When a dry run ends, I'll sort all the participants by their dice balances. Each one in the top 10 will be awarded with 100,000 JDS when JDS releases for their testing work. A valid winner must have dice count >= 10. If the number of valid winners is less than 10, every winner gets (1,000,000/valid winners).

You can participant multiple dry runs and win multiple dry runs.

Please keep your private key secure as I'll send JDS using your public key. You can use dry run 2 to get familar with building and playing.

116
General Discussion / Re: JDS Dry Run #2
« on: October 11, 2014, 05:01:11 am »
Quote from: Riverhead on October 11, 2014, 04:54:45 am
Eh, won't compile. It's late, I'll mess with it tomorrow.

Take your time. I'm preparing a dice competition which will be published later.

117
General Discussion / A cross-chain idea derived from escrow
« on: October 10, 2014, 11:50:40 pm »
I know very little about cross chain but it's interesting to think about. Forgive me if it's obvious, ridiculous or nonsense.

The idea works like escrow. Say A wants to trade with B for btsx with btc. A sends btsx to an escrow(C). C receives btsx and watch whether B has sent btc to A in specified time. If not, C sends btsx back to A. If yes, C sends btsx to B.

Here we can have the delegates(thus the btsx network) acting as escrow. That means btsx network need to know btc network. This is quite a burden and that's why it's not perfect. But at least btc network doesn't need to know anything about this. Maybe delegates can choose to directly use data from say blockchain.info.

The idea works like this:
A and B agrees on a crosschain transaction.
A sends a crosschain transaction (transferring 100 BTSX to B when a specified BTC transaction happens in 5 days).
B sees this transaction in btsx blockchain and is assured he can receive the btsx when btc transaction is done in time.
B sends btc to A as the transaction specified.
delegates see the btc transaction in 5 days, transfer the btsx to B.
if delegates don't see the btc transaction in 5 days, transfer the btsx back to A.

118
General Discussion / Re: JDS Dry Run #2
« on: October 10, 2014, 01:55:28 pm »
Quote from: Riverhead on October 10, 2014, 10:37:23 am
I'm running Ubuntu 14.04. I used the url from github itself if that helps anyone.

Thanks for the JDST :).

I'm not seeing the GUI in your screen shots. Just the stock Bitshares X wallet with JDST currency. I'll re-read the .ad's to see if I missed a step. To be honest I didn't read them and built it like Bitshares X.

Thanks for pointing out. It's my fault as I didn't know git submodule thing. Seems the submodule is still on a branch. I tried fixing that with "git submodule add -b master [URL to Git repo]" and hope it will work. Please do submodule init and update and let me know if it works or not.

119
General Discussion / Re: JDS Dry Run #2
« on: October 10, 2014, 01:17:35 pm »
My config.json for your reference if you want to do the same as me:

  "rpc": {
    "enable": true,
    "rpc_user": "xxxx",
    "rpc_password": "xxxxx",
    "rpc_endpoint": "127.0.0.1:0",
    "httpd_endpoint": "127.0.0.1:8088",
    "htdocs": "/home/xxxx/jds/dice_web_wallet/generated"
}
.....

With this config you can access it using http://localhost:8088/#/dice

120
General Discussion / Re: JDS Dry Run #2
« on: October 10, 2014, 01:14:03 pm »
Quote from: Riverhead on October 10, 2014, 10:37:23 am
I'm running Ubuntu 14.04. I used the url from github itself if that helps anyone.

Thanks for the JDST :).

I'm not seeing the GUI in your screen shots. Just the stock Bitshares X wallet with JDST currency. I'll re-read the .ad's to see if I missed a step. To be honest I didn't read them and built it like Bitshares X.

It should be the same. I cloned the UI in https://github.com/zhangweis/dice_web_wallet.git and put it in .gitmodules. The bitshares xts build instructions should be apply well on the web part.

For me for development reason, I cloned https://github.com/zhangweis/dice_web_wallet.git in ~/dice_web_wallet and I changed the config.json to enable rpc and assign user,pass and port, point htdocs to "htdocs": "~/dice_web_wallet/generated". In this way, I can "lineman build" for each change to take effect and I can also debug it in browser.

Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 ... 21

Page created in 0.199 seconds with 23 queries.