Author

Topic: Devcoin - page 174. (Read 412954 times)

hero member
Activity: 756
Merit: 500
August 08, 2011, 11:34:00 AM
#43
Ok this is probably going to annoy you guys and I do apologise but I really think it needs to be this way for the project to succeed. I'm not even a programmer and i'm more of a hardware, web, OS/application support guy but I did do some programming when I was a teenager and in my early 20's. Anyway I have setup a git repository at:

https://github.com/caston/devcoin

The changes I have made are to the share line in main.cpp

static const int64 share = initialSubsidy * 1 / 10;

and I have been changing the makefiles to build devcoind instead of bitcoind


So what I basically want to do is change the share so that miners keep 90% of what they mine and 10% goes to the open source projects. By doing this I think we will actually collect more devcoins overall because more people will mine. Its the same as if a country has a high tax rate no one wants to work or run a business there.

I haven't started trying to mine with this change and I am not sure what will happen if I do. My assumption is though that it would only work if all the other miners made this change too.

Now I think we can double make up for this. There has been talk of moving devcoin to merged mining. I think this is a horrible thing to do because people have been using their hardware and electricity to mine coins as an extractive currency and now you are suggesting turning those coins into mere tokens. Investors will have very little interest in tokens and thus there will be little prospects of a high exchange value.

This is not to say that tokens are not very useful. They have an excellent niche of allowing trade between projects that are operated for "purpose" rather than for "profit".

So to "double make up " for the reduced levy we start a new currency called DevToken. DevToken starts off as a token currency since day one so none of the miners are losing wealth over this. Devtokens are merged mined with Devcoin. So you mine for devcoins and Devtokens are also created.

So the miners keep 90% of their devcoins and 10% go to opensource projects but to "double make up" for this 100% of the devtokens can go to open source projects. The tokens are of little interest to investors but perfect for allowing open source projects to trade with each other. So they can hire a person from another project to work on something for their project and vise versa.

The collected devcoins that go to projects helps the people with their real life expenses e.g. food, rent, electricity.

But if we consider the people working on these open source projects are working for the public good. They may be doing more than writing software for instance developing a way of automatically fabricating food and clothing.

We are doing something much more radical here. We are actually creating the means of separating public services from the state. After this happens we get things like health care and education light years more advanced than anything that exists today. This will truly help us become a more advanced civilisation.




sr. member
Activity: 574
Merit: 250
August 08, 2011, 10:25:09 AM
#42
I tried mining today,  and found two blocks.  Had one up to 2/unconfirmed,  but then they all of the sudden went to 0 and orphan status.   Only see one connection.  No idea what happened, except I guess  someone else made a block and did not add in mine?
hero member
Activity: 756
Merit: 500
August 08, 2011, 03:11:05 AM
#41
Are you guys ready to start these discussions on the Devcoin forums?

I also want to know if you have read my proposal that instead of merging Devcoin with Bitcoin to make another currency called DevToken. Devtoken is merged with Devcoin. When you mine for DevCoins you also create Devtokens. Devtokens are a currency that the projects that receive Devcoin shares use to trade with each other. They probably are of no interest to investors or to hired contributors that would prefer coins but they are perfect for transactions between open source projects.
sr. member
Activity: 574
Merit: 250
August 07, 2011, 09:17:31 AM
#40
So embedded python or curl or wget or ftp right inside our code I guess. If libcurl is tinier than libpython (or however one embeds python) it might be okay I guess, though python is more versatile than curl (and thus a larger attack surface quite possibly/likely...

I am back to what are those admins thinking? In general putting anything on the https part of a site instead of the http part is counter-indicated in cases where no session nor private data etc is on the page, isn't it? Wholesale slapping of reams of pages that don't need https into the https section is supposedly deprecated nowadays?

(Sourceforge does it because there is login session potentail on the pages in the https section, presumably/potentially so the https is called for in their case unless a fully user-provided page happens not to use such features?)

-MarkM-



Wget should be ruled out as it would introduce the gpl requirements to the code.
libcurl was pretty much made for this type of use. libfetch is what would be used to bring in the bsd ftp's http code, though pretty sure it does not support https though.

No idea what they are thinking , especially without specific examples.  Probably just practicing the better safe then sorry approach to make sure they never serve mixed content/pages.
legendary
Activity: 2940
Merit: 1090
August 07, 2011, 09:01:54 AM
#39
So embedded python or curl or wget or ftp right inside our code I guess. If libcurl is tinier than libpython (or however one embeds python) it might be okay I guess, though python is more versatile than curl (and thus a larger attack surface quite possibly/likely...)

I am back to what are those admins thinking? In general putting anything on the https part of a site instead of the http part is counter-indicated in cases where no session nor private data etc is on the page, isn't it? Wholesale slapping of reams of pages that don't need https into the https section is supposedly deprecated nowadays?

(Sourceforge does it because there is login session potential on the pages in the https section, presumably/potentially so the https is called for in their case unless a fully user-provided page happens not to use such features?)

-MarkM-
sr. member
Activity: 574
Merit: 250
August 07, 2011, 08:17:54 AM
#38
Does this forum support multiquote?  Can't seem to find it if it does.

Is curl installed by default on most distros these days? if its not found you could always throw up an error message telling them to install it.
Otherwise as he suggests libcurl might work.

If you mean linux distributions,  I don't know but I doubt it, they seem to prefer wget.   I myself mostly use BSD systems.  What they have done is extend the ftp  command to also handle http.
I see perl installed by default more often then python, so to me, I still have to install something that is not default either way.  
It seems overkill to have to bring in a whole new language interpreter just to fetch from a url.  I would need to do this on the BSD installs and windows.  Also it is not considered a good security practice to search the PATH for an  executable called from a program... so  a built from source curl that is invoked as ./curl   or /path/to/curl  is going to be more secure then a 'python https.py ...' exec also.
sr. member
Activity: 574
Merit: 250
August 07, 2011, 08:11:58 AM
#37

I suggest if the data stream between the tor exit node and the website needs to be encrypted to prevent sniffers from figuring out there is a devcoin node hiding somewhere on the Tor network we should be encrypting the actual network stream between nodes too otherwise the attacker doesn't need to watch the web traffic they can track the actual network connections to figure out who is talking about *coin to which Tor exit node...

(So it seems a case of "too little, too late". If it is needed, bitcoin needs it more than devcoin does, we should bounty the getting of it into bitcoin, then worry about whether devcoin admins should force clients to spend CPU on https instead of simply ignoring admins who offer it in favour of admins who publish the receivers list on http.)

(Maybe in meantime maybe allow compile option, like US-UPNP we could have USE_PYTHON or USE_CURL with both set to = emptry string meaning use neither?)

(Or how about admins who want to keep their copies of the receiver files secure put them on Tor sites instead of on the non-Tor non-i2p web at all?)


-MarkM- (Plus the whole https thing could simply be fallout from {|parts of} sourceforge being https, oh whoopie so important...)


So we all turn on IPsec?   

From reading your replies, seems quickest thing to do would be to junk the https and then figure out a better way to bring it back or a replacement for what it provides?  Who will make the call?
   
sr. member
Activity: 574
Merit: 250
August 07, 2011, 07:57:49 AM
#36
I built it on windows now.   The main issue was the use of sleep() in one of the files, which I found really odd since the code already went through the trouble of defining a more portable Sleep() function, so wonder why sleep was used in one of the files instead.

Now, running on windows the use of the python for what just seems to be fetching a url seems to be overkill.   I am going
to change that to use curl for now.   I am also curious just how sanitized the wx gui code is.  Has that been made safe to coexist with bitcoin on the same system or has it not been fully switched over to devcoin? I did noticed it is still using bitcoin irc channels?  Shouldn't they be switched?



Good news that you built in on Windows.

I am wondering when we can provide Windows binaries. Are you able to help with this?

I don't think what I have is ready to distribute.   I have not even dared to run it yet, as I don't have windows on a vm image like I do bsd/linux.   I will probably dig out an old laptop to run it on once the https/http/python/curl issue reaches a consensus.
hero member
Activity: 756
Merit: 500
August 07, 2011, 07:49:44 AM
#35


I suggest replacing the python call with a call to 'curl -O temporaryName address' , the curl exe is small
enough it could easily be bundled in to any binary distribution at least.   Could code it to use libcurl as well
and that would solve the https issue.  I am not sure what is in these files that are being fetched?
Only reason to use https would be to be able to ensure the origin source that I can see, and if that
is the reason to use it, it would have to be required that it is always used for it to be effective.  Probaly
better to just require the files be signed if that is why ssl is used.


Is curl installed by default on most distros these days? if its not found you could always throw up an error message telling them to install it.
Otherwise as he suggests libcurl might work.
legendary
Activity: 2940
Merit: 1090
August 07, 2011, 06:56:47 AM
#34
Might be interesting to see what it would take to get it going as well. (the wx version)

If it is like the -qt version, the changes should all (if I recall correctly; certain very close to all) cosmetic.

Meaning places where Bitcoin or bitcoin or BTC occur visibly to the end-user.

Even in the -qt I might have missed some due to being paranoid as to which were actually output for the user to see so the user could know which module of which executable was outputting the assert or error message and which were module or template-bundle names or even the possibility that the word might be in the network stream between nodes for all I knew about that stream.

I suggest replacing the python call with a call to 'curl -O temporaryName address' , the curl exe is small
enough it could easily be bundled in to any binary distribution at least.   Could code it to use libcurl as well
and that would solve the https issue.  I am not sure what is in these files that are being fetched?
Only reason to use https would be to be able to ensure the origin source that I can see, and if that
is the reason to use it, it would have to be required that it is always used for it to be effective.  Probaly
better to just require the files be signed if that is why ssl is used
.

I suggest if the data stream between the tor exit node and the website needs to be encrypted to prevent sniffers from figuring out there is a devcoin node hiding somewhere on the Tor network we should be encrypting the actual network stream between nodes too otherwise the attacker doesn't need to watch the web traffic they can track the actual network connections to figure out who is talking about *coin to which Tor exit node...

(So it seems a case of "too little, too late". If it is needed, bitcoin needs it more than devcoin does, we should bounty the getting of it into bitcoin, then worry about whether devcoin admins should force clients to spend CPU on https instead of simply ignoring admins who offer it in favour of admins who publish the receivers list on http.)

(Maybe in meantime maybe allow compile option, like US-UPNP we could have USE_PYTHON or USE_CURL with both set to = empty string meaning use neither?)

(Or how about admins who want to keep their copies of the receiver files secure put them on Tor sites instead of on the non-Tor non-i2p web at all?)


-MarkM- (Plus the whole https thing could simply be fallout from {|parts of} sourceforge being https, oh whoopie so important...)
sr. member
Activity: 574
Merit: 250
August 07, 2011, 06:43:28 AM
#33


I had no idea the wxWidgets code duplicated some of the functionality (such as choosing IRC channels) that already existed in the non-GUI core code that it was, as far as I knew, merely a GUI-wrapper / GUI-front-end for.


I don't think it does,  that seems to be me misreading a quick grep I did for 'bitcoin'....   the code in irc.cpp is commented out on closer examination.

Quote
(It is only devcoind, instead of actually using wxWidget GUI client we use -qt client as our GUI client.)

Might be interesting to see what it would take to get it going as well. (the wx version)

Quote
receiver.h, which contains the offending sleep() fnction call, is Unknowingbit's code encapsulating most of the receiver stuff that is most of how devcoin differs from bitcoin, and is what we are trying to test. So thanks for finding that.

He tried to get rid of python, succeeded, then broke down at the last moment in the face of "some admins might insist on putting their copy of the receivers files on an https server instead of on an http server. (Maybe those admins who wish to do that would like to issue bounties on getting that to work without clunky band aid silliness like calling an external python script or curl application? It is public data, deliberately public, what for do they want to force everyone to spend CPU cycles doing https to get it? It even costs them more CPU too, so who the heck gains what from it?)

-MarkM-



I suggest replacing the python call with a call to 'curl -O temporaryName address' , the curl exe is small
enough it could easily be bundled in to any binary distribution at least.   Could code it to use libcurl as well
and that would solve the https issue.  I am not sure what is in these files that are being fetched?
Only reason to use https would be to be able to ensure the origin source that I can see, and if that
is the reason to use it, it would have to be required that it is always used for it to be effective.  Probaly
better to just require the files be signed if that is why ssl is used.
hero member
Activity: 756
Merit: 500
August 07, 2011, 06:37:00 AM
#32
I built it on windows now.   The main issue was the use of sleep() in one of the files, which I found really odd since the code already went through the trouble of defining a more portable Sleep() function, so wonder why sleep was used in one of the files instead.

Now, running on windows the use of the python for what just seems to be fetching a url seems to be overkill.   I am going
to change that to use curl for now.   I am also curious just how sanitized the wx gui code is.  Has that been made safe to coexist with bitcoin on the same system or has it not been fully switched over to devcoin? I did noticed it is still using bitcoin irc channels?  Shouldn't they be switched?



Good news that you built in on Windows.

I am wondering when we can provide Windows binaries. Are you able to help with this?
legendary
Activity: 2940
Merit: 1090
August 07, 2011, 06:06:15 AM
#31
I built it on windows now.   The main issue was the use of sleep() in one of the files, which I found really odd since the code already went through the trouble of defining a more portable Sleep() function, so wonder why sleep was used in one of the files instead.

Now, running on windows the use of the python for what just seems to be fetching a url seems to be overkill.   I am going
to change that to use curl for now.   I am also curious just how sanitized the wx gui code is.  Has that been made safe to coexist with bitcoin on the same system or has it not been fully switched over to devcoin? I did noticed it is still using bitcoin irc channels?  Shouldn't they be switched?

I had no idea the wxWidgets code duplicated some of the functionality (such as choosing IRC channels) that already existed in the non-GUI core code that it was, as far as I knew, merely a GUI-wrapper / GUI-front-end for.

(devcoin-dd-Mon-yyyy.tgz  is really so far only devcoind. Instead of actually using wxWidget GUI client we use -qt client as our GUI client.)

receiver.h, which contains the offending sleep() function call, is Unknowingbit's code encapsulating most of the receiver stuff that is most of how devcoin differs from bitcoin, and is what we are trying to test. So thanks for finding that.

He tried to get rid of python, succeeded, then broke down at the last moment in the face of "some admins might insist on putting their copy of the receivers files on an https server instead of on an http server". (Maybe those admins who wish to do that would like to issue bounties on getting that to work without clunky band aid silliness like calling an external python script or curl application? It is public data, deliberately public, what for do they want to force everyone to spend CPU cycles doing https to get it? It even costs them more CPU too, so who the heck gains what from it?)

-MarkM-
newbie
Activity: 57
Merit: 0
August 07, 2011, 05:23:41 AM
#30
Got it running on Ubuntu 11.04 server.
Tomorrow I'll install a permanent node (on the same server used for groupcoin phase testing).
Will provide the address later when it will be done.

P.S. Groupcoin node still up and rinning without any interrupts since launch - so this server is stable enough.
P.P.S. Is the ubuntu console (via ssh) devcoin node setup guide will be usefull for devcoin wiki?

Dedicated permanent node is up and running at the:
50.19.210.139:52333

Please check availability.

P.S. I can set up few more - if needed. It can be helpfull at the initial phase to have some nodes available 24/7.
sr. member
Activity: 574
Merit: 250
August 07, 2011, 05:05:49 AM
#29
I built it on windows now.   The main issue was the use of sleep() in one of the files, which I found really odd since the code already went through the trouble of defining a more portable Sleep() function, so wonder why sleep was used in one of the files instead.

Now, running on windows the use of the python for what just seems to be fetching a url seems to be overkill.   I am going
to change that to use curl for now.   I am also curious just how sanitized the wx gui code is.  Has that been made safe to coexist with bitcoin on the same system or has it not been fully switched over to devcoin? I did noticed it is still using bitcoin irc channels?  Shouldn't they be switched?

hero member
Activity: 756
Merit: 500
August 07, 2011, 02:18:11 AM
#28
Ahhh, the wiki is at GitHub! Cool. Well yeah for sure since we have a wiki obviously putting info on the wiki is the right thing to do, its what wikis are for, afterall! Smiley

-MarkM-


I'm in the process of putting up a dedicated wiki which should be available within a day or two. I'm just have to integrate it with SMF and then its ready to go.

I have also added more to the thread on the forum discussing merged mining. I have made a proposal not to merge with Bitcoin but instead of start a new purpose built currency called tokencoin that will be merged mined with Devcoin. I then changed my mind and thought a better name was DevToken.

Please read and comment at: http://www.devcointalk.org/index.php?topic=4.0

I have also posted about the wiki at:

http://www.devcointalk.org/index.php?topic=8.0
legendary
Activity: 2940
Merit: 1090
August 06, 2011, 08:15:28 PM
#27
Ahhh, the wiki is at GitHub! Cool. Well yeah for sure since we have a wiki obviously putting info on the wiki is the right thing to do, its what wikis are for, afterall! Smiley

-MarkM-
newbie
Activity: 57
Merit: 0
August 06, 2011, 07:57:39 PM
#26
A devcoin wiki would probably be useful for devcoin wiki Wink

(If there is a devcoin wiki this is the first I've heard of it. If there isn't well hey where should we put one? A freebie on sourceforge or github or something? Or bribe the devcoin community admin to add a wiki there?

I have seen a link with "wiki" and "devcoin" in it at the first post!  Cheesy

"https://github.com/Unthinkingbit/charity/wiki/Devcoin-Description"
legendary
Activity: 2940
Merit: 1090
August 06, 2011, 07:32:00 PM
#25
A devcoin wiki would probably be useful for devcoin wiki Wink

(If there is a devcoin wiki this is the first I've heard of it. If there isn't well hey where should we put one? A freebie on sourceforge or github or something? Or bribe the devcoin community admin to add a wiki there?

Or maybe the software used to make the devcoin community site actually includes a wiki and I haven't noticed that yet?

Thanks for the post, maybe by the time you do post your receiving address it'll be 200,000 DVC bounty you'll be due? (Meaning maybe by then you'll've posted a detailed post for the extra 100,000 bounty...)

By the way jackjack I sent you 200,000 DVC last night, in two transactions of 100,000 each.

-MarkM-
newbie
Activity: 57
Merit: 0
August 06, 2011, 07:16:12 PM
#24
Got it running on Ubuntu 11.04 server.
Tomorrow I'll install a permanent node (on the same server used for groupcoin phase testing).
Will provide the address later when it will be done.

P.S. Groupcoin node still up and rinning without any interrupts since launch - so this server is stable enough.
P.P.S. Is the ubuntu console (via ssh) devcoin node setup guide will be usefull for devcoin wiki?
Jump to: