Quote from: bytemaster on September 27, 2014, 01:50:57 PM
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?

Quote from: bytemaster on September 27, 2014, 01:54:22 PM
Also.. if two delegates collude then they can win 100% of the time.

See https://bitsharestalk.org/index.php?topic=9393.msg122049#msg122049

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 :(

Quote from: bytemaster on September 27, 2014, 01:50:57 PM
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.

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.

Also.. if two delegates collude then they can win 100% of the time.   

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 :)

Quote from: xeroc on September 27, 2014, 09:44:01 AM
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

Quote from: zhangweis on September 27, 2014, 01:42:11 PM

Quote from: bytemaster on September 27, 2014, 01:40:18 PM
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 :)

Quote from: bytemaster on September 27, 2014, 01:40:18 PM
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 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.

"Building like a hurrricaaaane, yeahh" mosh mosh mosh, stagedive, crowdsurf, falling, beer, mosh mosh :D

that one came from nowhere .. awesome!!

+1!

Sent from my SCH-I535 using Tapatalk