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

Why not "just" change how bitcoin does things so everyone needs a new bitcoin client?

Such a change would be a so called "hard fork". I expect there is a lot of info about "hard forks" on these forums, especially in the technical / development section.

(Bitcoin likes to schedule such things two years in advance, so that once they do change the code they change it to code that says "when we reach this two years or so from now block, these new rules go into effect...)

Please check whether you read my previous post since I editted it as I was still working on it when you posted...

-MarkM-

Yes, thanks for your patience, nothing like a dev you can ask questions and get immediate answers.
I try to read every post, but most I still find incomprehensible.
You are right, I'll go back to the beginning and reread. Problem is I don't know where to start, there are other locked DVC-Threads in this forum... should I go that far back?

So, is there a mathematical reason for having a maximum division of shares into five parts? Why not just up this?

You obviously skipped a bunch of posts from a day or few ago, plus same data in posts way longer ago than that.

Each "round" is 4000 "blocks", and the mining tries, by adjusting "difficulty", to target an average time between "blocks" of ten minutes.

Thus a "round" - 4000 blocks - should on average tend to be vaguely around about a month or so of "real time".

It is a hard limit, as 4000 blocks is the definition of a "round", and since each block is a share, there are only ever at most 4000 shares.

This is why eventually we will likely end up with only 4000 projects getting a share each, or up to 20,000 getting a fifth of a share each, then each project will divvy up its coins among its participants/workers itself after it receives them.

For example in an Open Transactions server maybe a videos site might have an asset called Moviecoins or Videocoins, and a medical/health site have an asset called Healthcoins or Medcoins or whatever and so on, which it can give out to its workers and then periodically when it receives devcoins on the blockchain it can issue digidevcoins on the Open Transactions server to represent them and place offers in the markets in the Open Transactiosn server to buy back its medcoins or moviecoins or whatever wit digidevcoins, which in turn could be cashed out for real on the blockchain devcoins (maybe via a multi-dignature blockchaincoin-pool in which multiple servers must approve the digidevcoins in order to sign the multisig on-the-blockchain transaction that moves the actual on-th-eblockchain devcoins).

-MarkM-

Aha, yes I see... now with _29 at the end, it opens the file. Cool.

So they excluded the number at the end of the peer url, because it regularly changes. Makes sense.

hm, There is no limit to the amount of blocks I assume?
or is there a theoretical limit of how many shares there can be?

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