Closed Traxo7 closed 5 years ago
main.cpp has the answer:
static const int64 initialSubsidy = 50000*COIN;
static const int64 share = roundint64(initialSubsidy * 0.9);
static const int64 fallbackReduction = roundint64((initialSubsidy + share) / 2);
Also:
src/util.h:39:static const int64 COIN = 100000000;
Let's use whole numbers, so assume COIN = 1. Then we have this:
initialSubsidy = 50000
share = 45000
fallbackReduction = 47500
We can quickly realize that initialSubsidy - fallbackReduction = 2500, exactly the amount of current miners reward. That operation is presumably happenning in function CreateNewBlock() at line 4368:
4364 int64 nFees = 0;
4365 int64 minerValue = GetBlockValue(pindexPrev->nHeight+1, nFees);
4366 int64 sharePerAddress = 0;
4367 if (coinAddressStrings.size() == 0)
4368 minerValue -= fallbackReduction;
4369 else
4370 sharePerAddress = roundint64((int64)share / (int64)coinAddressStrings.size());
This is GetBlockValue():
int64 static GetBlockValue(int nHeight, int64 nFees)
{
int64 nSubsidy = initialSubsidy;
return nSubsidy + nFees;
}
So, it just returns 50000, which is assigned to minerValue, then it is substracted fallbackReduction, so we have minerValue with a final value of 2500. This is true when coinAddressStrings.size() == 0
(line 4367).
We have coinAddressStrings.size() == 0
because getCoinAddressStrings() is returning a empty list. That function triggers getTextLines() getStepOutput() getTokens() getStepText(). So we have to debug all of them to figure out why the list is empty.
I realized that getLocationTexts() is the best place to validate how is the nodes are dealing with receiver files mirrors. So I added some DEBUG code, and the function looks like this:
// Get the pages by the addresses, be they file names or hypertext addresses.
vector<string> getLocationTexts(vector<string> addresses)
{
vector<string> locationTexts;
for(int addressIndex = 0; addressIndex < addresses.size(); addressIndex++) {
cout << "DEBUG: Fetching " << addresses[addressIndex] << " ... ";
const string locationText = getLocationText(addresses[addressIndex]);
cout << "got " << locationText.length() << " bytes" << endl << endl;
locationTexts.push_back(locationText);
}
return locationTexts;
}
This is the output:
DEBUG: Fetching http://galaxies.mygamesonline.org/receiver_1.csv ... got 1271 bytes
DEBUG: Fetching http://devcoinpool.btc-music.com/receiver/receiver_1.csv ... got 1271 bytes
DEBUG: Fetching http://devcoin.darkgamex.ch/receiver_1.csv ... got 1271 bytes
DEBUG: Fetching http://d.evco.in/receiver/receiver_1.csv ... got 0 bytes
DEBUG: Fetching http://show-me-the-devcoin.info/devtome/receiver_1.csv ... got 0 bytes
DEBUG: Fetching http://node1.devcoin.cloud/receiver_files/receiver_1.csv ... got 0 bytes
DEBUG: Fetching http://jerpat.us/dcr/uploads/receiver_1.csv ... got 0 bytes
Host http://d.evco.in has something that nodes don't like
Found the issue with d.evco.in, thanks to wget:
$ wget http://d.evco.in/receiver/receiver_1.csv
URL transformed to HTTPS due to an HSTS policy
--2019-10-31 03:04:43-- https://d.evco.in/receiver/receiver_1.csv
The host is enforcing HTTPS, which is not supported by old Devcoin nodes. I have fixed this already in #77, so we should now work on a new release and wait till miners update their nodes.
After studying the code and performing several tests, my conclusion is that there wasn't any bug. Devcoind is programmed to reduce rewards in the even of not being able to find enough file custodians. That is what actually happened and we don't need to change the source code to solve the problem
According to cryptoId explorer, starting with block 396,000 (which is the start of the round 99) Devcoin block rewards are reduced to 2,500.
According to this recent post the problem might be that the nodes tried to get the receiver files in advance (some-time/some-block-number prior to start of the round, but never after the round has actually started), but were unable to find them (slightly more than 50% of the mutually matching receiver files) at all before the round has started.
Can such cause of the issue actually be confirmed, and if so, how can we deal with miners in the future being unable to reach receiver files on time?
On the other hand, to me it sounds unlikely that four (more than 50%) out of (apparently) seven (number of file custodians in the round 99) file custodians did not upload the required file to the required locations.
Personally I couldn't reach 2/7 receiver files after I found out that block rewards plunged, and other 5 output same hash (i.e. they were identical). Thus if reaching the files was indeed a problem, and if I understand correctly, at least 2/5 uploaded files were not uploaded on time.