Topic: [DVC]DevCoin - Official Thread - Moderated - page 37. (Read 1058927 times)

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 am not sure how many blocks in advance is the biggest random number of blocks in advance that a node can choose to start trying to get the files.

It keeps trying until presumably it either succeeds or the round starts without the files.

I saw endless stream of node's complaints of not enough identical files since before the round began, but when I went looking after someone pointed out that minting had changed I noiced it has stopped pringing those complaints. So it looks like once the round has begun, or shortly after it has begun, without he files, it is too late to get the files.

Each rounded evidently does or does not have a receiver file in time.

-MarkM-

https://chainz.cryptoid.info/dvc/block.dws?396000
> Date/Time 2019-10-26 11:07:49

Why would nodes have to look for the files more than a week (if it's time based, and not block-number based?) in advance, and then presumably for some reason just ignore looking for them at all afterwards (up to just before the beginning of the next round, i.e. block 3999 of the current round)?
I understand the need for "some" time in advance, but weeks rather seems to be an overkill as it probably takes just few seconds to jump from node to node and get the files?
Even if we are talking about time less than a week, my point still stands I think.

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-

Price of BTC today - $9630

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

I know, that’s why I was asking what happened. 

The reward was 50,000 until this round.
Now it is suddenly 2,500
https://chainz.cryptoid.info/dvc/block.dws?396066.htm

What about Mac OS users? The GUI wallet looks old as heck. Any updates?

Anybody else [besides myself] notice the block reward drop to 2500? 

After starting the daemon, this message is displayed in the console:
This is normal?

Done compiling the wallet in Linux Mint and synchronizing it! I followed the step-by-step guide to compile it in here: https://steemit.com/busy/@cpol/how-to-compile-your-very-own-devcoin-wallet-in-ubuntu-18-04

Compiling process and wallet sync ran as expected without any problems. I didn't sync it from scratch, but it seems a little bit slower to sync than my previous compiled version.  No bugs to report in github.

Almost all file custodians are synced right now, except http://show-me-the-devcoin.info who's custodian I can't reach. If you know how to contact that person, please help us.

Also, we have some little -yet very important- changes to the source code. I have updated the default seed nodes, DNS seeds and receiver files mirrors in the source code, given that we had many of them not working any longer. A detail of the changes can be found here: https://github.com/devcoin/core/commits/master

All wallet testers along Windows and Linux administrators, please build the latest version of Devcoin from https://github.com/devcoin/core/ master branch, and report your findings in the issue queue: https://github.com/devcoin/core/issues/new

Go go Devcoin!

- develCuy

Attention DevCoin Administrators

Now that DevTome is behind password protection while still being online acsessable to admins, it is time to think of the move from the online Wiki to the STEEM Blockchain. The first order of business should be the DevCoin related postings like the Human Resources Page, etc,, There are a great number of them from a quick look earlier. New rewards will be worked out for the new tasks of finding content in DevTome and moving it to the STEEM blockchain through postings from our STEEM @devcoin account. All admins are encouraged to join the discussion in the DevCoin Forum to have a voice in those decisions.

As time goes on the hope is to reward DVC for posts using the DevTome community/team/tag in their STEEM postings, yet that is still up the road. Running our own community/tribe node is also an aspiration which would display only DevTome content from the STEEM Blockchaian. The main objective in the near future will be to port Ad Sense acceptable Proof of Brain Admin approved content from DevTome to the STEEM blockchain using appropriate tags.

Any Admin that wishes to be part of the port please make that intention known on the DevCoin Forum. Once our present human resources are fully tapped then we will reach out to the wider community for candidates.

#DevSTEEM On!

- Nova

This means that all rewards from the old devtome.com are now suspended. In other words, there aren't going to be new rewards for marketing from round 99.

- develCuy

DevTome Update

There have been some adjustments to the plan moving forward with DevTome as first explained in a recent post on this thread found at :

https://bitcointalksearch.org/topic/m.52650234

After reviewing the costs associated with hosting DevTome, bandwidth-wise, it is hard to see the value it is bringing to the project at this time. That is not to mean that the content does not have potential value as we move towards #DevSTEEM. 

The big difference from the original proposal will be that DevTome will be set up behind password protection so that admins can access it to be able to pick and choose what will then be posted on the STEEM blockchain using the tag devtome, thus removing the concern over bandwidth usage. We will also pick only Ad Sense friendly content so that we can eventually run a community/team of our own on the STEEM blockchain and gain a revenue stream from DevTome's content - as was its original unfulfilled goal.

MarkM is putting together a scheme whereby the devtome.com traffic can be redirected to the STEEM blockchain so that links using DevTome urls will continue to work.

Ongoing contribution to DevTome will happen through the use of the devtome community on the STEEM Blockchain. This will likely include upvotes from our @devcoin account on approved content as well as a possible revenue split on Ad Revenue once we have our own Community STEEM Node operational and displaying banner ads while displaying DevTome content.

We are in the process of getting the content holding site online. It will be given password protection so that Administrators can begin the process of sorting through the DevTome content and begin the port to the STEEM blockchain.

More to follow, hopefully, shortly.

- Nova (DevTome Administrator)

The Operations Fund started thanks to Qtera and it is now receiving all the ongoing shares from the expiring Devtome, Ctya's and other abandoned roles. Following the details

Article Administrator: 1 share
Category Administrator: 1 share
Cryptocoincharts Maintenance: 2/5 shares
Inspector Factotum: 1 share
Node Maintenance: 2/5 share
Share Administrator: 2 shares
Wallet Tester: 1 share
Web Factotum: 1 share
Portal Maintenance: 2/5 share
2 Signing Administrators: 4 shares

Total: 61/5 ongoing shares (12 + 1/5)

1F272RtCW9TKvYA3YUMA9AZ3xbxJjaoBEQ is the official address of OpsFund.

- develCuy

The 18 ongoing shares previously assigned to Ctya, and its corresponding 1 administrator share are now assigned to the new address of the Exchange Fund, in a similar fashion to the other funds, it can be tracked with the official address 1n58SBkjTAGfMivACgkaAkRY9Q7pjNeRB

- develCuy

We initially had 14 shares assigned to the fund, then 25 shares where assigned on round 98. For round 99, the 2 shares from the resigning Devcoin Developer will be reassigned to this fund, it means that they total 41 ongoing shares for the Devcoin Software Development Fund (DevFund).

19hM1CJzN2FYiR8CcrEe2X7SbJ69xH8nZ6 is the official address of DevFund.

- develCuy

Novacadian is the new Interim Devtome Administrator. The 2 ongoing shares from the former Devtome Administrator will be reassigned to the new one from round 99.

- develCuy