Hi,

I managed to build the 0.3.1 client on Ubuntu-14.04 (i586), but it is seriously unstable.
After starting it, it instantly goes to 100% CPU and stays there. The console reports varying connection counts, and the p2p.log shows lots of
20140815T093416.678613       th_a on_blockchain_item_i ] sync:     191d0c7973d0bf89568668600c8b5a36d8938028                     node.cpp:1942
According to get_info, the block count stays constant for a long time before it starts to crawl upwards - if it ever gets to that point. Most of the time, it crashes either with an Assertion Failure (attempt to free a mutex while threads are waiting on it) or a segfault. After about a dozen or so attempts I'm now synced up to block #23190. IOW, the client is unusable.

Here's a backtrace of the latest segfault:
--- there are now 4 active connections to the p2p network
(wallet closed) >>>
Program received signal SIGSEGV, Segmentation fault.
0x0917fd7a in fc::detail::is_operation_shorter::operator()(fc::detail::rate_limited_operation const*, fc::detail::rate_limited_operation const*) ()
(gdb) bt
#0  0x0917fd7a in fc::detail::is_operation_shorter::operator()(fc::detail::rate_limited_operation const*, fc::detail::rate_limited_operation const*) ()
#1  0x09181663 in void std::__insertion_sort<__gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, fc::detail::is_operation_shorter>(__gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, __gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, fc::detail::is_operation_shorter) ()
#2  0x09180e17 in void std::__final_insertion_sort<__gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, fc::detail::is_operation_shorter>(__gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, __gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, fc::detail::is_operation_shorter)
    ()
#3  0x091803ae in void std::sort<__gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, fc::detail::is_operation_shorter>(__gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<f---Type <return> to continue, or q <return> to quit---
c::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, __gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, fc::detail::is_operation_shorter) ()
#4  0x0917eef7 in fc::detail::rate_limiting_group_impl::process_pending_operations(fc::time_point&, unsigned int&, std::list<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> >&, std::list<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> >&, unsigned int&, unsigned int&) ()
#5  0x0917eaee in fc::detail::rate_limiting_group_impl::process_pending_writes() ()
#6  0x0917e685 in fc::detail::rate_limiting_group_impl::writesome(boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >&, char const*, unsigned int)::{lambda()#1}::operator()() const ()
#7  0x0917f8f2 in fc::detail::void_functor_run<fc::detail::rate_limiting_group_impl::writesome(boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >&, char const*, unsigned int)::{lambda()#1}>::run(void*, fc::detail::void_functor_run<fc::detail::rate_limiting_group_impl::writesome(boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >&, char const*, unsigned int)::{lambda()#1}>) ()
#8  0x08b0bf37 in fc::task_base::run_impl() ()
---Type <return> to continue, or q <return> to quit---
#9  0x08b0beed in fc::task_base::run() ()
#10 0x08b0472b in fc::thread_d::run_next_task() ()
#11 0x08b04a46 in fc::thread_d::process_tasks() ()
#12 0x08b042bb in fc::thread_d::start_process_tasks(int) ()
#13 0x091c3fa9 in make_fcontext ()

I also managed to build the QT wallet, but tested it only briefly as it doesn't even get to the point of opening a "real" window (other than the splash screen). One strange thing I noticed is that it uses "$HOME/BitShares X" instead of "$HOME/.BitSharesX" like the CLI version.

Edit: here's the assertion failure I was referring to:
(wallet closed) >>> bitsharesxd: /home/peter/Work/packages/bitshares/trans/bitsharesx-0.3.1/libraries/fc/src/thread/mutex.cpp:22: fc::mutex::~mutex(): Assertion `!m_blist && "Attempt to free mutex while others are blocking on lock."' failed.


It would be nice to have some graphs:

1. Mining rewards paid out so far
2. Total LTS spent on tickets, 15% of same
3. Total LTS paid out on winning tickets
4. Total supply

In the long run this DAC is profitable  if 15% of LTS spent on tickets > mining rewards.
In the short run we're operating at a profit if total spent on tickets > mining rewards + payout for winning tickets.

Hm, now it loads the sharedrop files, but still it fails. This is in the log (openSUSE-12.3 on x86_64):

2014-06-29 12:12:16 LottoShares version v1.0.0.0-gdab1cbb-beta ()
2014-06-29 12:12:16 Using OpenSSL version OpenSSL 1.0.1h 5 Jun 2014
2014-06-29 12:12:16 Default data directory /home/peter/.lottoshares
2014-06-29 12:12:16 Using data directory /home/peter/.lottoshares
2014-06-29 12:12:16 Using at most 5 connections (1024 file descriptors available)
2014-06-29 12:12:16 Using 4 threads for script verification
2014-06-29 12:12:16 init message: Verifying wallet...
2014-06-29 12:12:16 dbenv.open LogDir=/home/peter/.lottoshares/database ErrorFile=/home/peter/.lottoshares/db.log
2014-06-29 12:12:16 init message: Loading block index...
2014-06-29 12:12:16 Opening LevelDB in /home/peter/.lottoshares/blocks/index
2014-06-29 12:12:51 Opened LevelDB successfully
2014-06-29 12:12:51 Opening LevelDB in /home/peter/.lottoshares/chainstate
2014-06-29 12:13:17 Opened LevelDB successfully
2014-06-29 12:13:17 LoadBlockIndexDB(): last block file = 0
2014-06-29 12:13:17 LoadBlockIndexDB(): transaction index disabled
2014-06-29 12:13:17 Initializing databases...
2014-06-29 12:13:40 after bitcoin, total coins :2000000000000000
2014-06-29 12:13:46 after doge, total coins :4000000000000000
2014-06-29 12:13:47 after pts, total coins :4999999998109821
2014-06-29 12:13:48 after mmc, total coins :6000000079533682
2014-06-29 12:13:48 after ags, total coins :6999957079872862
2014-06-29 12:13:51 89ac175ec9bc64af4ebce8112bfcd7983e5abcb2871a69d265b214b71b94e211
2014-06-29 12:13:51 4ff382bb8a0284d52f2a119b461352b4dc294500d65a7261a0e456441e49950a
2014-06-29 12:13:51 a49d54ead14b7666e567800a6ad91b7c8983839b498033d4b3b492068b4a6ffb
lottosharesd: main.cpp:2995: bool InitBlockIndex(): Assertion `block.hashMerkleRoot == merklerootGenesisBlock' failed.


Better, but...

src/lottoshares.cpp: In function 'void addShareDrops(CBlock&)':
src/lottoshares.cpp:468:40: error: 'itoa' was not declared in this scope
src/lottoshares.cpp:492:40: error: 'itoa' was not declared in this scope
src/lottoshares.cpp:519:52: error: 'itoa' was not declared in this scope
src/lottoshares.cpp:556:52: error: 'itoa' was not declared in this scope
src/lottoshares.cpp:594:52: error: 'itoa' was not declared in this scope


Just beware and do you due diligence. It may be all good, but based on what has transpired before, it doesn't seem likely.

Exactly what I thought when I read the LottoShares snapshot announcement. There's several points that are fishy about the whole concept:

How will the numbers be drawn and prizes awarded?

As soon as a new block is generated, its hash will be signed by FreeTrade. The signed hash is used as a seed for the random numbers.

IOW: the creator of LottoShares, who is most likely also the biggest stakeholder, has at least some control over the "random" numbers used by a lottery!

Who will own the shares?

10% will be proportionally distributed to MemoryCoin (MMC) holders
10% will be proportionally distributed to ProtoShares (PTS) holders
10% will be proportionally distributed to AngelShares (AGS) holders

30% will be targeted at the public addresses of individuals who can be helpful to LottoShares DAC (devs, exchanges, service providers, marketeers etc - email memorycoincc@gmail.com to make a pitch, full list to be provided at launch)

It is unknown how much of the 30% for "devs" etc. are allocated for FreeTrade himself.

This first 60% is vested and funds will not be valid for (90 + rand(365))days - where the pseudo-random component is seeded on the address.

Again, the author is in a position to control when he will be able to sell his own allocations, while everyone else has to wait.

20% will be airdropped on the top 1,000,000 Bitcoin addresses (Block 302,000)
20% will be airdropped on the top 250,000 Dogecoin addresses (Block 232,000)

This 40% will be valid for use immediately, this will be non-proportional, providing a small amount to each BTC/DOGE holder regardless of the size of their holding.

Again, the author is in a position to control how much is "airdropped" to his own addresses.


Now, I'll be receiving free LottoShares, so I'm not complaining. But I'll be damned if I invest a single satoshi into that project.

I donated several PTS yesterday noon to get ags. Now almost 24 hours passed, the transaction is still not confirmed. Sigh :-(

Doesn't matter. If the transaction had one confirmation before midnight GMT, you will have received a share of yesterday's AGS.

What happens for pts miners with their unconfirmed pts? since the difficulty changes at November. I think loz of ppl will have hundreds unconfirmed pts in their account. which means, if there are two DAC is releasing, ppl lose a lot of invest?

For a week, I didn't get half of the pts confirmed.

When a snapshot is taken, it doesn't matter if transactions have been "confirmed" or not. Every transaction in the blockchain up to the point (i. e. block) of the snapshot is part of the snapshot.