BitShares Forum
Main => General Discussion => Topic started by: zhangweis on September 27, 2014, 01:46:26 am
-
This dry run is over and dry run #2 is started at https://bitsharestalk.org/index.php?topic=9758.msg126678#msg126678 (https://bitsharestalk.org/index.php?topic=9758.msg126678#msg126678)
- shares allocation is planned to distribute like DNS which might be changed later. (20%PTS/20%AGS/10%Dev/50%Delegates
- 5 sec. block interval
- 2 blocks to get dice result which averages 7.5 seconds.
- winning bets adds to shares supply which means all the share holders will pay the cost. losing bets are burnt which means all the share holders share the profit.
https://github.com/zhangweis/jds
build instructions are similar with btsx.
Screenshot:
(http://www.webpagescreenshot.info/i3/542607f60b76c9-36955432)
-
Test account private key 5JBLNgtSSBAzsq6bXkqpDyNn64kmp6nDepyM798a2dZLdyHThbf. Please don't empty it.
It's better to use GUI but if you want to use console you can do as below:
wallet_dice "<account_name>" 100 2 true
Roll dice using account 100 JDS and payout as 2, roll high.
wallet_account_dice_transaction_history to view the result.
-
thats freaking awesome! +5% +5% +5% +5% +5% love you!
-
+5%
-
+5% Awesome!!!
-
+5% +5%
-
+5% +5% +5% HackFisher + zhangweis = Dream Team :)
-
+1!
Sent from my SCH-I535 using Tapatalk
-
that one came from nowhere .. awesome!!
-
"Building like a hurrricaaaane, yeahh" mosh mosh mosh, stagedive, crowdsurf, falling, beer, mosh mosh :D
-
The DAC heavily used code from HackFisher https://github.com/bitsuperlab/bitshares_play/tree/dice (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.
-
It averages 15 seconds... 5 seconds for the first block, 2nd block takes the full 10 seconds.
-
It averages 15 seconds... 5 seconds for the first block, 2nd block takes the full 10 seconds.
The block interval is set to 5 seconds for experiment of responsiveness. That's the shortest time interval I dare to use.
-
It averages 15 seconds... 5 seconds for the first block, 2nd block takes the full 10 seconds.
The block interval is set to 5 seconds for experiment of responsiveness. That's the shortest time interval I dare to use.
Right.. my bad... 5 seconds is really pushing it :)
-
that one came from nowhere .. awesome!!
This Chinese thread explains the idea more in details and progress. I hope google translate understands it.
https://bitsharestalk.org/index.php?topic=8973.0 (https://bitsharestalk.org/index.php?topic=8973.0)
-
You're Odds look wrong...
The probability of being greater than 49.5 is more than 50%... so I could be greater and win on average based on your screen shot.
I would recommend deriving chance to win and threshold from payout...
BET: $10
Payout: $100
Chance to win 1/100 * .99 (ie: dice < .0099)
I would also restrict the currency for betting to BitUSD on your network.... this will drive demand for BitUSD :)
-
Also.. if two delegates collude then they can win 100% of the time.
-
Another plan is to refactor code to be able to accept latest changes from upstream more easily. For the moment, many changes need to be done in original hpp and cpp files (like client.cpp, client.hpp, chain_database.cpp, chain_database.hpp,..etc.) and this makes update to latest upstream code difficult. API part is almost allowed to easily add extensions. My rough idea is to use classes inherited from these classes but I need time to figure out which is the best to way to do that.
-
You're Odds look wrong...
The probability of being greater than 49.5 is more than 50%... so I could be greater and win on average based on your screen shot.
I would recommend deriving chance to win and threshold from payout...
BET: $10
Payout: $100
Chance to win 1/100 * .99 (ie: dice < .0099)
I would also restrict the currency for betting to BitUSD on your network.... this will drive demand for BitUSD :)
It's a bug in UI display and it should be >50.5 or <49.5.
-
it's not compiling:
[ 30%] Building CXX object libraries/fc/CMakeFiles/fc.dir/src/thread/thread.cpp.o
In file included from /usr/include/boost/atomic.hpp:12:0,
from /usr/include/boost/thread/pthread/once_atomic.hpp:20,
from /usr/include/boost/thread/once.hpp:20,
from /usr/include/boost/thread.hpp:17,
from /tmp/jds/libraries/fc/src/thread/thread_d.hpp:4,
from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
/usr/include/boost/atomic/atomic.hpp:31:16: error: 'atomic' is already declared in this scope
using atomics::atomic;
^
In file included from /tmp/jds/libraries/fc/src/thread/thread_d.hpp:5:0,
from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
/tmp/jds/libraries/fc/src/thread/context.hpp: In constructor 'fc::context::context(void (*)(intptr_t), boost::coroutines::stack_allocator&, fc::thread*)':
/tmp/jds/libraries/fc/src/thread/context.hpp:58:27: error: 'default_stacksize' is not a member of 'boost::coroutines::stack_allocator {aka boost::coroutines::basic_standard_stack_allocator<boost::coroutines::stack_traits>}'
size_t stack_size = bco::stack_allocator::default_stacksize() * 4;
^
/tmp/jds/libraries/fc/src/thread/context.hpp:60:70: error: invalid conversion from 'boost::context::fcontext_t {aka void*}' to 'void**' [-fpermissive]
my_context = bc::make_fcontext( stack_ctx.sp, stack_ctx.size, sf);
^
libraries/fc/CMakeFiles/fc.dir/build.make:146: recipe for target 'libraries/fc/CMakeFiles/fc.dir/src/thread/thread.cpp.o' failed
make[2]: *** [libraries/fc/CMakeFiles/fc.dir/src/thread/thread.cpp.o] Error 1
CMakeFiles/Makefile2:196: recipe for target 'libraries/fc/CMakeFiles/fc.dir/all' failed
make[1]: *** [libraries/fc/CMakeFiles/fc.dir/all] Error 2
Makefile:76: recipe for target 'all' failed
make: *** [all] Error 2
clang and gcc :(
-
Also.. if two delegates collude then they can win 100% of the time.
See https://bitsharestalk.org/index.php?topic=9393.msg122049#msg122049 (https://bitsharestalk.org/index.php?topic=9393.msg122049#msg122049)
-
I would also restrict the currency for betting to BitUSD on your network.... this will drive demand for BitUSD :)
the BitUSD you mentioned here is from btsx or from jds? according to the discussion on music related threat, i believe u mean from jds. but if so, it will not drive the demand for btsx's BitUSD, correct?
-
Correct. JUSD.
-
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.
-
The DAC heavily used code from HackFisher https://github.com/bitsuperlab/bitshares_play/tree/dice (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.
-
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?
-
looks better now .. thanks for the hint
-
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.
-
awesome +5%
-
good job~
+5%
-
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).
-
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.
-
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.
-
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
-
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.
-
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.
-
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.