Devcoin

[caston]

Hi I have posted in the devcoin community forums with a question for developers:

http://www.devcointalk.org/index.php?topic=4.0

This is about the change at block 8000. Please read and respond to this.

As well as a post calling for volunteers and nominations for moderation and admin access to the forum.

http://www.devcointalk.org/index.php?topic=5.0

[twobits]

I built and ran the devcoind, though it built of course as bitcoind, it did create a .devcoin directory at least!

After that I built and ran the devcoin-qt,  it told be it could not run since I had devcoind already running, so I stopped that and reran it.  It is now showing as only having one connection and 6581 block(s) downloaded.

I build it on Debian 6, and had to install the boost libraries, and gthread2.0 and qt4-qmake to get it all to build.

Not really sure what to do now though!

The INSTALL file mentions some files that need to be in the program's "current directory" aka "present working directory" when the program is run.

As you mention needing Qt, it sounds like you made devcoin-qt as well as devcoind?

Yep,  I built both.   

The INSTALL for devcoind mentions one typically strips it (to make it smaller) and renames it as devcoind.

Yeah, just was suprised the simple change to the makefile to have it build as devoind was not done.  *shrug*

Devcoin-qt cannot mine. So if you want to mine it is devcoind you will want to run, at least while mining.

I take it, merged mining is not supported?

With some routers, if you compile with USE_UPNP active, it might be able to open the port it needs for networking automagically. If not, you will probably need to tell your router to route that port number, tcp protocol, to that port on that machine.


Having the port open lets others connect to you, if you don't open the port you might experience for yourself what you would be helping cause others to experience: difficulty in finding someone to connect to.

Whether you mine or not is up to you. But we need people with the port (port 52333) open as lack of such people is why others have trouble at this early stage in finding people to connect to. Basically we need to establish a bunch of 24/7 nodes, and even, once we know who they are, put their static IP address if they have one, or their no-ip.org dynamic name or equivalent, right into the program as seed nodes to help make sure people find others to connect to swiftly and easily.

I see...  I am just now trying to wrap my head around the alternative blockchain ideas.  So I saw this and build it and ran it to see what I would learn while doing so.  I did it for now on a VPS though, and it is not set up to allow incoming
connections.  I am just two parts short of building a box dedicated to messing around with bitcoins and releated projects though, so when that is up I should be able to run something 24/7 for a bit.

[markm]

One thing that would be useful would be a server provider that people could pay for in bitcoins/devcoins and get whatever level of service they want and can afford.  A lot of developers end up spending a lot of time looking for a good server to run scripts on.

It would be good to know what the price is per unit for a dedicated machine and for a server.  If it is cheaper to buy in bulk, we could make a devcoin buy for open source developers who want a server, maybe with some *coind daemons and block explorer available.

AttractSoft's price list doesn't show dedicated servers, it only goes up to VPS: http://hosting.knotwork.com/vps-hosting.html

I could enquire directly about dedicated server possibilities but I think I'd rather actually try their VPS first before considering dedicated, and also price getting a "real" connection at home because if I cannot know who might have walked physically up to the thing and done who knows what to it right at the hardware level any concept of "security" of the server seems to me pretty much blown right out of the starting-gate...

AttractSoft doesn't accept *coins themselves but I could as reseller.

-MarkM-

Edit: twobits: I recall reading somewhere something about merged mining getting onto the bounty list somewhere along the line of foreseeable bounties, it is not in yet so far we haven't finished testing devcoin itself so trying to merge it with other chains is an effort that hasn't even been started yet. sacarlson has been testing merging with his multicoin-based chains so if he really does have that working now that might be a good place to look to see how exactly he did it. I believe I owe you 100,000 DVC bounty for having posted about installing, but I don't have your devcoin receiving address to send it to. I am so rusty in the inner details of a.out and make and so on that I wasn't sure how the name of the executable is decided, I thought maybe it was based on the name of the .o that turns out to contain the function "main" when linking so thought it might involve having to change the name of the .c in order to result in the new name for that .o ... if not hey great what simple change exactly would accomplish the feat?

[Shattienator]

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?

[markm]

A devcoin wiki would probably be useful for devcoin wiki

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

[Shattienator]

A devcoin wiki would probably be useful for devcoin wiki

(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! 

"https://github.com/Unthinkingbit/charity/wiki/Devcoin-Description"

[markm]

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!

-MarkM-

[caston]

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!

-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

[twobits]

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?

[Shattienator]

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.

[markm]

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-

[caston]

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?

[twobits]

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.

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

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.

[markm]

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

[caston]

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.

[twobits]

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.

[twobits]

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?
   

[twobits]

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.

[markm]

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-

[twobits]

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.