Dear Devcoin miners,

I'm pleased to announce that all the file custodians are finally in sync and ready to hit round 100!

It is very important that you make sure that your node has the latest receiver_99.csv and receiver_100.csv files into the receiver/ folder, in advance to block 400000, otherwise the fallback reduction algorithm will keep halving the miners reward down to 2500 per block. If you can't find the files in your local copy of the blockchain, please manually download them from here:

http://galaxies.mygamesonline.org/receiver_99.csv
http://galaxies.mygamesonline.org/receiver_100.csv

You don't need to stop your node or perform any other action apart from downloading those files into the right place. Also, I recommend this because during round 98 many file custodians, for different reasons, had their mirrors offline temporarily or definitively. Your node needs the up-to-date list of file custodian mirrors in order to work correctly, and that can't happen automatically if the majority of mirrors are offline for too long.

Last but not least, there is a new pre-release of Devcoin awaiting for you in the official repository: https://github.com/devcoin/core/. It was a very long time since the last release, so you have another reason to give your merged miner setup some maintenance.

Thanks for your precious time and contributions to the Devcoin project!

Go go Devcoin!

- develCuy

Some old coins like DeVCoin will just change the bounty to reward the admins with your work
Beware old coins that change admins

Can you supply me with the old url, unicode.03C0? Equiped with the url then the original page should be retrievable from the backup server and made available for you.

- Nova

I went to this https://github.com/devcoin/receivers and download zip master receiver file and open %appdata% roaming>devcoin and move the unzipped file to this location and rename it to receiver after deleting receiver file already there and my wallet now syncs.
Thank you for this solution.I would give merit but am unable to with newbie status but help appreciated!

Just a note that it's --reindex (two hyphens) on linux.

I got that on Windows. I had to right click within the folder my wallet is in, run Powershell, then start the client with the -reindex command-line option in Powershell. I had a backup of my wallet beforehand.

That got my wallet reindexing the chain but then it stalled at a block it had before. I noticed I didn't have the receiver files from 96 to 99 (most recent) so I copied them from one of the seeds and put them in my roaming>devcoin folder with the rest of my receiver files.  My wallet is Windows 32-bit 0.8.5.1 (a beta version it says).  The 2014 update was the last for Windows, unless you know how to compile the new one. But this one works for now. Got it from devcoin.org.

Hope that helps you.

I am getting error "failed to find/connect to best block"

What is the meaning please?

My Windows wallet 0.8.5.1 (beta one from devcoin.org) keeps getting stuck at the same block when I try synching (around the time 0.8.6.0) came out for Linux and what not. Just wanted to mention that. I've got it all backed up and I actually think maybe since deveCuy mentioned to mine "1 block only" that this is something I'd have expected so no worries. (just don't forgot your windows friends when you got the time =) ). Thanks!

I have finally figured out what is happening and I'm working on a fix. We had a mixture of situations:

1. Two custodians have their servers not working properly, they tend to go offline for different issues with their infrastructure
2. Ctya's server was shutdown in the middle of round 98, rather than at the end, not allowing Traxo to take over smoothly
3. Another custodian has enforced HTTPS connections but most of the miners nodes don't support it
4. The custodians not were in sync early enough for round 99

For the reasons above, we had 4 of the 7 mirrors "out of sync" for the standard of Devcoin blockchain, that leaves only 3 working mirrors when we need at least 4, the nodes are then rejecting the receiver files. The consequence of is that miners apply a penalty know as "fallback reduction", as an incentive for solving the issue with file custodians.

Hopefully, we can finally fix this situation, but it requires consensus from all the file custodians and perhaps adding a couple mirrors as I anticipated since previous rounds. My proposal is to implement one or two automated receiver files mirrors, so that we can lower the chance for this situation to happen again. Also, we have to be more strict with file custodians, if they are unreliable, we can't hold them for a single round more, and that is what I'm going to do from now on. Along releasing the receiver file earlier, we should define a safe deadline soon.

People interested on the technical details of what originated this situation please check the issue queue: https://github.com/devcoin/core/issues/76

Last but not least, the latest version of Devcoin supports HTTPS, but it looks like the majority of miners never managed to update their nodes. I don't blame them because we never released any official stable version for a long time. So we should do it now!

Let's clean up all the mess!

- develCuy

I think it is simply doing what it is designed to do in the event that "file custodians" do not put the new receiver files online in time.

Basically it got to the start of the new round, could not find enough identical receiver files, which each node would have started to look for a different random number of blocks before the end of the previous round in order not to all go looking at once and in order to ensure by the time the new round began it would alreay have the new receiver file in place; thus it had to go ahead with this round without a receiver file, and to draw even the miner's attemption to that fact it halves even the miner's payout (to give miner an incentive to keep the file custodians doing their thing, and for the miners to actually use the receiver files).

So I think it is doing exactly what it is supposed to do.

Unthinkingbit was worried it was taking so long to get the files in place, as he figured about the 17th of the month they should have been in place.

(Or maybe he meant that by the 17th I should have generated the file for others to grab, so they could all grab it in plenty of time.)

Now I guess we will have to rename the 99 file as 100 and wait for the next round, which hopefully we won't be too late getting the files in place for.

And of course since the blockchain is running this round as a no-receive-rfile round, we have to get rid of those 99 files so anyone trying to catch up to the blockchain from scratch does not crap out on round 99 due to thinking it had a reeiver file when in fact at the time it actually happened in real life it did not.

It is important to have those files in plae BEFORE the first block of the new round is mined if we actually want a receiver file to be used for the round.

Basically we just dawdled and delayed and filed to have them in place by the 17th or whenever it was that nodes started going out looking for the next round receiver file so as to be ready when the new round came along.

This is something that obviously had to be done, since no way should the blockchain stall, user's transactions failing to transact and so on, merely due to file custodians screwing up.

By affecting the income of the miners to, it ensures the miners have an incentive to try to make sure there are resposible custodians who are doing their job on time.

-MarkM-

After studying the source code a bit more, I'm more convinced that we neither have a bug or a network attack, instead we have the miner nodes doing what they are programmed to do as Mark already said. Why are they generating only 2500 DVC per block? Because miner nodes are unable to validate that the 50% + 1 of file custodians have their mirror of receiver_99.csv in sync. For that reason they aren't downloading that file, rather they apply a programmed "fallback reduction" that lowers the rewards to 2500 DVC.

There is an assumption that we had to have the file custodians in sync 2 weeks in advance to the new round, but I can't confirm it yet. So far I read in the source code that miner nodes keep trying to download the next receiver file before, during and after discovering a new block and regular nodes do it when syncing the blockchain with the network.

Long history short, we currently have a contradiction, because the file custodians doesn't seem to be hosting the exactly same copy (bit by bit) of receiver_99.csv. At least, that is what the nodes "can say". But when I compare the files, they are exactly the same. Another option is that somehow the nodes aren't able to download all copies of the receiver file, they might be getting a truncated file or even empty. This idea is reinforced by the fact we had 3 file custodians outdated or with their server offline, the remaining 4 should be enough but it doesn't seem to be the case.

I keep debugging the source code for finding a solution. All help is welcome! We have an open issue here https://github.com/devcoin/core/issues/76

- develCuy

Now we have the issue reported in the issue queue https://github.com/devcoin/core/issues/76

So far we know that round 99 started at block 396000 on 2019-10-26 11:07:49 UTC, and that at least 4 of the 7 file custodian mirrors where well setup by  2019-10-23 17:04:45 UTC or 2 days and 18 hours in advance to round 99. Yet, we should investigate further to determine if that was enough time in advance and if not having the next receiver file prior to generating block 396000 makes the nodes to halve miners rewards and not paying shares, as proposed by Markm.

- develCuy

I can confirm that starting from block 396000 (round 99) onward, there are only 2500 new coins being generated, and they are being paid enterily to miners. Also, none of my wallets are downloading the receiver_99.csv file, yet they are still downloading blocks.

My guess is that miners are generating blocks while ignoring the latest receiver file, which should never happen. This might be due to a bug or a network attack. We should first discard the bug. Which is not an easy task because there are different versions of devcoin running the network, we should analyze each of them individually.

- develCuy