Bitcoin Forum
December 12, 2019, 01:16:42 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 [146] 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 ... 412 »
  Print  
Author Topic: [DVC]DevCoin - Official Thread - Moderated  (Read 959542 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
weisoq
Hero Member
*****
Offline Offline

Activity: 718
Merit: 500


View Profile
December 23, 2013, 11:00:26 AM
Last edit: December 23, 2013, 03:09:59 PM by weisoq
 #2901

I would like to propose a bounty for qt images and new icons.  8 shares for the images and icons used in the qt, 4 shares for the second best set of icons.

Any objections, or should anything be changed??
There were already objections here: https://bitcointalk.org/index.php?topic=310280.msg4095549#msg4095549

Unthinkingbit:
Quote
Your article is way more than 50 words, it has great pictures, and Bittzy78 got his link from your article, it must of been there first. Technically since the post was made later, you would only get 1 share, but since you wrote the information first before Bittzy78 posted, you should get at least 3 shares. So I suggest 3 shares for Wekkel, any objections?

I'm pretty sure wekkel and others were already involved in testing and commenting on the test earlier here: https://bitcointalk.org/index.php?topic=310280.msg4085910#msg4085910

Sidhujag:
Quote
I want to fully testwith 0.8.5 first to make sure we didn't introduce any malfunction in the way it works. The code is totally different and we have to be confident that we can roll fwd from this point on. After testing is done I will work on 0.8.6 and look ahead to 0.9 upcoming. We still have to decide on the fee changes and/or implications to inflation rate structure if we go there. This will cause a hard fork.
The fee should remain a flat 1 dvc as far as I know, with no fork.

Bittzy:
Quote
I guess that I must be doing something wrong then. I have entered a couple of articles and have properly filled out the receipt section on Devtome.com  but when I check the daily account31.csv on http://d.evco.in/charity/ I don't see my user name in the Devtome earning section. If you could provide any insight into what I am doing wrong. It would be most helpful.
It can take a little while to add new writers to the receiver lists, but if still not on in a few days remind me and I'll chase it for you.

Giftculturewriting:
Quote
Maybe I'm just being sensitive, but this discussion seems to be escalating and I don't know if that's productive. This is just a discussion on a forum thread-- brainstorming, opinions, et cetera. What's actually implemented is a system that pays creators for creating, currently limited to writing. Personally I'd look at how the project has actually manifested as opposed to unmanifested ideas. The limitations and challenges of expanding the system to include other content such as music have already been outlined. They will take time and people-power to implement, and that's just a logistical reality at this point.
Quite. As I said I think these things should be done properly, so taking one step at a time is important. There's some interesting discussion that would probably have been easier to follow if there was a separate devtome thread.
1576113402
Hero Member
*
Offline Offline

Posts: 1576113402

View Profile Personal Message (Offline)

Ignore
1576113402
Reply with quote  #2

1576113402
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1576113402
Hero Member
*
Offline Offline

Posts: 1576113402

View Profile Personal Message (Offline)

Ignore
1576113402
Reply with quote  #2

1576113402
Report to moderator
1576113402
Hero Member
*
Offline Offline

Posts: 1576113402

View Profile Personal Message (Offline)

Ignore
1576113402
Reply with quote  #2

1576113402
Report to moderator
1576113402
Hero Member
*
Offline Offline

Posts: 1576113402

View Profile Personal Message (Offline)

Ignore
1576113402
Reply with quote  #2

1576113402
Report to moderator
markm
Legendary
*
Offline Offline

Activity: 2464
Merit: 1032



View Profile WWW
December 23, 2013, 11:04:25 AM
 #2902

He didnt do anything about low memory he just updated to bitcoin 0.8.5 and problem was gone.

If that is true, then the whole "merged mined coins use up more RAM and this is why" theory is maybe blown out of the water?

All the memory usage fixes for the merged mined coins were predicated on the theory that the massive coinbase transactions produced by p2pool get kept in RAM by the merged mined coins because the bitcoin chain's block against which they were merged is their proof of having been correctly merged mined, or something like that.

If that was not afterall what was realy going on, then maybe it was afterall a memory leak that caused GeistGeld and I0Coin to use massive amounts of RAM, not this business of the merged mining proof stuff in RAM...

Unless maybe the bitcoin code now somehow puts such proofs to disk like the memory-hog-fix does or something?

(And we care about that and should care about that not only because things that affect other merged coins might effect us but also because they are part of our merged mined coins family, providing a spread of different features using the same hashing power that secures our own chain. Also because we are all about free open source development and after bitcoin the other merged mined coins are our closest relations. We want merged mining to work nice and smooth for all the merged coins because we don't want merged mining to get a bad rep like "oh no you are merged mined, such and such a coin is merged mined and it has problems such and such and such and such...)

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
sidhujag
Legendary
*
Offline Offline

Activity: 2044
Merit: 1004


View Profile
December 23, 2013, 11:09:23 AM
 #2903

I would like to propose a bounty for qt images and new icons.  8 shares for the images and icons used in the qt, 4 shares for the second best set of icons.

Any objections, or should anything be changed??
There were already objections here: https://bitcointalk.org/index.php?topic=310280.msg4095549#msg4095549

Unthinkingbit:
Quote
Your article is way more than 50 words, it has great pictures, and Bittzy78 got his link from your article, it must of been there first. Technically since the post was made later, you would only get 1 share, but since you wrote the information first before Bittzy78 posted, you should get at least 3 shares. So I suggest 3 shares for Wekkel, any objections?

I'm pretty sure wekkel and others were already involved in testing and commenting on the test earlier here: https://bitcointalk.org/index.php?topic=310280.msg4085910#msg4085910

Sidhujag:
Quote
I want to fully testwith 0.8.5 first to make sure we didn't introduce any malfunction in the way it works. The code is totally different and we have to be confident that we can roll fwd from this point on. After testing is done I will work on 0.8.6 and look ahead to 0.9 upcoming. We still have to decide on the fee changes and/or implications to inflation rate structure if we go there. This will cause a hard fork.
The fee should remain a flat 1 dvc as far as I know, with no fork.

Blitzy:
Quote
I guess that I must be doing something wrong then. I have entered a couple of articles and have properly filled out the receipt section on Devtome.com  but when I check the daily account31.csv on http://d.evco.in/charity/ I don't see my user name in the Devtome earning section. If you could provide any insight into what I am doing wrong. It would be most helpful.
It can take a little while to add new writers to the receiver lists, but if still not on in a few days remind me and I'll chase it for you.

Giftculturewriting:
Quote
Maybe I'm just being sensitive, but this discussion seems to be escalating and I don't know if that's productive. This is just a discussion on a forum thread-- brainstorming, opinions, et cetera. What's actually implemented is a system that pays creators for creating, currently limited to writing. Personally I'd look at how the project has actually manifested as opposed to unmanifested ideas. The limitations and challenges of expanding the system to include other content such as music have already been outlined. They will take time and people-power to implement, and that's just a logistical reality at this point.
Quite. As I said I think these things should be done properly, so taking one step at a time is important. There's some interesting discussion that would probably have been easier to follow if there was a separate devtome thread.

It should be 4 shares for the qt images that is what I proposed.

Also do we have a bounty for ability to transact dvc via qr codes?

2 parts 1 ability to generate qr codes from your pc wallet. 2 we need a mobile wallet. Mobile wallets can use builtin scanners and mobile wallet would parse devcoin: {address} to send coins.

We can then add this to the webpage to promote devcoin.
sidhujag
Legendary
*
Offline Offline

Activity: 2044
Merit: 1004


View Profile
December 23, 2013, 11:17:14 AM
 #2904

He didnt do anything about low memory he just updated to bitcoin 0.8.5 and problem was gone.

If that is true, then the whole "merged mined coins use up more RAM and this is why" theory is maybe blown out of the water?

All the memory usage fixes for the merged mined coins were predicated on the theory that the massive coinbase transactions produced by p2pool get kept in RAM by the merged mined coins because the bitcoin chain's block against which they were merged is their proof of having been correctly merged mined, or something like that.

If that was not afterall what was realy going on, then maybe it was afterall a memory leak that caused GeistGeld and I0Coin to use massive amounts of RAM, not this business of the merged mining proof stuff in RAM...

Unless maybe the bitcoin code now somehow puts such proofs to disk like the memory-hog-fix does or something?

(And we care about that and should care about that not only because things that affect other merged coins might effect us but also because they are part of our merged mined coins family, providing a spread of different features using the same hashing power that secures our own chain. Also because we are all about free open source development and after bitcoin the other merged mined coins are our closest relations. We want merged mining to work nice and smooth for all the merged coins because we don't want merged mining to get a bad rep like "oh no you are merged mined, such and such a coin is merged mined and it has problems such and such and such and such...)

-MarkM-

I didnt see any mem specific code rsnel wrote but I think bitcoin code had something if i can remember about writing to disk instead of using ram.. that was prob part of the fix and then other mem leaks getting cleaned up.. We wont know for sure until someone runs the daemon on the pool and logs the difference of memory usage over sample period of time.
markm
Legendary
*
Offline Offline

Activity: 2464
Merit: 1032



View Profile WWW
December 23, 2013, 11:31:54 AM
 #2905

Even the ancient devcoin code has yet to display the kind of massive RAM-usage that that GeistGeld and I0Coin did, because we only have one block per ten minutes on average whereas I0Coin is much faster thus has way the heck more blocks to deal with and GeistGeld is maybe even too darn fast to be practical so has even way the heck more than I0Coin.

Plus of course, GeistGeld and I0Coin might have more blocks that were mined using p2pool than DeVCoin does because they have spent more time not being on public pools thus having to be mined using p2pool by individuals instead of being mined maybe on a pool that does not put all the miner payouts into the coinbase transaction eating up RAM...

Also, one of the coders told me soem tiem back that he was in fact adapting the fixed I0Coin, not working directly from bitcoin code.

I had gotten the impression from the wording of his posts that he was ignoring the whole fixed I0Coin for some reason or for no apparent reason and was instead working from raw bitcoin code, but he corrected that impression.

That is part of why it seems weird to now hear that supposedly hs has backgtacked and is in fact working directly from bitcoin and creating a devcoin version that lacks the fixes that were put into I0Coin.

rsnel did the I0Coin fixes that is why we wanted to get rsnel if possible to do the other coins too, since he might grok his fixes/code better than others might.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
georgem
Legendary
*
Offline Offline

Activity: 1470
Merit: 1003


spreadcoin.info


View Profile WWW
December 23, 2013, 12:47:34 PM
 #2906

Even the ancient devcoin code has yet to display the kind of massive RAM-usage that that GeistGeld and I0Coin did, because we only have one block per ten minutes on average whereas I0Coin is much faster thus has way the heck more blocks to deal with and GeistGeld is maybe even too darn fast to be practical so has even way the heck more than I0Coin.


I was wondering:

Is there a way to limit the ram usage of a process in ubuntu server?

Is there a command for that?

I have installed a few daemons on a server, and they eat up all ram very fast.

markm
Legendary
*
Offline Offline

Activity: 2464
Merit: 1032



View Profile WWW
December 23, 2013, 01:16:06 PM
 #2907

Unix-type operating-systems use all available RAM for file buffers and such, so don't look at total RAM in use, look at the resident set and whether the swap partition is getting used up.

I0Coin used to need about four gigs though and GeistGeld would crash from lack of RAM on an 8 gig machine even no other coins running so I moved it to 16+ gig machines.

The new halfway-fixed GeistGeld (the quick-and-dirty fix) uses way the heck less RAM and the properly fixed I0Coin even less.

Bitcoin you can still run in a gig I think, but maybe not in half a gig or not run it well in half a gig anyway.

Most other coins, if not merged mined, seem to fit into half a gig or so.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
georgem
Legendary
*
Offline Offline

Activity: 1470
Merit: 1003


spreadcoin.info


View Profile WWW
December 23, 2013, 01:33:14 PM
 #2908

Unix-type operating-systems use all available RAM for file buffers and such, so don't look at total RAM in use, look at the resident set and whether the swap partition is getting used up.

I0Coin used to need about four gigs though and GeistGeld would crash from lack of RAM on an 8 gig machine even no other coins running so I moved it to 16+ gig machines.

The new halfway-fixed GeistGeld (the quick-and-dirty fix) uses way the heck less RAM and the properly fixed I0Coin even less.

Bitcoin you can still run in a gig I think, but maybe not in half a gig or not run it well in half a gig anyway.

Most other coins, if not merged mined, seem to fit into half a gig or so.

-MarkM-


thanks. So I should try to somehow enlarge the swap partition. Is this possible?

markm
Legendary
*
Offline Offline

Activity: 2464
Merit: 1032



View Profile WWW
December 23, 2013, 01:37:42 PM
 #2909

Nowadays I have noticed Fedora defaults the swap partition to only a little larger than the RAM. Maybe for good reason, as it does seem to get into swap-thrashing if you do try the old twice the size of the RAM or the even older three times the size of the RAM for swap.

Basically you probably want a gigabyte per coin for long-established coins, and maybe even for the newfangled "almost as fast as GeistGeld" coins since they go through blocks fast; and a gig per merged mined coin.

Getting into swap while mining is a poor idea as it leads to p2pool complaining that daemons are taking more than 5 seconds to respond, and it might well be that it complains because slow access to getblock calls maybe degrades mining performance for all the coins it is merging.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
georgem
Legendary
*
Offline Offline

Activity: 1470
Merit: 1003


spreadcoin.info


View Profile WWW
December 23, 2013, 01:53:57 PM
 #2910


Basically you probably want a gigabyte per coin for long-established coins,...


That coincidies with my own experience.

I am working on a side project, something like a coinmarketcap overview of about 50 coins. Mixed with api chartdata of the biggest exchanges.
Everything in one site.

My server has 24 gigs. And runs smoothly as long as I have about 20 daemons ... but if I try to start all 50 daemons (yes I compiled 50 daemons by hand  Cool ) sooner or later everything crashes.

At one point even apache crashed and I couldn't access the server, had to restart.

Another strange thing I noticed: when I do a pidof most coins only list one process (which is good), but I have seen some daemons namely namecoind and infinitecoind list many more ids when I do pidof. Why do they need many processes instead of just one???

I basically need most daemons only to make a getblockcount call and getdifficulty of the respective coin. (additionaly to provide donation adresses for visitors, so they can donate to my project whatever coin they like)

The basic thing I want to do is calculate the total money supply for every coin. And I do not want to rely on external sources/blockexplorers because they could be offline (as I have seen happen many times with coinmarketcap.com) so I don't want to do it like them.

Do you know if there is a way to have a naked stripped down daemon who doesn't do anything else then provide geblockcount and moneysupply if available?

I have seen that some coins provide the variable "moneysupply" when you do a RPC call. Others don't and you therefor have to calculate the blockcount and then apply the halving rules over time etc to get to the amount of total actual coins in circulation.

PS I never had any problems with the devcoind daemon. I use version 32501, which is the newest one I hope.

markm
Legendary
*
Offline Offline

Activity: 2464
Merit: 1032



View Profile WWW
December 23, 2013, 02:00:32 PM
 #2911

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-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
georgem
Legendary
*
Offline Offline

Activity: 1470
Merit: 1003


spreadcoin.info


View Profile WWW
December 23, 2013, 02:06:15 PM
 #2912

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, 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 look around for insteresting things to do with all the spare RAM they have still left over.

Its like $30 or 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 so it seems a good deal to me.

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

markm
Legendary
*
Offline Offline

Activity: 2464
Merit: 1032



View Profile WWW
December 23, 2013, 02:16:47 PM
 #2913

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-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
georgem
Legendary
*
Offline Offline

Activity: 1470
Merit: 1003


spreadcoin.info


View Profile WWW
December 23, 2013, 02:27:10 PM
 #2914

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.

giftculturewriting
Newbie
*
Offline Offline

Activity: 52
Merit: 0


View Profile
December 23, 2013, 02:38:56 PM
Last edit: December 23, 2013, 02:51:50 PM by giftculturewriting
 #2915

Is it one share per ten hours?


In fact it seems to me that ideally we should at some point no longer need to pay authors by the word, because, hopefully, we will eventually be able to do authors the same way we do any other developers of free open source software, which is to say, if we find a good author who habitually as a lifestyle spends ten hours per week creating free open source stuff they should be able to get onto the receivers list as a developer of free open source stuff.

Notice that they get the same one share regardless of whether they only spend the absolute minimum - ten hours per week - working on such stuff or they do such stuff 40 hours a week or 60 hours a week or 80 hours a week or whatever.

The idea was we are looking for those people who already naturally as a lifestyle contribute their time freely to free open source development.

Did you read the above paragraph of mine that you quoted?

As it answers the question you posted above it. Smiley


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? Huh ...And it would have been clearer. Tongue

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.

The thing is though, why would you settle for only one share for all those hours instead of getting one share per 1000 words?

Well one reason, I suppose would be if you didn't want to post the material to Devtome.

But basically the crazy-high pay currently going to Devtome authors kind of discourages anyone from going for the lifestyle author of free open source software option, not to mention the vast number of shares that go to Devtome authors grossly dilutes the actual value that a lifestyle author's lonely single share would actually be worth on the exchanges.

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)
smeagol
Hero Member
*****
Offline Offline

Activity: 966
Merit: 1000


bitclicker.ga


View Profile WWW
December 23, 2013, 03:06:26 PM
 #2916

I would like to propose a bounty for qt images and new icons.  8 shares for the images and icons used in the qt, 4 shares for the second best set of icons.

Any objections, or should anything be changed??
There were already objections here: https://bitcointalk.org/index.php?topic=310280.msg4095549#msg4095549

It should be 4 shares for the qt images that is what I proposed.

Are there any objections to 4 shares, then 2?

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

  BITMIXER.IO   High Volume Bitcoin MIXER  
BTC: 1JH2jybjWruvDD23wSe5PCY9Epmr45u6nQ - DVC: 1SMEAGqpm9JSpJ6JZaM5dEBptPTNahpFa - Earn Devcoins by Writing | Devcoin Official Site  | SAT
smeagol
Hero Member
*****
Offline Offline

Activity: 966
Merit: 1000


bitclicker.ga


View Profile WWW
December 23, 2013, 03:11:25 PM
 #2917

My server has 24 gigs. And runs smoothly as long as I have about 20 daemons ... but if I try to start all 50 daemons (yes I compiled 50 daemons by hand  Cool ) sooner or later everything crashes.

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

Also, a moneysupply call would be nice.

  BITMIXER.IO   High Volume Bitcoin MIXER  
BTC: 1JH2jybjWruvDD23wSe5PCY9Epmr45u6nQ - DVC: 1SMEAGqpm9JSpJ6JZaM5dEBptPTNahpFa - Earn Devcoins by Writing | Devcoin Official Site  | SAT
markm
Legendary
*
Offline Offline

Activity: 2464
Merit: 1032



View Profile WWW
December 23, 2013, 03:17:26 PM
Last edit: December 23, 2013, 03:50:15 PM by markm
 #2918

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? Huh ...And it would have been clearer. Tongue

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

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

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
eeh
Full Member
***
Offline Offline

Activity: 185
Merit: 100


View Profile
December 23, 2013, 03:18:22 PM
 #2919

Quote

#On the Charity Github, which US rocket is shown being launched?
#What is the most current version of the Windows Devcoin-qt?
#Name a pool where DVC is merge mined.
#What is unthinkingbit's DVC earnings address?
#What was the difficulty of block 118485?

Answers

Edit this wiki page and enter your responses below along with your Devtome username and your DVC address. Be sure to save the page so I know who had the earliest revision for tracking purposes.

# Apollo 15 rocket
# Windows Client Devcoin_QT 0.8.5 from Sidhujag
# Bitparking Merge Mining Pool http://mmpool.bitparking.com/pool
# [address removed]
# 466074503.558

Answers from cyke64 [address removed]

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!
weisoq
Hero Member
*****
Offline Offline

Activity: 718
Merit: 500


View Profile
December 23, 2013, 03:46:43 PM
Last edit: December 23, 2013, 04:18:44 PM by weisoq
 #2920

...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)
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.
Pages: « 1 ... 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 [146] 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 ... 412 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!