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

This coin is the "unit of account" for a massive amount of "accounts receivable" and is also a "reserve currency".

There is also a whole "DeVCoin-based economy" in the Galactic Milieu in which quite a lot of DeVCoin is tied up.

The longer you-lot keep trying to make DeVCoin appear "worthless" the easier it is for debtors to pay off the over 2900 BILLION DeVCoins they owe.

If you-lot had upheld the value of the coin enough it might not have been necessary for the creditors to have to become so willing to accept payments against those accounts-receivable in coins other than DeVCoins themselves, thus the debtors would have had to actually BUY DeVCoins with which to make their payments. But that become totally impractical years ago when Devtome authors started just dumping their coins instead of inveting them into various facets of the DeVCoin-based economy. So you've maybe only yourselves to blame for the fact all that economic activity gets to just look up the supposed value of a DeVCoin and pay "an equivalent value" in some other currency of their choosing.

Then again maybe what was really going on was the authors on Devtome were the very same people who owed billions upon billions upon billions of DeVCoin? So had a big incentive to make sure the value of DeVCoin stayed as low as they could make it so that they could pay off those debts all the faster?

There are many currencies you can convert DeVCoin into, and even now there are still some of them that are still somehow managing to continue having a spot on various web-based "crypto exchanges".

It does keep getting harder, yes, because every time we manage to build up a good solid buy-side for one of our coins on one of the "exchanges" the "exchange" claims to have been hacked and runs off with all the coins, or it de-lists the coin due to the fact we tend to trade mostly over-the-counter or on HORIZON or STELLAR networks so maybe do not provide as much "volume" to the exchanges as they would like.

Partly this is also probably due to so many folks still not recognising how much the coins tie together, so as more and more of the coins that are still on "exchanges" fall off of them they do not see that as affecting some one particular coin they happen to favour, being as how they themselves maybe had not been in the habit of trading "their" coin for various of the others that are on exchanges.

The fact is the number of "our" coins that are still on exchanges has been shrinking for years, and some of them (CoiLedCoin, GRouPcoin, GeistGeld, TeneBriX and FairBrix come to mind) never even got onto any exchanges and no one seemed to care, maybe because they could always just trade them for DeVCoin, I0Coin or IXCoin all of which were still on exchanges.

But wake up folks, I am not sure I0Coin is on any exchanges anymore, I do not think IXCoin is on many, I am trying to start building buy-sides for GPL2, KED, SCIFI and QBT on LiveCoin but would not be surprised if as soon as I build them up strongly they will claim to have been hacked and run away with all the money. That is why I keep trying to just stick to HORIZON and STELLAR, at least there I know the coins are actually present and accounted for.

-MarkM-

What is point of all this when you have no trading activity on the exchange and nobody willing to trade it against bitcoin or dollars?What is coin any use for??

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

My nodes stopped complaining long ago now.

Are you sure miners behave differently?

It seems reasonable that once a round begins it is "too late", to keep trying to get the files after that just makes more and more of a re-organisation (fork undo) be needed if suddenly such files did appear.

Having such files available now seems likely to confuse any new nodes that try to catch up with the blockchain.

-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 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