0 Members and 1 Guest are viewing this topic.
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 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 100Produce 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 1Produce a block, the delegate that produced the block goes to the end.Shuffle the top 100This 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.
Quote from: bytemaster on September 27, 2014, 03:31:22 pmIf 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.
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.
it's not compiling:clang and gcc
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.
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.
[ 30%] Building CXX object libraries/fc/CMakeFiles/fc.dir/src/thread/thread.cpp.oIn 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' failedmake[2]: *** [libraries/fc/CMakeFiles/fc.dir/src/thread/thread.cpp.o] Error 1CMakeFiles/Makefile2:196: recipe for target 'libraries/fc/CMakeFiles/fc.dir/all' failedmake[1]: *** [libraries/fc/CMakeFiles/fc.dir/all] Error 2Makefile:76: recipe for target 'all' failedmake: *** [all] Error 2
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: $10Payout: $100Chance 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
that one came from nowhere .. awesome!!
Quote from: bytemaster on September 27, 2014, 01:40:18 pmIt 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.