MS Windows build of Steem v0.12.0 is released.
You will need Visual C++ Redistributable Packages for Visual Studio 2013 . Download it here - https://www.microsoft.com/en-us/download/details.aspx?id=40784
From Steem github, changes made in this release are :
Each root level comment has a reward weight which impacts the end payout of the post. We are targeting 4 posts in 24 hours. Your first 4 posts in 24 hours will not be penalized. After that, they weight is decreased from 100% based on your average posting frequency. Having a frequency just barely higher than 1 every 6 hours will have very little impact, while spamming will be penalized heavily. This change is aimed to increase the quality of content at the cost of quantity.
Each discussion goes through a two stage payout. The first one is nearly identical to what currently happens on a new discussion except that we are weighting payout times by 12 hours instead of 24. This should cycle through currently trending content quicker. There is a second voting period set to 30 days after the first payout. This should help posts that don't have immediate viral success accumulate votes and have more consistent payouts in the long run. After the second payout a discussion becomes "frozen". The discussion is no longer editable and new replies are disabled. Users can still vote on comments in these discussions as a "nod" to the author without costing their posting power or awarding reward shares.
There has been a lot of controversy surrounding liquidity rewards. We are refraining from making a judgment at this point but want to spend more time reviewing their impact. We do believe that in their current form the liquidity rewards are simply too much for the value thy provide. As such, we are temporarily disabling liquidity rewards until we can design a better solution. In the meantime, a transaction fee free market should be incentive enough for users to continue to use the Steem internal market.
The average block size calculation is too high. We are reducing the minimum block size limit from 128k to 64k and changing the average block size threshold from max_block_size / 2 to max_block_size / 4. The net result is that the average block size threshold can be 4 times smaller. If witnesses chose to vote this way, it will make triggering transaction bandwidth limits easier, which is currently not applying except in the most extreme circumstances.
Fixed a bug in the cli wallet that incorrectly allowed the wallet to attempt to broadcast an update account operation from a locked wallet. The broadcast would fail but created a poor user experience.
Added recovery operations to account history so they can be tracked more easily.