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

Each line is one block, each block is called a share, and the software supports having 1/5ths of a share (by placing five addresses on one line).

Try receiver_1.csv, receiver_2.csv etc. The number is the "round" number. (Each 4000 blocks is one "round" of payouts. We are paying out "round" 29 now I believe, and clients will pick a random block during this "round" to download the receiver_30.csv file so that they don't all ask for it at the same moment.)

-MarkM-

I get 404 if I try to open any csv listed in any of the peers of a reciever file.

http://devtome.com/files/receiver.csv
http://devcoin.darkgamex.ch/receiver.csv
http://d.evco.in/receiver/receiver.csv

Are they not accessible directly? Only thru a port, or something?

Excellent, thank you.

So let's talk about the structure of a reciever file.

I see it has a node called _beginpeers / _endpeers

and _begincoins / _endcoins

What does it mean when sometime many adresses are listed together, separated by commata?
Did those people work on the same project or something?

The receiver files are on your disk, in the subdirectory named receiver in your devcoin data-directory.

You could use a text editor to read them, heck maybe even a word-processor.

Or simply use the "more" command (or, on Linux systems, the new improved "more" known as "less").

(Maybe you might like to tell your file-viewer that that type of file is to use that type of viewer to view it; though since the extension of the filename is .csv, meaning comma separated variables, you might find your file viewer already recognises them as files suitable for viewing in a spreadsheet program and hey, they might look better viewed in a spreadsheet than viewed in a text editor or word processor.)

-MarkM-

I see, so my devcoin daemon is reading those reciever files? Even when I am not mining?

So is there a command or rpc call with the daemon that spits out the current reciever files contents?

Or do I have to visit devtome to inspect the reciever file?

Those coins are sent directly to authors' wallets, not to "devtome".

Devtome admins have the authors' addresses put into the "receiver files" that the DeVCoin clients and daemons consult to figure out who to send 90% of the mined coins to each block.

At some future time though the various projects like Devtome will use Open Transactions to divvy up coins between their authors and such, whereupon yeah there will have to be some kind of "treasurer" for each project, to whom the digiDevcoins on the Open Transactions server will be sent.

However, by then maybe the actual coins will be going to a "N of M signatures" address so that it would take more than one person, or even more than one Open Transactions server, to sign a blockchain tranasaction to move the actual coins. (Normally though all the Open Transactions servers that audit the one that requests a blockchain transaction be done to send coins on the blockchain will sign if the digicoins on the server are legit, so just the coins pool feature of Open Transactions won't by itself prevent the admin the digicoins are sent to misappropriating the coins. How to handle this needs some more thought/work.)

-MarkM-

Recently all my sell offers on Vircurex way up through 193 satoshis got bought up by the way, in case no-one else noticed.

So are the people who claimed the previous times my coins bought at around 30 sold for up near or over 200, or even up to and just beyond 300, was just some weird pump and dump scheme orchestrated by Fontas now going to tell us this too was such a thing; that it is not true that the price ranges from down near 30 and maybe sometimes below to up near 200 and sometimes to 300 or higher?

Notice it happened fast, again. Waiting until you hear about it then firing up a client then waiting for six confirms before you can exchange your coins might not be the best way to cash in on such cycles; despite the inherent risk in sitting coins on third party sites it might we worthwhile to start putting some profit coins, coins you can well afford to lose, into buy offers one offer per satoshi of price all the way down from 250, 300 or 350 to some nice high figure that is seldom actually reached (so that you don't sell them at a price these spikes tend to blow right on through and keep on going...)

Also maybe as you sell them (at double or triple or quadruple or more what you paid for them) start taking some of the profit and putting it into satoshi by satoshi buy offers from one satoshi up through 30 or so, to profit also on the low end.

-MarkM-

so can please anyone explain this.

With every round we have 180 Million DVC that are send to devtome.

Or how exactly does this work.

Who is the reciever of this money? Escrow?

Well yeah let's hope so. I won't even go into my desire to see longer-term just how much writers really value their writing and are willing to contribute to marketing, interest and appeal by making it completely self-sustaining...

Well hopefully pouring out these huge bribes initially is paying off, since we do seem to have attracted at least one lifestyle writer plus we have gotten a lot of admins from the pool of Devtome authors.

Hopefully in what will seem after the fact like not long at all we'll have found plenty of such people, at which point maybe we can do the same "overkill pay to launch the thing" approach with the next major project, whatever that ends up being; and although the authors who squandered their DeVCoins will moan and complain at the insane pay the new type of people get and how writing isn't even bringing in minimum wage anymore the lifestyle "gotta write, gonna write, how much do I have to pay to be able to write, writing is my addiction" people will be sitting back looking at their one entire share and their huge pile of sell offers sitting at 200 or more satoshis per coin and the price of the bitcoins those satoshis are the lowest denomination of and think "holy cow I am doing well, those new guys are gonna be millionaires unless they squander their coins and if they do squander them guess who will be buying them cheap while they foolishly dump them"...

(By then hopefully the pay for articles will be shares of the ad revenue of devtome, and of course lifestyle authors who write as a lifestyle are just as free to post to Devtome for shares of its ad revenue as the new guys are to build their rocketships or whatever it is that the new guys do...)

-MarkM-

One way would be to apportion each aspect of devcoin a weighting of periodic generation. For example, we might say devtome = 180m * x%; developing = 180m * y%, bounties = 180m * z% etc. Then all payments are made from a sub-pool. But the problem with that is it changes the calculation dynamics, where for example a bounty would also need to become a % rather than an absolute sum. And then, what if there are no bounties achieved in a round, does that roll over to the next month - would that help catalyse getting it done, or would it instead just be 'wasted' when it could have been earned by somebody else.

That's why I've only suggested limiting the max payout per round - unless specifically designated like a bounty. Because if that cap is at the right level it should result in work and pay trending towards some sort of equilibrium where all parties - writers, developers, one-off bounty workers, admins, buyers etc - think it's worth their time and effort. And in rounds where that isn't the case, the dynamics of relative interest up or down should be corrected, because anything considered too low/very high will feedback into disincentive/greater incentive in the next one.

So I think the issues and same ends can be addressed more easily with cap (and maybe floor) adjustments over time without going through the hassle (and unknowns) of adding more complications.

WINNER! Congrats to cyke64. Your DVC is on its way. Congrats for participating. If anyone would like to see more of these hunts, please tell me. My theory is that it is a way to get participants to dig into existing DVC related files and sites. Familiarity breeds DVC!

It is just ONE share for having a lifestyle commitment to free open source development that chronically consumes at least ten hours per week/month of your time.

Even if it consumes your every waking hour that is one share - one life, dedicated to such a lifestyle. Ten hours is a minimum, surely it is very hard for such people to limit themselves to only working on the stuff ten hours, heck that is less than one day, usually when they get on a roll they are likely to very shortly notice it is morning again yet they feel like they only just woke up and got into doing some good work... When you are a lifestyle developer, it is good to try to remember to sleep at least once a week whether you need to or not.

(Ten hours is the week you go on vacation and have to work while "using the bathroom" and such because your family thinks you are actually not doing any work that week so you can spend time with them... )

-MarkM-

Is that a physical server, or virtual server?  That's a lot of daemons!

Also, a moneysupply call would be nice.

Are there any objections to 4 shares, then 2?

This also includes a new icon set.  (new address book, etc.)

It sounded so low I wanted to clarify and make sure you weren't describing something hypothetical (like in earlier parts of the discussion). Maybe I should have written... IS it just ONE share per TEN hours? ...And it would have been clearer.

EDIT: Forgot to add, part of the reason this surprised me so much was that I just got a one share bounty for writing a short review of a devcoin wallet installer.


I'd say it definitely encourages lifestyle authors of written material at this point. It might also encourage people who are not using it in the spirit it was intended. But if it went to the lifestyle developer=certain number of shares, you'd probably have to have the dedicated pool of developers *first*, transition the program, then there'd be a lot fewer shares that would be worth more. You'd also theoretically be able to up the number of shares given to lifestyle developers for their work (for instance if that section in a receiver file looked like devtome earnings currently does)

thanks, I will look into it.

Although I have three servers, at least one of them I need to be stable at all times... that's why I don't think I am going to install any daemon there.

Check /var/log/messages, when the O/S shuts down tasks due to running out of RAM it should indicate that in there.

I am not sure whether swap actually helps, maybe it does. The 8 gig machine here at home that it kept crashing on only had 2 gigs of swap because I upgraded the RAm after the disk had already been set up and the operating system installed. So try swap, maybe it will work. It might take a while to gt responses to RPC calsl but if you aren't mining that shouldn't be a problem.

Very fast block coins though would maybe thrash at some point, a block arrives so it starts to swap out another coin to make room for block processing, then that other coin also hears about a block and it too tries to unswap, pretty soon maybe all the fast coins are all trying to unswap so only the slow coins actually stay swapped a while, if even they do since they still keep hearing about transactions maybe if they are coins actually used to transact...

Maybe just go with five machines, ten daemons per machine?

But wait, three times 24 is more than fifty, you should be able to run 50 coins with that much RAM. Are you using old non-memory-fixed I0Coin and/or GeistGeld or something?

Stopping and starting the daemons would likely run into the problem of being blocks behind on the blockchain, you presumably want the latest block in order to get the stats you want.

Maybe just make a simple little daemon that just gets blocks and tallies up the stats you want, maybe something written in python or something?

Or look at the various libs people have made for processing blockchains and doing the p2p to get blockchains.

-MarkM-

that is a good price, I pay about twice that where I am. I have 3x 24 gig.

Splitting the daemons on all available servers was my second thought too.

Or, since I only need to do a getblockcount once every ten minutes or so (and then write the variable into mysql) I will probably start a daemon, wait for it to update and then stop it. Then restart it every 10 minutes with a cronjob.
Why should it run all the time when I don't need it in realtime.

Do you see any problems with that?

I don't know, I already threw money at the problem by leasing three dedicated servers, two being 16 gigs one being 24 gigs, for a year paid in advance.

They paid for themselves and more by CPU mining primecoin and protoshares (back when they actually were able to find blocks of those reasonably often), not even thinking about the massive number of BBQcoins they picked up during BBQcoin's under the radar mine it with CPUs year (last year), so I just split up all the daemons I need for merged mining among those three servers and look around for interesting things to do with all the spare RAM they have still left over. (The spare cores are still mining primecoin, albeit not finding blocks very often.)

Its like $30 or $35 so a month for a 16 gig dedicated machine with unlimited bandwidth on a gigabit-per-second ethernet and heck running the same machine at home would cost me more than that just in electricity without even considering getting a high bandwidth internet connection here at home comparable to what they have at the datacentre so it seems a good deal to me.

(Its not the hosting link in my sig; PM me if you want a referral.)

-MarkM-