Devcoin

[doublec]

What client GUI do i0coin and namecoin use?

Namecoin doesn't have a gui and i0coin uses the older wxwidgets based GUI.

[1714999144]

1714999144

[1714999144]

1714999144

[1714999144]

1714999144

[1714999144]

1714999144

[markm]

Qt comes from repositories as packages for your system. wxWidgets not so much. At least not the version bitcoin needed/used.

I did get it to actually work on Fedora 14, and I see I still have that machine's hard drive mountable in this machine so I can grab it over and see if it still compiles in Fedora Core 15.

Some folk apparently actually like that old GUI better than the qt one.

It is right there in the old-devcoind repo, you "just" need the dependencies...

-MarkM-

[Unthinkingbit]

Qt comes from repositories as packages for your system. wxWidgets not so much. At least not the version bitcoin needed/used.

I did get it to actually work on Fedora 14, and I see I still have that machine's hard drive mountable in this machine so I can grab it over and see if it still compiles in Fedora Core 15.

Some folk apparently actually like that old GUI better than the qt one.

It is right there in the old-devcoind repo, you "just" need the dependencies...

The reason I started with bitcoin-qt is that I was not able to compile bitcoin-wxWidgets. If someone can make a binary of bitcoin-wxWidgets that most people could install then that would be good enough.

Another possibility is that the offending process call could be changed to a file write by a script and then a read by bitcoin-qt. What I mean is that just before we ported over the remaining python stuff in the really old devcoin to boost C++, we did manage to get python working safely from qt by calling the script, having the script write to a file, then reading that file. Since this was awkward we dropped it when the remaining python code was ported to C++. However, if in this case there is no other way to solve the problem, then CheckBlock could use that same technique.

[markm]

Who is "most people"? Windows?

We should nail down exactly what is causing the crash. We already got rid of what was causing it before, which was mining.

So what the heck is causing it now?

What was mining doing that caused it? Was it just that mining uses threads?

This error looks as if threads are happening even without mining. Maybe the patches explicitly set up threads themselves?

I am not really clear as to whether our previous solution (simply not trying to mine) worked due to eliminating the use of threads or due to eliminating of whatever it was that was not thread-safe.

Are there still threads? What for? Why aren't there threads in the daemon?

Is the GUI simply trying to pretend to be both a front end GUI and a back end daemon by running a GUI thread and a daemon thread? If so maybe we could/should rip out the GUI from the deamon and have the GUI totally separate, like any normal unix application that provides a GUI front end to interact with a daemon?

That might be approaching close toward being a thin client, maybe we can look around and find a thin client people who want a GUI can use to talk to the daemon?

OH WAIT! Open Transactions' java client includes a tab in which you talk to your bitcoin daemon.

I don't recall exactly what problems I had to solve to get the wxWidgets bitcoin to compile, I do recall it was a pain, and took a while. I was given the impression that on normal systems, which maybe meant Windows, Mac and some kind of Linux, maybe Ubuntu or Debian or both, it "just works", that it didn't work on Fedora was my fault for using Fedora instead of the target platform. What platform did you try it on?

-MarkM-

[cablepair]

My pool is all ready and working 100% with Bitcoin as the parent chain and namecoin and devcoin as aux chains, ive been mining on it all night with my 8 ghash with no problems and have actually solved a name coin block (damn I feel lucky)

I missed this, sorry. This means you're not actually mining devcoins at the moment. Your blocks will be created but then orphaned by the network as all the other nodes should reject them. You'll basically be mining your own fork of devcoin. What is the current hashrate of the entire devcoin network? Someone should ask allchains to support it, or provide an equivalent if possible.

this was on a private testpool.

Pool.devcoin.org is exclusively mining devcoins on mainnet until we get to the magic number block then I will shut down and reboot with new config and will be live on Bitcoin, Namecoin and Devcoin Network.

Although it will take me a day or two to get the stats and web pages upgraded for users we will be effectively merged as soon as that magic number hits and I reboot the pool software.

[kjlimo]

So will pool.devcoin.org merge mine BTC/NMC/I0C/IXC/DVC?  If so, I think that'll attract a lot of traffic for those interested in merged mining.

I'll probably add it to mmpool to see how it goes. That'll give it 30-40 Ghash/s.

Rock On!

[cablepair]

I'm not sure I see the value in i0 and iX merged mining , they are basically dead , broken coins with no purpose or future

[Unthinkingbit]

Who is "most people"? Windows?

I was thinking Ubuntu would be enough, as a majority of the people using the devcoin-qt client are doing so on Ubuntu.  I was not able to install wxWidgets in June, but installing under Ubuntu is supposed to be doable:
http://wiki.wxwidgets.org/Installing_and_configuring_under_Ubuntu

We should nail down exactly what is causing the crash. We already got rid of what was causing it before, which was mining.

So what the heck is causing it now?

What was mining doing that caused it? Was it just that mining uses threads?

This error looks as if threads are happening even without mining. Maybe the patches explicitly set up threads themselves?

I don't understand what the patches are doing, but I speculate that indeed the patches must be setting up threads themselves.  I would speculate that there should be a way to just check without setting up more threads, but I don't know how to do that. If there are no objections, they'll be an twelve generation share bounty to check in some way that doesn't crash a Qt client, divided by everyone who codes it. I know that won't magically fix the problem and I don't know if the problem can be fixed, but if it can it'll give the developers who fix it some of what they deserve.

I am not really clear as to whether our previous solution (simply not trying to mine) worked due to eliminating the use of threads or due to eliminating of whatever it was that was not thread-safe.

I believe our previous problem was that the Qt threads were incompatible with threads made by other programs. When we tried calling a python script from within Qt it crashed; when we tried running a python script and then reading the result from a file, that worked fine.

Is the GUI simply trying to pretend to be both a front end GUI and a back end daemon by running a GUI thread and a daemon thread? If so maybe we could/should rip out the GUI from the deamon and have the GUI totally separate, like any normal unix application that provides a GUI front end to interact with a daemon?

That might be approaching close toward being a thin client, maybe we can look around and find a thin client people who want a GUI can use to talk to the daemon?

OH WAIT! Open Transactions' java client includes a tab in which you talk to your bitcoin daemon.

I suspect that bitcoin-qt wraps tightly with the network code. If someone does make a thin GUI client which communicates securely with the daemon, that would be good too.

I don't recall exactly what problems I had to solve to get the wxWidgets bitcoin to compile, I do recall it was a pain, and took a while. I was given the impression that on normal systems, which maybe meant Windows, Mac and some kind of Linux, maybe Ubuntu or Debian or both, it "just works", that it didn't work on Fedora was my fault for using Fedora instead of the target platform. What platform did you try it on?

I tried it under Ubuntu, and I could not get it to compile.  I'm hoping that either the wxWidgets package has improved, or that someone else could make a devcoin-wxWidgets binary and I could run that.

[Unthinkingbit]

I'm not sure I see the value in i0 and iX merged mining , they are basically dead , broken coins with no purpose or future

From looking at the trading on vircurex:
https://vircurex.com/

There is a 28 BTC trading volume on i0coin, but only 1 BTC on iXcoin. So you could run the pool with devcoin as the parent, namecoin and i0coin as the auxilaries, and sell all the i0coins as your fee for the extra work in running a merged mining pool.

[markm]

I copied my wxWidgets source code from the hard disk that had been in my old 32 bit Fedora 14 box to the /usr/src area on my currency 64 bit Fedora 15 bix and compiled it successfully first time.

In the process I saw names going by like cairo and pango that reminded me what the pain had been: dependencies. It had been really hard to find out exactly what that long list of things had been that it actually needed to get those components to work; the original list had not been right for Fedora.

Since you mention binaries, I won't bother deleting the .o files, on the probably not likely but maybe hypothetically possible chance they could work on Ubunto; and will .tgz the directory and put it on the sunsite downloads site. Hpoefully if nothing else seeing the exact dependencies that worked on both Fedora 14 and Fedora 15 might help get it working on Ubunto.

I think it is possible that I never even tried to get the bitcoin wxWidgets GUI to work on my 64bit, Fedora 15 boxes, so maybe there isn't even anything weird and special installed on this box that made this compile work. (Other than it already has everything the -qt needed.)

Wow wxWidgets is huge:

-rw-r--r--.  1 root root 335759774 Dec 30 01:10 wxWidgets-2.9.0.Fedora15.tgz

I'll have to use sftp to put it on sunsite, web uploads don't seem to work for anything over a meg or few. It'll take a while to get there.

-MarkM-

[doublec]

Is the 25,000 switch on time 'official' now? Will there be an announcement for people to update nodes? We're at 23,770 as I'm writing this so it's not far off. I'd like to upgrade my node but don't want to do it if it's going to change. Are you going to add a checkpoint in the release?

[Unthinkingbit]

Is the 25,000 switch on time 'official' now? Will there be an announcement for people to update nodes? We're at 23,770 as I'm writing this so it's not far off. I'd like to upgrade my node but don't want to do it if it's going to change. Are you going to add a checkpoint in the release?

Yup, 25,000 is the official time. Because coding and testing went faster than I expected the switch will be at around block 25,000 instead of the 25,500 I originally said.

Everyone using the daemon must upgrade to Mark's latest devcoind release before block 25,000:
https://github.com/knotwork/old-devcoind

Block 25,000 will probably be around Jan 7, but don't wait, upgrade as soon as possible.

[doublec]

Block 25,000 will probably be around Jan 7, but don't wait, upgrade as soon as possible.

Ok, thanks. I've upgraded my node at bitparking.com with the new code.

[cablepair]

if anyone needs an i686 Linux binary

http://pool.devcoin.org/files/daemons/

that devcoind is the latest: knotwork-old-devcoind-266adc4

[markm]

if anyone needs an i686 Linux binary

http://pool.devcoin.org/files/daemons/

that devcoind is the latest: knotwork-old-devcoind-266adc4

They don't say if they are for 32bit or 64 bit?

-MarkM-

[cablepair]

i686 = 32 bit

if it were 64 it would say x86_64

[cablepair]

Devcoin Download Links
Download

Devcoin Source:
https://github.com/knotwork/old-devcoind

Devcoind 32 Bit Linux Binary (i686)
http://pool.devcoin.org/files/daemons/devcoind

Devcoind 64 Bit Linux Binary (x86_64)
http://btcnetwork.com/files/daemons/devcoind

This information can also be found by clicking the 'Download' tab at
http://www.devcoin.org

[markm]

We don't actually have a -qt that will still work when block 25000 comes around, and I already removed the old one from souceforge since it would break at that block anyway. For now people who want a GUI are going to have to deal with wxWidgets it seems; the old-devcoind actually has the old wxWidgets code in it, we just never used that back when the -qt worked.

-MarkM-

[cablepair]

ok thanks for letting me know mark, I will remove it from the download list

(excited for block 25000! )

[doublec]

I take it this means another coin added to the mmpool so if wanting it then a new user has to be created again to include the devcoin address you want the coins sent too right?

At some point, yes. I'll announce when it's available to register with a devcoin address.  There's a way to avoid this need to re-register using the message signing capability in recent clients but it requires a decent amount of programming changes to the pool. I'll look into doing that though to avoid the pain of re-registering.

For those keen on trying it, I'm using my own devcoin daemon, built from https://github.com/doublec/devcoin, which is based on the original bitcoin release that devcoin was applied too, devcoin patch applied, and a bunch of cherry-picked bugfixes (the same as I applied to i0coin).