Does anyone know how many blocks are left, I don't know how to tell.

Here are the stats from Vircurex:

Devcoin:
Blocks: 86721
Difficulty: 584,663.5314
Networks GH/s: 2,615.0140

FinShaggy, check out this post from earlier in the thread (quoted below). It looks like round 23 will end at block 89,000. As of this post it looks like we're at block 86728, so that leaves 2272 blocks remaining. Based on my calculations, it takes 10.75 min on average to find a block (based on the time it took to mine blocks 85000-86000). Based on this, it should take about 17 days to get to block 89000 if mining continues at the same rate, so round 23 should end on May 10th. Hope this helps.

After re-reading that post I quoted, it looks like I made a mistake. It sounds like writing work will continue being added to the round 23 shares until block 89000, but currently we're actually still in round 21 - round 22 starts at 88000, and round 23 will start at 92000. So writers getting paid for round 23 should start getting paid in 5272 blocks, which at the current rate will be 39 days from now, which by my calculations is June 1st. At that point each block mined will pay out 45000 DVC to one of the people receiving shares. So basically the 4000 blocks from 92000-96000 will each pay 45000 DVC, split up equally among the shares, for a total of 180,000,000 DVC.

Based on the receiver files unthinkingbit posted a few pages back, I'm estimating that there are about 70 shares so far, with about 2.6 million DVC per share. At current exchange rate at Vircurex, that's about 5.66 BTC per share, at a value of about 763 USD! (Can someone check my math here?? Seems too good to be true.)

Which brings up an idea I had: I think if the potential earnings for writing were more obvious (imagine if you had a banner that was said Earn devcoins for writing 1000 words, $700 value!) we'd get a lot more writers. Could I propose a bounty for some sort of page that calculates the current number of shares based on the receiver files, estimates how many DVC each contributer will receive, the value of those DVC in BTC and USD, and the expected payout dates?

You could work out how many bitcoins each share was worth in the past rounds, but the more effective this marketing is the less predictable the number of shares per round going forward will be, so do not put "forward-looking statements" into the marketing. Just show them how much writers have made in the past. Likely they will make less devcoins per share going forward but depending on how exchange rates go that might or might not work out to less bitcoins which in turn might or might not work out to less dollars...

-MarkM-

I agree, please do not tell people how many devcoins there will be in a generation share. As devcoin gets more popular, the value goes up and more generation shares are earned, meaning fewer devcoins per share. However, the value per share varies less because the increase in value counters the decrease in devcoins per share. Lately, the value of a generation share has been around 200$, and it is likely to be over 150$ in the near future:
http://www.devtome.com/doku.php?id=earn_devcoins_by_writing#generation_share

lots of action with Devcoin right now, how come?

maybe fontas is preparing a pump...

Ok.   at this point I have made some changes that can allow a fresh install to bootstrap itself, with no receiver_ files.   
However it is fragile.. for example,  earlier today I was getting https://www.box.com/s/3v8jahr8ge29dcfjvomb as the receive_0.csv from the github url.   I have not yet been able to determine what http status code github is giving when
this happens, nor can I get it to happen often enough to catch it with the command line curl yet.   If anyone can capture
that status headers for this result it would help.   The code current can never recover once this happens.   It also has other
points that it will either never recover or 'attack' the host by trying to fetch the url many times a second when things fail
to fetch cleanly the first time.   There is also an odd bug that a space in the path to the receiver files gets stripped when
the directory is first made, but not later when it tries to write to that locations, so it then fails again.  What I have works much better then what the current release does but it still needs more error recovery and robustness...   however no ones is interested anyway,  I got zero replies or pms and people are more interested in writing and banners it seems then a sound fundamental client.

I any case the code I have fails still in odd ways, but regression testing shows the original code failed the same way as well, so I am pretty sure what I have is better but still not great

Edit:  To see what is in the csv file, download it and rename it to end in .html and load it in your browser.
Basically it is a fail that says "This page is taking way too long to load.

Sorry about that. Please try refreshing and contact us if the problem persists."