Supply was scaled up to 1 billion new PTS using a factor of 567.166.

Your 19.553911 old PTS became 11,090.313486 new PTS. Read: 11 thousand new PTS, not 11 new PTS. Nothing is missing.

Please give us a list of addresses and balances in the old client. Use the console command "listaddressgroupings" to also list change addresses.

When one such snapshot of the state of the database as of block N1 is created, the delegates could coordinate to sign the hash of this state. Let's say the 90th unique active delegate to submit their signature confirming the hash submits that signature in block N2. At that point, the delegates all work on building up the new hash for the state of the database up to block N2 and repeat the process. Until the new hash is also confirmed, the old hash for the state of the database up to block N1 is referenced in each block (say by including it in the digest of the block that the delegate must sign).

The problem with this approach is that the client needs a way to authenticate the delegates who sign that snapshot. But the votes authorizing the delegates are part of the snapshot, i. e. you have a circular validation process without a solid anchor.

Please give us a list of addresses and balances in the old client. Use the console command "listaddressgroupings" to also list change addresses.

The solution is as follows, the ticket result will be drawn by 2 delegates:
The first delegate's random number is only in charge of producing a number X between 1 and 3 that determines that the Xth block after him will draw the random number for the ticket. The 2th delegate could be the evil guy who is trying to attack, but he can not predict who will produce the right drawing block before 4 blocks, his attack cost is (3 * BLOCK_TICKET_SALE), but his expected return is still only 1 block_ticket_sale. The only thing game rule need is to set the draw interval 1 block before the first delegate.

I think the reasoning here is wrong. The question is what can an evil delegate gain by withholding his random secret? The answer is: he gains another chance for winning with his ticket. And using this, he can rip off the network if this second chance gives him an overall expected return that is higher than the house edge.

Suppose for example a dice-like game with 50% chance of winning and 1% house edge. I. e. if you buy a ticket for 50 shares, 50% of the time you'll lose 50 shares and 50% of the time you'll receive 99 shares in return.

The evil delegate attacker buys one ticket in every block. This costs him 5050 shares per round. In 100 of these 101 cases he cannot influence the outcome, but he will win 50 of these 100 on average, for a total return of 4950 shares. For the last ticket, he either wins normally or gets a second chance, for a winning probability of 75% and an expected return of 74.25 shares. Obviously, 4950 + 74.25 < 5050, so in this setup the evil delegate loses in the long run.
If the evil attacker owns 2 delegates or if 2 delegates collude, they cannot influence 99 of their 101 tickets. For these 99 they receive 4900.5 on average and get a second chance for the remaining two (in some cases they will even get a third chance for one of the two), i. e. 2*75%*99 shares = 148.5. 4900.5 + 148.5 < 5050, so they are still losing.

But three colluding delegates can rip off the network: they have 98 normal winning tickets yielding 4851 in returns, and 3 second chance tickets (some of the time even a third chance, and in rare cases 4 chances) for an expected return of 3*75%*99 shares = 222.75. 4851 + 222.75 = 5073.75 > 5050.

This was an urgently needed fix for the transaction malleability bug.

IIRC the proposed random number generation scheme had the problem that an individual delegate can decide to skip a block instead of producing a random number that would make him lose a game. (See https://bitsharestalk.org/index.php?topic=9489.msg139680#msg139680 ). Has that been addressed?

You may have downloaded the wrong branch. Check libraries/blockchain/include/bts/blockchain/config.hpp - there's a #define BTS_TEST_NETWORK that should be commented out. Looks fine in the v0.4.26 tagged version: https://github.com/BitShares/bitshares/blob/v0.4.26/libraries/blockchain/include/bts/blockchain/config.hpp