Topic: Devcoin - page 164. (Read 412955 times)

For some reason, I completely missed that reply.  Sorry about that.  I will try that now.  Thanks.

Did you try adding the IPs of the three amazon-based nodes as my shell script does as I mentioned earlier?

Unthinkingbit had me add al lthe receiver files to the realse thinking that woudl fix some problem windows people were having but maybe that doesn't actually fix their problem... Oh wait, you tried Ubunto too. Hmm. I guess I should try starting from scratch under a different user than the one that normally runs the thing... Annoying having to use only one machine nowadays (landlord didn't like electric bill), I'll have to stop mining to try this.

Hmm, it got a bunch of orphan blocks then end connection.

Unthinkingbit, could it be that somehow the changes for various adaptations of difficulty and so on have somehow get it to the point where the early part of the blockchain is no longer able to compute as valid anymore or something like that?

-MarkM-

Okay I tried again, and I still can't get it working.  I created a brand new Ubuntu 11.10 installation in VirtualBox, then downloaded and compiled devcoin-qt.  It runs, but stays at synchronizing 0%, 0 blocks downloaded, 3 peers.  Any ideas at all?

Markm, I am the admin of devtome, let me check it out, I know it was sending out confirmation emails before because I tested it

I will let you know...

Is something wrong with DevTome.org's outgoing email?

I signed up there figuring I could put some stuff on the wiki, but have not received the confirmation email and don't seem able to edit pages, which might be because my email has not yet been confirmed...

-MarkM-

just to clarify..

I understood this to be true as well, we were all told vinced was merged mining compatible however myself and a few other pool operators have had zero luck getting vinced namecoind to mine any blocks at all in merged mining not even on testnet

I can speak from experience that I have used ArtForz namecoind and it works with merged mining, I have personally merged mined Bitcoin and Namecoin blocks on my own pool with his daemon...

It was a mishmash'd mess, first I did fork iaanw's "bitcoin-qt", but then after downloading Unthinkingbit's stant on groupcoin or devcoin I basically ended up working from a downloaded, not forked or even pulled, version of bitcoin each time I started making a newer version of all the various alt chains I was working on.

For britcoin, botcoin, canadian digital notes, czech bitcash etc etc I pretty much remembered the few places on needed to change to make them from a normal bitcoin with minimal necessary hacks.

As I would start from latest fresh fixed bitcoin each time, I kept the hacks to a minimum, so one would even compile them as bitcoind then just change the name of the binary and tell it on the commandline what datadir and config file name to use (even those I didn't change in the code).

Groupcoin I am a little less sure what changes ended up in it.

Devcoin even more so, it has a whole header file of stuff only it uses, and hacks all over the place to change the magnitude of the default fees and so on. Each change made in bitcoin to make devcoind would have to be repeated in bitcoin-qt to make devcoin-qt, plus the devcoin-qt also tries to actually say devcoin in any user-visible places where it used to say bitcoin.

Now that bitcoin pretty much *is* bitcoin-qt instead of having all that nasty xwidgets stuff in it, hopefully there won't be need next time to duplicate the changes in two different things. And this time make a context diff or something so we know exactly what all the changes in total actually are.

Doing a diff of devcoind against a bitcoind source from back in the era it came from and also doing a diff of devcoin-qt against a bitcoint-qt from just before bitcoiin itself assimilated the -qt stuff should hopefully get a pretty good idea of what changes are the core devcoin stuff that went into both to turn them into devcoin versions. The -qt side will also have bunch of "cosmetic" changes chainging names that user sees, and also has stuff to turn off mining as the qthreads just would not let us mine it seemed.

Having another set of eyes do such diffs is probably a good idea anyway, in case somewhere along the line I managed to put something into just one of them that belongs in both.

I should probably delete the *coin repos I have under knotwork name on github, I don't use them and at I think one of them was Unthinkingbit's old original start towards trying to make a groupcoin or devcoin so isn't even really what its name would seem to imply it to be. Or maybe that was the one under his name and I used it straight from his repo not from any copy under my name. I think basically when I really made a release I used real bitcoin-qt from its author and real bitcoin from gavin, not any repo under my name or Unthinkingbit's.

I didn't learn until much later that with github one is expected to make a fork on their end to have something to push to, even when I did try clone instead of just downloading entire tarball I still used to just clone directly from author's repo thus later learn I could not push, any commit I did would be purely local to my own local machine.

Thus I gave up on pulling and just grabbed full tarball of what I wanted to work from.

I think I now have better idea how github is intended to be used / to work. But now one no longer needs two projects, one for the daemon and one for the -qt, presumably, if one starts from the latest bitcoin.

So maybe the thing to do is delete or ignore all the *coin repos from under my name on github, fork latest bitcoin, and start putting into it all the changes that are the same in both the daemon and the -qt version of the devcoin releases.

As I recall one problem I had with github is I did not see a way to tell it that I want to fork bitcoin BUT NAME THE FORK DEVCOIN.

I think at least one of the *coin repos under my name are misleading because of that, the name came from what I was using as original code from which to hack what I wanted to make. I never did find how to change its name so now cannot even remember which one that was. SO they all should go, I don't currently see offhand any potential use for them.

I now am down to just one machine, one of the 64bit Fedora 15 ones. The only bitcoin source I see on it is bitcoin-bitcoin-v0.3.24-0-gf087364.tar.gz so hopefully that is the one I last used as base from which to make the last set of updated altcoins.

Hmm on the other hand look at the dates:

drwxrwxr-x.  7 root root     4096 Jul  8 14:38 bitcoin-bitcoin-36aa6bd
-rw-r--r--.  1 root root   730076 Jul 20 04:47 bitcoin-bitcoin-v0.3.24-0-gf087364.tar.gz

Looks like maybe I actually used 36aa6bd, then later downloaded the gf087364 but didn't even untar it.

-MarkM-

Is there a git repository, based on the original bitcoin repository it was forked from? If not, do you know the commit id where it was forked? If not git do you have any version control repository?

Mark is making the releases:
http://sourceforge.net/projects/galacticmilieu/files/

I believe they are based on a version of bitcoin from at least a month ago.  The changes to make devcoin are relatively small, most are listed in the tech section:
http://www.devtome.org/wiki/index.php?title=Devcoin#Technical


I suggest setting the switch block number at 2,000 (about two weeks) after the block that merged mining is released on.  Most of the devcoin users are reading this thread and would switch within two weeks.

Note, the 120 bitcoin bounty is to be divided by everyone who helps bring merged mining to the devcoin programs, and later add devcoin merged mining to a pool:
https://bitcointalksearch.org/topic/m.591984

Since it would be you porting the code, Mark integrating it into the release, and Cablepair bringing it to the pool, that 120 bitcoins would be divided 3 ways, so 40 bitcoins each.  Having said that, in my opinion, porting the merged mining code is the crucial part that we're missing, so I'll add twenty million of my own devcoins to whoever ports the code.

ArtForZ didn't do Namecoin. 'vinced' did. I ported namecoin's merged mining support to i0coin and ixcoin recently. I could do the same for devcoin assuming it's similar. Is devcoin based on the standard bitcoin git repository?

You need to be aware that it's a blockchain forking change though. It'd have to have a block number that it turns on and all clients would need to update. Those that don't will be on an incompatible fork of the chain.

someone needs to patch the daemon in order to make it accept the merged mining, follow what ArtForz did for his namecoind fork that will give you a good idea

What exactly needs to be done to make it merged mining compatible?

yeah there is some display bug I need to work out but they are being calculated correctly

As far as merged mining compatible, the pool is ready to go as soon as the daemon is, in fact I have a namecoind and bitcoind already running.

Our pool will be merged mining within seconds of the daemon being patched compatible

there is a 120 BTC bounty for the coder who patches devcoind to be merged mining compatible so far I have not seen a lot of progress...

A) Notice how block 20,840 is listed twice and the rewards are over 4,950. 

My guess is that the rewards have been added together for block 20,840 and 20,839 and the block number is a display issue.

20841    28    12/07 3:48 pm    51.83 Min    436    3542.20183485 DVC
20840    29    12/07 2:57 pm    3.07 Min    9    7005.62499999 DVC
20840    30    12/07 2:53 pm    17.75 Min    9    7005.62499999 DVC
20838    31    12/07 2:36 pm    8.67 Min    58    3328.44827585 DVC

B) Also, could some commas be added to numbers over 1,000?  It's tough looking at millions with no commas.

C) Last point. I found somewhere advertising that devcoin is "merged mining" ready.  How far off do we estimate merged mining is?  Is anyone working on that right now?

I have 6 receiver files, all in my devcoin-qt directory on my desktop, where I'm running devcoin-qt from, not in the .devcoin directory.

receiver_0.csv through receiver_5.csv

I had problems with the download of blocks some weeks ago, it was because of the missing receiver CSV files. Do you have them all?

I wonder if maybe it is cycling from one person who has no incoming port to another or something?

You claimed it had three connections, are those incoming connections from people reaching out to it or does it have no incoming port through its firewall this maybe is connected to possibly the only three out there that do have an incoming port?

I wonder if there is some mode where it can claim to have a connection but the connection is in some sense not really working or maybe isn't even to a devcoin node.

Does the debug.log offer any hints? Usually that will show if attempts to connect are failing and stuff like that.

I notice I have

   -addnode=50.19.210.139 -addnode=107.20.209.11 \
   -addnode=107.20.228.112 \

in my startup shell-script, those are probably the three nodes someone set up on amazon virtual machines.

Are those the three connections you have, I wonder?

Maybe try putting them with -addnode like I do to make sure it tried them, see if that helps?

-MarkM-

Sorry to keep harping on this, but I still can't get the block chain to download in devcoin-qt. Does anyone have any ideas of things I can check to try and get it working?

At current difficulty 160 and hashrate 800 Mhash - it's really on average half a million DEV per day. But difficulty is changing every block - so it's all very speculative.

Note that we deliberately made devcoin addresses look exactly like bitcoin addresses precisely so that you can use an address that is generated on a BITCOIN you run yourself if you don't yet run devcoin yourself. Then some day if/when you ever do get into devcoin, you can export that bitcoin address from your bitcoin wallet, import it into a devcoin wallet, and find your bounty devcoins waiting for you in the devcoin blockchain.

-MarkM-