Devcoin

[weisoq]

Is there no syntax for devtome to italicize a whole paragraph?

''like this''
http://www.devtome.com/doku.php?id=wiki:syntax

(edit: btw think I misunderstood your orderbook point - went off on a tangent)

[Balthozar]

Is there no syntax for devtome to italicize a whole paragraph?

''like this''
http://www.devtome.com/doku.php?id=wiki:syntax

Yea I figured it out, I was using actual quotations instead of ''blhfjdskl fsjklsd ''

[metazilla]

Man... the DVC order book at vircurex is looking pretty stale.

Probably because it's so close to next payment, so everyone that got paid last time already did their Vircurex...
Wait till block 89000, I bet it goes crazy with DVC buying and selling.

FYI, round 22 starts paying out at block 88000 and round 23 (the current round) starts paying out at block 92000. Block 89000 is just when submissions for round 23 stop being accepted (and for round 24 open).

Maybe I should make a devtome page explaining this.

[FinShaggy]

Man... the DVC order book at vircurex is looking pretty stale.

Probably because it's so close to next payment, so everyone that got paid last time already did their Vircurex...
Wait till block 89000, I bet it goes crazy with DVC buying and selling.

FYI, round 22 starts paying out at block 88000 and round 23 (the current round) starts paying out at block 92000. Block 89000 is just when submissions for round 23 stop being accepted (and for round 24 open).

Maybe I should make a devtome page explaining this.

Nice.

I thought payout was gonna be around 95, 92 is WAY better

[Balthozar]

It has been abnormally quiet on here today. I guess everyone is busy writing away in hopes of getting that tablet from jasinlee lol.

[FinShaggy]

It has been abnormally quiet on here today. I guess everyone is busy writing away in hopes of getting that tablet from jasinlee lol.

I didn't know he was giving away a tablet. That means people are gonna be writing like crazy.
And actually, all the DVC threads have been pretty quiet.

[Unthinkingbit]

..
I suggest a 6 then 3 bounty.
..
I suggest 2 then 1 for the next two exchanges.
..
I suggest 2 then 1 for all other coin options.
..
I suggest the typical hosting maintenance of 1/5 of a share ongoing, for the first two sites.

..
I was not careful when I wrote the share amounts, and I was wrong, they were too high.

This is my estimate for how much a bounty should be for. In general I think a share should be for ten hours work. With bounties there is a chance the project won't succeed, or that someone else will claim it first. Assuming a one in two chance that the project would will not succeed, that brings it to two shares for ten hours of work. A chance that someone else will claim the bounty and so the developer has say a 45% chance of getting first prize, a 45% chance of getting the second half prize, and a 10% chance of getting nothing, that means the expected return is 0.45 + 0.45 * 0.5 = 0.675, this would bring it to 2.97 shares for ten hours work.
..

Bounties will be around 3 shares for ten hours of expected, sustainable work. This is work time including eating, breaks, etc.., if pure coding time is given, that amount is doubled. I asked Gweedo and Metazilla how much time they spent on the ticker, the sustainable average ended up being around 18 hours. This gives a total of 18 / 10 * 3 shares = 5.4 shares (27/5 shares). The second place if half that 13.5/5, which rounded up is 14/5.

They both also get 1/5 of a share for maintenance as long as they keep hosting their tickers. They will get this in round 23:
https://raw.github.com/Unthinkingbit/charity/master/bounty_23.csv

[Balthozar]

It has been abnormally quiet on here today. I guess everyone is busy writing away in hopes of getting that tablet from jasinlee lol.

I didn't know he was giving away a tablet. That means people are gonna be writing like crazy.
And actually, all the DVC threads have been pretty quiet.

Check it out here: https://forum.litecoin.net/index.php/topic,2702.60.html

[Unthinkingbit]

..
In future, if the devcoin market capitalization stays over 1 million for at least a week, then we can fund bigger bounties, for small applications and modifications to big applications, stuff that could take a month of work:
http://www.devtome.com/doku.php?id=devcoin_bounty#capitalization_1_000_000_usd

For those bigger bounties, I plan on asking devcoin citizens (people who received coins from generation in this round or the previous round), to describe projects directly, then vote on them with 0 to 99 range voting:
http://rangevoting.org/Why99.html

The top three projects would get major bounties (close to 1% of the market capitalization), and the next three would get medium bounties (half that size). If at least one of the projects is successful and there is not too much controversy over awards, we'll have another round.
..

Our market capitalization has now been over a million bucks for over a week. Over the last week the bitcoin price has been usually over 120$, given about 4,350 million devcoins over that time, for the capitalization to be at least 1 million, the price has to be at least 1,000,000$ / 120 $/btc / 4,350 Mdvc = 1.92 btc/Mdvc. The price has been over that since at least April 24, 4h:
http://www.cryptocoincharts.info/period-charts.php?period=10-days&resolution=hour&pair=dvc-btc&market=vircurex

After thinking about the bounties, I realized that it would make follow up rounds complicated if there were two sizes of bounties, so there will only be 5 bounties, all the same size. Also, five bounties of close to 1% capitalization, including the second half bounty would be too expensive, so they'll be medium bounties of 12 shares, then 6 for second. Because there are more citizens now than when the original was posted, citizens can only propose two projects so as not to overload the voters. To encourage people to submit bounties which are achievable, and to pay people for their ideas, whoever proposes a bounty which is later awarded gets 2 shares.

Please post your project ideas and suggestions about the process in the devcoin ventures thread:
https://bitcointalk.org/index.php?topic=193054.0

[FinShaggy]

I've got TONS of Devcoin projects in mind

[Unthinkingbit]

Because of the rapid devcoin growth, the administrators are doing much more than the ten hours of work per month that we're being paid for. In round 22, four full administrators are being paid a share each, so 4 shares for administrators, out of a total of 125 shares, roughly 3.2%. If devcoin grows quickly we'll have more developers to eventually draw administrators from, but we'll also have more developers so administrators will still be working more than 10 hours a month. On the other hand, while administration work is necessary, a frugal organization should not pay administrators more than 10% of the revenue.

I suggest that administrators get paid two shares, unless that puts the total administrator pay above 10%, in which case the administrators would get 1 share. This way, if we ever get enough administrators, and so each has less work to do, our pay would go down accordingly. This would be done automatically by account.py, which would check if the administrators were paid more than 10% in the previous round.

Are there any objections, or should something be changed?

[FinShaggy]

Because of the rapid devcoin growth, the administrators are doing much more than the ten hours of work per month that we're being paid for. In round 22, four full administrators are being paid a share each, so 4 shares for administrators, out of a total of 125 shares, roughly 3.2%. If devcoin grows quickly we'll have more developers to eventually draw administrators from, but we'll also have more developers so administrators will still be working more than 10 hours a month. On the other hand, while administration work is necessary, a frugal organization should not pay administrators more than 10% of the revenue.

I suggest that administrators get paid two shares, unless that puts the total administrator pay above 10%, in which case the administrators would get 1 share. This way, if we ever get enough administrators, and so each has less work to do, our pay would go down accordingly. This would be done automatically by account.py, which would check if the administrators were paid more than 10% in the previous round.

Are there any objections, or should something be changed?

2 shares seems fair, because I think Devtome is going to get A LOT more attention over the next few months... http://www.devtome.com/doku.php?id=devcoin_advertising_campaign
Maybe even more than just 2 shares in later rounds...

[FinShaggy]

SUPPORT DEVCOIN HERE:
https://bitcointalk.org/index.php?topic=193121.new#new

[metazilla]

I suggest that administrators get paid two shares, unless that puts the total administrator pay above 10%, in which case the administrators would get 1 share. This way, if we ever get enough administrators, and so each has less work to do, our pay would go down accordingly. This would be done automatically by account.py, which would check if the administrators were paid more than 10% in the previous round.

Are there any objections, or should something be changed?

Sounds fair to me. Will all administrators do the same amount of work? Also, I think it'd be nice if there was somewhere everyone could see what work the administrators are doing, to hold them accountable (if something like this does not already exist.)

[Unthinkingbit]

..
Will all administrators do the same amount of work?

In the short run no, because each different task takes a different amount of time. In the long run, more or less, because if someone is doing a time consuming task, they should delegate part of their task to a new administrator.

Also, I think it'd be nice if there was somewhere everyone could see what work the administrators are doing, to hold them accountable (if something like this does not already exist.)

There isn't yet, I'll start by adding more descriptive terms to the bounty file. Later someone could put the descriptions on devtome.

[markm]

What I do that is administrative:

Once a round I run a shell script that does all the steps Unthinkingbit prescribed for making the new receivers list. For quite a while he would paste the list of instructions and I'd reply that actually I ran a script that purports to do the things he keeps explicitly listing out in the instructions, so eventually the script got put on the wiki somewhere in case some day someone else needs to do all those steps. Basically they consist of downloading all the categorised lists and the scripts for processing them (in case the scripts have been updated) and running the scripts. Then I upload the recievers file to galaxies.mygamesonline.org (which the script does not do because I like to eyeball it first, which is how I caught recently the fact lots of records were missing, so it seems a step worth doing, even though presumably all the other admins also eyeball it before uploading it to their places that they upload their copy to).

It actually would probably make sense for at least one other admin to run the same script themselves to check they get the same results I do. But as far as I know all that happens next is Unthinkingbit tells them the new one is ready, they copy it from galaxies.mygamesonline.org and put it on their own site. (So I could falsify it bwahahaha yeah definitely someone else should check my results. )

I also control the knotwork github account where the source code for reference versions of devcoind and devcoin-qt reposes, and the Galactic Milieu project at Sourceforge whose files download area contains .tgz tarballs of those (and various other coins' source code tarballs and some Open Transactions stuff and so on).

I also control some domains on behalf of the project, we'll be talking more about domains soon along with things to use them for. Among them is the devcoin.org domain to which I have added some hostnames to point at "stable" / "backbone" nodes.

I have two "stable" / "backbone" nodes set up on dedicated servers, a 16 gigs of RAM server and a 24 gigs of RAM server. They are pointed to by dvcstable01.devcoin.org and dvcstable02.devcoin.org as well as having their raw IP addresses hardcoded into the fallback IPs list of the recent reference client on github.

I have replaced the receiver.h in my not yet pushed copies of the reference clients, it builds fine now about to try to actually use it.

Because I am also involved on the code side I have to try to keep aware of bugs found on the bitcoin side, and have over the long term put some fixes into the code accordingly, for example even though our code originally came from quite-old-now bitcoin code one or two BIPs were grabbed and put in even though we did not update the whole codebase. We also fixed the timetravel exploit, which bitcoin did not bother to do because it figured it has such high difficulty that exploit would not be practical for an attacker. (I think it was Unthinkingbit who actually came up with the exact code for how exactly we did fix the time travel exploit. He does a lot of work, working with him has been very nice.)

Like Unthinkingbit I have also been involved in the DVC/BTC trade on Vircurex trying to ensure liquidity (instead of, for example, just cashing out my bitcoins leaving the "sell devcoins" side full and the "buy devcoins" side empty).

Hmm off the top of my head maybe that might be pretty much everything "administrative" I do? Hmm. Maybe.

-MarkM-

EDIT: Oh I also am still trying to find a pool setup that will actually motivate people to use it, currently it is just a no-fee p2pool located on dvcstable01.devcoin.org - there are still no systems I know of whereby to count up the bitcoins people got from mining on the p2pool and somehow compensate them extra based on all the many merged mined chains, including devcoin, that their hashes benefit. They get their bitcoins automatically, 100% of them, but there is no mechanism to pay more than 100% nor to, for example, divvy out devcoins to them based on how much of all the other chains we managed to mine and how much, in devcoins, those add up to when converted to devcoins. So that is research-and-waiting (waiting for some solution to appear out there somewhere) and watching and meanwhile thinking about what would need to be coded to do it if it never does appear.

EDIT2: Technically I run a devcoin exchange, since my Digitalis Open Transactions server does feature devcoins and thus allows them to be traded against any other asset at any scale that is a power of ten. I cannot recall offhand whether devcoins are also one of the assets I issued on the OTdemo server. Quite likely it is (I think actualy it is), if not it can be done easily if there is actual demand for it.

[emfox]

Because of the rapid devcoin growth, the administrators are doing much more than the ten hours of work per month that we're being paid for. In round 22, four full administrators are being paid a share each, so 4 shares for administrators, out of a total of 125 shares, roughly 3.2%. If devcoin grows quickly we'll have more developers to eventually draw administrators from, but we'll also have more developers so administrators will still be working more than 10 hours a month. On the other hand, while administration work is necessary, a frugal organization should not pay administrators more than 10% of the revenue.

I suggest that administrators get paid two shares, unless that puts the total administrator pay above 10%, in which case the administrators would get 1 share. This way, if we ever get enough administrators, and so each has less work to do, our pay would go down accordingly. This would be done automatically by account.py, which would check if the administrators were paid more than 10% in the previous round.

Are there any objections, or should something be changed?

I agree. And more, I suggest to increase to 3 or 4 or whatever more shares, if admins got all shares that less than 5%(or 4.5%), and decrease when reach 10%, to keep admin a relative stable amouts of all shares.

[markm]

Oh I like that "and more" clause, nice, thanks.

-MarkM-

[markm]

BOUNTY SUGGESTION:

A tool to implement paying out more than 100% to people merged-mining using p2pool with bitcoin as primary chain and devcoin as one of potentially many (currently about seven or eight or so) secondary chains.

Preferred is to pay them these extra (as in, above and beyond the bitcoins that p2pool sends them automatically in the coinbase transactions of the bitcoin blocks) earnings in the form of devcoins.

Because devcoins use the exact same addresses as bitcoins, it suffices to use the address they get their bitcoins at as the address to send devcoins also to. At least one user in the past said it would be better to allow them to specify a separate address but that is extra complexity that is not "technically" vital. It might help public relations though since otherwise people have to figure out the whole hassle of how to export their bitcoin address from their bitcoin wallet and import it into a devcoin wallet.

If they are to be rewarded based on all the many and various coins merged-mined, then some of the code people have already written for computing the value of one coin in terms of another might be needed, to figure out how much all those other coins are worth in devcoins.

On the other hand, just because some ticker claims they are worth a certain amount does not necessarily mean we will actually realise that amount when we actually sell them.

So it might make sense to do something like putting the control of the p2pool under the "DeVCorp" corp, and let it accumulate its coins of every kind, and pay people in DeVCorp shares. They can then sell those shares on the open market (e.g. on the Digitalis Open Transactions server) to realise those earnings. (I already have scripts that figure out the value of such corps based on what they hold, albeit several of the merged-mined coins are not yet counted in such valuations since some of them are not necessarily going to turn out to be worth anything. DVC and GRP and I0C and IXC and BTC and NMC and LTC holdings though are counted.)

Or, we can simply not count the coin types that the corp valuation scripts do not yet count, and pay people only based on the coins those scritps do imagine they "know" the value of. The other coins could accumulate in e.g. DeVCorp and anyone who desires to benefit from any value those other coins might some day end up having can simply hold shares of DeVCorp.

TL;DR a way to do payouts for a massively merged mining instance of p2pool.

It can be a tool run approximately once a month to do these extra payouts, but should not absoutely require the pool admin to have to run it at exactly that interval, so it should know when last it was run and pay out from then to the time it is run, thus allowing it to be run more or less often without losing track or getting out of sync.

It probably needs to both tell the admin how much it thinks it ought to pay out and ask the admin how much in total to pay out, because depending on how sales of various coins have been going there might not actually be enough devcoins on hand to pay the full amount it thinks should be paid out. So admin will need to be able to specify the total devcoins available for paying out, and I guess maybe it ought to keep track of shortfalls from what it thought should be paid, to make them up when the admin does get hold of more devcoins.

I see a potential problem here though if it takes a long time to realise devcoins from various altcoins.

So maybe having all the extra coins fall into DeVCorp coffers thus increase DeVCorp share value might in the end be the simplest/best solution in the long run.

-MarkM-

P.S. Hmm maybe stuff around the DeVCorp, General Development Corp and General FInancial Corp, all being DeVCoin-based Corps, might also count as "administrative" stuff that I do.

[psybits]

I second Mark's bounty suggestion - more miners are vital to the Devcoin network. Apparently BFL is finally shipping so when I bite the bullet and buy a  little ASIC I will have it merge mining DVC (When it finally arrives!!)