BitShares Forum
Main => General Discussion => Topic started by: zhangweis on October 06, 2014, 04:33:02 pm
-
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.:
https://bitsharestalk.org/index.php?topic=9393.0 (https://bitsharestalk.org/index.php?topic=9393.0)
(http://www.webpagescreenshot.info/i3/5432bfe2edb628-13370369)
-
+5% +5%
-
赞一个，支持。
-
great project. looks promising
-
Seems great +5%
-
support
-
Nice DAC 8) +5% +5% +5%
-
[Update]:
Shuffling delegates after every block is implemented and under tests.
-
I see there are 17 dry runs. Are they place holders? Do you want any testing done? I build the source but the blockchain wasn't active. I did DR17 since it was the biggest number haha. Looking forward to this DAC.
-
I see there are 17 dry runs. Are they place holders? Do you want any testing done? I build the source but the blockchain wasn't active. I did DR17 since it was the biggest number haha. Looking forward to this DAC.
I cloned it from btsx and I'm using master.
-
I see there are 17 dry runs. Are they place holders? Do you want any testing done? I build the source but the blockchain wasn't active. I did DR17 since it was the biggest number haha. Looking forward to this DAC.
I cloned it from btsx and I'm using master.
Thank you. Sorry if I jumped the gun. Just excited to see this in action. :)
-
Thank you. Sorry if I jumped the gun. Just excited to see this in action. :)
Thanks for trying.
Currently it has very low testing participation and I'm trying to find a way to promote testing participation as most big changes have been done.
-
Do you want me to bring it up at Friday's "State of the Blockchain" Mumble session? We can get you testers if that's what you need.
-
Do you want me to bring it up at Friday's "State of the Blockchain" Mumble session? We can get you testers if that's what you need.
Sure, I'd appreciate that and I'm also thinking of a JDST dice tournament to promote this.
-
how can i help?
where can i find the client?
maybe start with 1 official thread with links. i couldn't find something to download the client
-
how can i help?
where can i find the client?
maybe start with 1 official thread with links. i couldn't find something to download the client
It's still in the dry run phase. How comfortable are you building from github?
https://github.com/zhangweis/jds
-
hehe
never did it.
but i will dry.
can you point me to a explaination`?
-
No time like the first time :).
Here are the instructions for BitSharesX. Since JDS is based on the bitshares_toolkit the steps will be nearly if not completely the same.
http://wiki.bitshares.org/index.php/BuildInstructionsBitSharesX
-
No time like the first time :).
Here are the instructions for BitSharesX. Since JDS is based on the bitshares_toolkit the steps will be nearly if not completely the same.
http://wiki.bitshares.org/index.php/BuildInstructionsBitSharesX
You can also follow https://github.com/zhangweis/jds/blob/master/BUILD_UBUNTU.md (https://github.com/zhangweis/jds/blob/master/BUILD_UBUNTU.md) if you're using ubuntu. I only changed the git repository url.
-
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.
-
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.
-
Build fails for me:
[ 73%] Building CXX object libraries/net/CMakeFiles/bts_net.dir/message_oriented_connection.cpp.o
/home/peter/rpmbuild/BUILD/jds-master/libraries/net/message_oriented_connection.cpp:31:19: error: cannot declare field 'bts::net::detail::message_oriented_connection_impl::_sock' to be of abstract type 'bts::net::stcp_socket'
In file included from /home/peter/rpmbuild/BUILD/jds-master/libraries/net/message_oriented_connection.cpp:9:0:
/home/peter/rpmbuild/BUILD/jds-master/libraries/net/include/bts/net/stcp_socket.hpp:12:7: note: because the following virtual functions are pure within 'bts::net::stcp_socket':
In file included from /usr/include/fc/network/tcp_socket.hpp:4:0,
from /home/peter/rpmbuild/BUILD/jds-master/libraries/net/include/bts/net/message_oriented_connection.hpp:2,
from /home/peter/rpmbuild/BUILD/jds-master/libraries/net/message_oriented_connection.cpp:8:
/usr/include/fc/io/iostream.hpp:24:26: note: virtual std::size_t fc::istream::readsome(const std::shared_ptr<char>&, std::size_t, std::size_t)
/usr/include/fc/io/iostream.hpp:46:27: note: virtual std::size_t fc::ostream::writesome(const std::shared_ptr<const char>&, std::size_t, std::size_t)
/home/peter/rpmbuild/BUILD/jds-master/libraries/net/message_oriented_connection.cpp: In member function 'void bts::net::detail::message_oriented_connection_impl::read_loop()':
/home/peter/rpmbuild/BUILD/jds-master/libraries/net/message_oriented_connection.cpp:143:57: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
-
Build fails for me:
[ 73%] Building CXX object libraries/net/CMakeFiles/bts_net.dir/message_oriented_connection.cpp.o
/home/peter/rpmbuild/BUILD/jds-master/libraries/net/message_oriented_connection.cpp:31:19: error: cannot declare field 'bts::net::detail::message_oriented_connection_impl::_sock' to be of abstract type 'bts::net::stcp_socket'
In file included from /home/peter/rpmbuild/BUILD/jds-master/libraries/net/message_oriented_connection.cpp:9:0:
/home/peter/rpmbuild/BUILD/jds-master/libraries/net/include/bts/net/stcp_socket.hpp:12:7: note: because the following virtual functions are pure within 'bts::net::stcp_socket':
In file included from /usr/include/fc/network/tcp_socket.hpp:4:0,
from /home/peter/rpmbuild/BUILD/jds-master/libraries/net/include/bts/net/message_oriented_connection.hpp:2,
from /home/peter/rpmbuild/BUILD/jds-master/libraries/net/message_oriented_connection.cpp:8:
/usr/include/fc/io/iostream.hpp:24:26: note: virtual std::size_t fc::istream::readsome(const std::shared_ptr<char>&, std::size_t, std::size_t)
/usr/include/fc/io/iostream.hpp:46:27: note: virtual std::size_t fc::ostream::writesome(const std::shared_ptr<const char>&, std::size_t, std::size_t)
/home/peter/rpmbuild/BUILD/jds-master/libraries/net/message_oriented_connection.cpp: In member function 'void bts::net::detail::message_oriented_connection_impl::read_loop()':
/home/peter/rpmbuild/BUILD/jds-master/libraries/net/message_oriented_connection.cpp:143:57: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Are you on master? Have you tried "git submodule init" and "git submodule update"?
-
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. It's in json, that's why it's better to use GUI .
-
I am still getting a compile error:
[ 30%] Building CXX object libraries/fc/CMakeFiles/fc.dir/src/thread/thread.cpp.o
In file included from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
In file included from /tmp/jds/libraries/fc/src/thread/thread_d.hpp:4:
In file included from /usr/include/boost/thread.hpp:17:
In file included from /usr/include/boost/thread/once.hpp:20:
In file included from /usr/include/boost/thread/pthread/once_atomic.hpp:20:
In file included from /usr/include/boost/atomic.hpp:12:
/usr/include/boost/atomic/atomic.hpp:31:16: error: target of using declaration conflicts with declaration already in scope
using atomics::atomic;
^
/usr/include/boost/atomic/detail/atomic_template.hpp:668:7: note: target of using declaration
class atomic :
^
/tmp/jds/libraries/fc/include/fc/thread/spin_yield_lock.hpp:4:30: note: conflicting declaration
template<typename T> class atomic;
^
In file included from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
In file included from /tmp/jds/libraries/fc/src/thread/thread_d.hpp:5:
/tmp/jds/libraries/fc/src/thread/context.hpp:58:49: error: no member named 'default_stacksize' in '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:17: error: assigning to 'bc::fcontext_t *' (aka 'void **') from incompatible type 'fcontext_t' (aka 'void *')
my_context = bc::make_fcontext( stack_ctx.sp, stack_ctx.size, sf);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
/tmp/jds/libraries/fc/src/thread/thread_d.hpp:74:44: error: implicit instantiation of undefined template 'boost::atomic<fc::task_base *>'
boost::atomic<task_base*> task_in_queue;
^
/tmp/jds/libraries/fc/include/fc/thread/spin_yield_lock.hpp:4:30: note: template is declared here
template<typename T> class atomic;
^
In file included from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
/tmp/jds/libraries/fc/src/thread/thread_d.hpp:34:41: error: implicit instantiation of undefined template 'boost::atomic<int>'
static boost::atomic<int> cnt(0);
^
/tmp/jds/libraries/fc/include/fc/thread/spin_yield_lock.hpp:4:30: note: template is declared here
template<typename T> class atomic;
^
5 errors generated.
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
-
Are you on master? Have you tried "git submodule init" and "git submodule update"?
My fault, sorry. Wrong fc version.
-
I am still getting a compile error:
[ 30%] Building CXX object libraries/fc/CMakeFiles/fc.dir/src/thread/thread.cpp.o
In file included from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
In file included from /tmp/jds/libraries/fc/src/thread/thread_d.hpp:4:
In file included from /usr/include/boost/thread.hpp:17:
In file included from /usr/include/boost/thread/once.hpp:20:
In file included from /usr/include/boost/thread/pthread/once_atomic.hpp:20:
In file included from /usr/include/boost/atomic.hpp:12:
/usr/include/boost/atomic/atomic.hpp:31:16: error: target of using declaration conflicts with declaration already in scope
using atomics::atomic;
^
/usr/include/boost/atomic/detail/atomic_template.hpp:668:7: note: target of using declaration
class atomic :
^
/tmp/jds/libraries/fc/include/fc/thread/spin_yield_lock.hpp:4:30: note: conflicting declaration
template<typename T> class atomic;
^
In file included from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
In file included from /tmp/jds/libraries/fc/src/thread/thread_d.hpp:5:
/tmp/jds/libraries/fc/src/thread/context.hpp:58:49: error: no member named 'default_stacksize' in '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:17: error: assigning to 'bc::fcontext_t *' (aka 'void **') from incompatible type 'fcontext_t' (aka 'void *')
my_context = bc::make_fcontext( stack_ctx.sp, stack_ctx.size, sf);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
/tmp/jds/libraries/fc/src/thread/thread_d.hpp:74:44: error: implicit instantiation of undefined template 'boost::atomic<fc::task_base *>'
boost::atomic<task_base*> task_in_queue;
^
/tmp/jds/libraries/fc/include/fc/thread/spin_yield_lock.hpp:4:30: note: template is declared here
template<typename T> class atomic;
^
In file included from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
/tmp/jds/libraries/fc/src/thread/thread_d.hpp:34:41: error: implicit instantiation of undefined template 'boost::atomic<int>'
static boost::atomic<int> cnt(0);
^
/tmp/jds/libraries/fc/include/fc/thread/spin_yield_lock.hpp:4:30: note: template is declared here
template<typename T> class atomic;
^
5 errors generated.
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
Can you try from a fresh start? like removing the jds folder and git clone, git submodule init, git submodule update, cmake ., make.
-
I am still getting a compile error:
[ 30%] Building CXX object libraries/fc/CMakeFiles/fc.dir/src/thread/thread.cpp.o
In file included from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
In file included from /tmp/jds/libraries/fc/src/thread/thread_d.hpp:4:
In file included from /usr/include/boost/thread.hpp:17:
In file included from /usr/include/boost/thread/once.hpp:20:
In file included from /usr/include/boost/thread/pthread/once_atomic.hpp:20:
In file included from /usr/include/boost/atomic.hpp:12:
/usr/include/boost/atomic/atomic.hpp:31:16: error: target of using declaration conflicts with declaration already in scope
using atomics::atomic;
^
/usr/include/boost/atomic/detail/atomic_template.hpp:668:7: note: target of using declaration
class atomic :
^
/tmp/jds/libraries/fc/include/fc/thread/spin_yield_lock.hpp:4:30: note: conflicting declaration
template<typename T> class atomic;
^
In file included from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
In file included from /tmp/jds/libraries/fc/src/thread/thread_d.hpp:5:
/tmp/jds/libraries/fc/src/thread/context.hpp:58:49: error: no member named 'default_stacksize' in '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:17: error: assigning to 'bc::fcontext_t *' (aka 'void **') from incompatible type 'fcontext_t' (aka 'void *')
my_context = bc::make_fcontext( stack_ctx.sp, stack_ctx.size, sf);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
/tmp/jds/libraries/fc/src/thread/thread_d.hpp:74:44: error: implicit instantiation of undefined template 'boost::atomic<fc::task_base *>'
boost::atomic<task_base*> task_in_queue;
^
/tmp/jds/libraries/fc/include/fc/thread/spin_yield_lock.hpp:4:30: note: template is declared here
template<typename T> class atomic;
^
In file included from /tmp/jds/libraries/fc/src/thread/thread.cpp:5:
/tmp/jds/libraries/fc/src/thread/thread_d.hpp:34:41: error: implicit instantiation of undefined template 'boost::atomic<int>'
static boost::atomic<int> cnt(0);
^
/tmp/jds/libraries/fc/include/fc/thread/spin_yield_lock.hpp:4:30: note: template is declared here
template<typename T> class atomic;
^
5 errors generated.
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
Can you try from a fresh start? like removing the jds folder and git clone, git submodule init, git submodule update, cmake ., make.
I have the same problems as xeroc...
I deleted the bitshares_toolkit (jds) directory and have begin from the start but with no succes!
[ 75%] Building CXX object libraries/blockchain/CMakeFiles/bts_blockchain.dir/time.cpp.o
[ 75%] Building CXX object libraries/blockchain/CMakeFiles/bts_blockchain.dir/extended_address.cpp.o
[ 76%] Building CXX object libraries/blockchain/CMakeFiles/bts_blockchain.dir/address.cpp.o
[ 76%] Building CXX object libraries/blockchain/CMakeFiles/bts_blockchain.dir/pts_address.cpp.o
[ 77%] Building CXX object libraries/blockchain/CMakeFiles/bts_blockchain.dir/asset.cpp.o
/home/liondani/bitshares_toolkit/libraries/blockchain/asset.cpp: In function ‘bts::blockchain::asset bts::blockchain::operator*(const bts::blockchain::asset&, const bts::blockchain::price&)’:
/home/liondani/bitshares_toolkit/libraries/blockchain/asset.cpp:216:24: error: cannot convert ‘fc::bigint’ to ‘bts::blockchain::share_type {aka long int}’ in assignment
rtn.amount = amnt;
^
/home/liondani/bitshares_toolkit/libraries/blockchain/asset.cpp:241:25: error: cannot convert ‘fc::bigint’ to ‘bts::blockchain::share_type {aka long int}’ in assignment
r.amount = result;
^
make[2]: *** [libraries/blockchain/CMakeFiles/bts_blockchain.dir/asset.cpp.o] Error 1
make[1]: *** [libraries/blockchain/CMakeFiles/bts_blockchain.dir/all] Error 2
make: *** [all] Error 2
liondani@liondani-GA-770T-D3L ~/bitshares_toolkit $
-
Built here without issue.
riverdice - JDST6t2MrADeGpACfRm5Nm3unEkH82dvdvxwKCECNV8coVoywuWuJ9
Also, is this the right blockchain?
"blockchain_id": "9329bb6fbb5d6fbc0e0872dd306536f66ea53250ee1e00602cb36bff05eff842",
"symbol": "JDST",
"name": "BitShares JDST",
"version": 109,
"db_version": 133,
"genesis_timestamp": "2014-06-20T14:40:27",
-
Can you try from a fresh start? like removing the jds folder and git clone, git submodule init, git submodule update, cmake ., make.
it has been a fresh checkout ..
I am running on boost 1.56.0
-
it has been a fresh checkout ..
I am running on boost 1.56.0
Are you on master?
-
it has been a fresh checkout ..
I am running on boost 1.56.0
Are you on master?
*confirmed*
-
Built here without issue.
riverdice - JDST6t2MrADeGpACfRm5Nm3unEkH82dvdvxwKCECNV8coVoywuWuJ9
Also, is this the right blockchain?
"blockchain_id": "9329bb6fbb5d6fbc0e0872dd306536f66ea53250ee1e00602cb36bff05eff842",
"symbol": "JDST",
"name": "BitShares JDST",
"version": 109,
"db_version": 133,
"genesis_timestamp": "2014-06-20T14:40:27",
Yes, it's the right one.
sent 1,000,000.00000 JDST to you.
-
it has been a fresh checkout ..
I am running on boost 1.56.0
Are you on master?
*confirmed*
I'm using Debian 3.2.57-3 with boost 1.55.0.2
Can you try to follow https://github.com/zhangweis/jds/blob/master/BUILD_UBUNTU.md (https://github.com/zhangweis/jds/blob/master/BUILD_UBUNTU.md)? I've fixed the url in it.
-
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.
-
Hm .. I am on Archlinux and not ubuntu/debian ... maybe I can build on a other machine ..
-
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.
-
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
-
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.
-
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.
Ok, rebuilding now.
-
Eh, won't compile. It's late, I'll mess with it tomorrow.
-
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.
-
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.
-
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.
-
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!!
-
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.
-
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.
-
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.
-
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
-
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.
-
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 :D 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?
-
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.
-
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:
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.
-
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.
-
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.
-
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.
-
There's a bug in the code and it should be:
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) );
}
-
Is there any update on this project?