It is not dead, I found 8 connections when I fired it up just now, and that is just the limit to how many connections you get if you don't have incoming port open.

Likely the IRC server is acting up again. Usually it does come online eventually so maybe just wait it out.

The coin needs some "stable" nodes - nodes running 24/7/365.25 or so - with stable IP addresses, to add to its fallbacks in the code so it will not be so dependent on IRC to find connections.

Maybe any exchanges that carry the coin will commit to also maintaining a stable public-facing node to help new clients bootstrap onto the network?

-MarkM-

I have a vague memory-of-a-memory of something about the BDB problems that led to the recent Bitcoin fork being able to abort a branch due to a BDB error, the error being handled in such a way the block was treated as bad instead of the system realising it had no real idea whether the block was actually bad because it simply ran out of BDB locks when trying to work with the problem.

That is, a re-org attempt would run out of locks and think like "oh I guess I was fine without a re-org".

It was why the bitcoin fork was going the way it was going I think, nodes with low BDB lock count would crap out trying to take one path of the fork and assume it was a bad block instead of realising they didn't have enough locks to be able to really process the thing to find out it was not a bad block just a bad (too low) BDB locks count limit.

We need to apply the merged mining patches to a recent but good/stable bitcoin to make a "bitcoin with ONLY the merged mining patches applied" repository, then each merged mined coin can individually fork off of that to add their own unique patches that make them the particular merged mined chain that they are. They could all do with a code update/upgrade.

-MarkM-

Both of my servers dvcstable01.devcoin.org and dvcstable02.devcoin.org get the same result:

./coiledcoind.sh getblockhash 179577
e654dad298eeccbcd74e90804a5ac1583a875a4fd08ed4e90844e44cd6806e34

./coiledcoind.sh getblockcount
195368

I thought most plans to watch for too-large re-orgs were going to go into don't do anything mode and display "please intervene or something" messages for operator to see,

I guess we can manually pick the longer chain and put a checkpoint at the divisive block-number but for sure it would be nice to find out what is really going on. Phase Of Moon (POM) errors are just so ... well... sacrificing goats to keep computers running was supposed to have gone out of fashion last millenium wasn't it?

-MarkM-

By receiver.cav it mean receiver_19.csv in this case. receiver.csv is just the base filename that the round number gets put into to name a specific instance of such files.

Apparently it either does not have write permission to write the file or the space in the path is making it maybe even think the directory it is to write the file to does not exist.

-MarkM-

Probably all the many and varied currencies will be abstracted away from vendors and POS checkout operators, just like credit cards or paypal does. Payment processors will handle all that stuff so the vendor simply gets the price they want in the currency they want.

Payment processors though could handle any number of currencies.

-MarkM-

Mined coins take 100 or 120 blocks ("confirmations") to mature, one is hard number the other is softer number the user interface says/uses.

It is so it would take an insanely huge fork/split/re-organisation to undo "matured" mined coins.

-MarkM-

It picks a random lbock number at which to go get next set of receiver files, I think it would have been round 19 it would have already got before reaching block  76000, then sometime before block 8000 it would try to get round 20. Possibly block 76221 is the random block number at which it decided to do that.

Is the receivers list number 20 in the receiver subdirectory of the data directory?

Extra copies of receiver files lying around elsewhere it likely will not even be seeing, unless by change they happen to be in the directrory that was the program's "current working directory" when it was run. (In which case it should have copied them to the receiver directory of the data directory).

I guess with all the flavours of coins though there is always the weird times when people seem to end up deleting the blockchain and re-getting it from scratch. Hate to blindly try that without knowing the actual problem though.

Is there any clue in the debug.log file that is in the data directrory?

Does it write something to console maybe about files it got being identical or not?

Does it actually have connections? It is not some old version is it?

-MarkM-

I have had devcoins take all night, sometime into next day, so maybe over 12 hours.

Just to even show up as zero conf.

If you send then close your client that can happen too, it can end up not getting retried until you fire up your client again.

-MarkM-

No, but, in general if you locate yourself (change directrory to; use the cd command) where they are, it will pick them up and put them where it actually wants them.

So basically if you compiled from a taraball it should have come with a bunch of them, in the main dir of the tarball. Both tarballs contain enough receiver files to get you started, so if you fire up the program while sitting right there it should pick them up and put them wherever it likes to put its datadir on your type of system, in a subdir named receiver of the data dir.

You could also try searching for wallet.dat, as where it ends up putting them should be in subdir named receiver of the dir where the wallet.dat is kept.

(If you have many coin types on your system, you'll need to guess which one is the devcoin one, hopefully the directory will have "devcoin" somewhere in its name to help you figure that part out.)

If mac os X is as similar to Linux as I have sometimes heard, then try looking for ~/.devcoin (a directory named .devcoin in the home directory of the user who runs devcoin.) The receiver files go in a subdirectoty named receiver inside that directory.

-MarkM-

Nice quick confirm on that one. Ten sends of 10,000 BBQ each are in my shell's input buffer waiting for daemon to catch up with them.

-MarkM-

And to think some people thought too many altcoins were being spawned!

Ironic, since maybe we haven't spawned anywhere near enough of them yet.

If everyone has choices of several hundred altcoins, most of which are small-footprint enough not to need noticeable amounts of server infrastructure and bandwidth,  the real bitcoin, divided into however many individual chains it takes, under however many names / labels / brands it takes. to be small enough to survive, will hopefully survive, while selloutcoin or bigbrothercoin or whatever the goons get the Foundation goons to make plays token blockchain for the bankers and corps.

Though they'd prefer to launch their own, surely?

Even more proliferation, maybe?

How about we tell them hey this is free open source, each and every code change you want you can implement in your own fork, and any combinations of them to your heart's content, go crazy, have fun, roll your own...

..And democracy can come into play as each individual chooses which blockchains they choose to use for what, when, where and how...

-MarkM-

I am running out of the amount I am willing to sell before the exchanges open.

Also I have not seen any higher prices be actually bought.

One of my buyers offered 10,000 for 1.6 BTC for example and no one bought.

Admittedly maybe because they figured they could get them from me cheaper. But maybe they figured wrong, since so far I am just servicing the same customers repeatedly. People wanting less than 100,000 can go buy retail from them now, no need to bother me over trivial sums.

-MarkM-

Sorry it took a while (I see 2 confimations on the BTC now), my bbqcoind takes a while to start up, even though I turned off -rescan to help it start faster.

The actual sends take a while too as it has to put together a lot of outputs to make a 10k send, I have managed a 15k send once but 20k it usually just cannot even do. So I'll be sending in 10k chunks.

sendtoaddress bQox2kACL4f9nb9YrvCzt46gXRHfwBW3Y5 10000
2c528b0c627c650ac1ffe63e925e9d39d87e24483945b86ffc7fd303e2b7ac67

-MarkM-

Oh good, still interested.

This price is not going to last, people. I only have so many I can part with this cheap, as I want to hang on to some to provide liquidity with when they go onto Vircurex and save some more for long term savings.

-MarkM-

Very simple fix:

In main.cpp, change line 36 from

static CBigNum bnProofOfWorkLimit(~uint256(0) >> 20); // Junkcoin: starting difficulty is 1 / 2^20

to

static CBigNum bnProofOfWorkLimit(~uint256(0) >> 30); // Junkcoin: starting difficulty is 1 / 2^30

Rebuild, run, and the whole difficulty problem goes away a lot.

If it is still too easy maybe go with >> 32 or >> 34 or >> 36 or whatever ends up working nicely.

>> 30 hopefully at least give us a few seconds between blocks, hopefully even the full minute that is the target time we are aiming for. If more than that at first that is good, as it would give time for more people to get aboard during the first "day".

This only fixes the difficulty problem. The "random" rewards will still be totally predictable.

-MarkM-

EDIT: I looks like it will need the genesis block to be re-mined though, as I think with this fix the old low-difficulty genesis block hash is causing problems: for example minerd gets error 500 trying to mine, so maybe when it tries to get work for minerd it realises the genesis block itself is not difficult enough...

p2pool supports merged mining.

You mine bitcoins using p2pool, but also tell p2pool about any merged-mine-able coin daemons you wish to merged-mine alongside bitcoin. So you can pick and choose whichever merged-mine-able coins you like, up to all of them if you have the RAM and bandwidth and disk space to run all of them.

Currently I have p2pool doing that on one 16 gigs of RAM machine, with all the coin daemons it is using all on that same machine with it, merged-mining BTC, NMC, DVC, GRP, I0C, IXC, CLC and XGG all at once. It works fine except that I0Coin dies regularly from a boost assert when boost fails to successfully do a DNS lookup. The rest keep humming along though so I just have to restart I0Coin periodically, which actually I could maybe even delegate to a watchdog script or daemon.

Adding seven more chains should not really be any particular problem. (Maybe use more RAM of course, but 16 gigs is hardly a large system so that should not be a problem.)

-MarkM-

Since it has now been established that it is fine and dandy to pre-mine, and also that it is fine and dandy for rewards to be random, maybe the day is fast approaching when the coins that retreated, for security, to Open Transactions can consider coming out into the open?

Imagine a coin worth 15.23244463 BTC per coin.

A coin so ancient that long long long long long ago the last block-reward was already given out.

So the "random reward" is in fact the "randomness" of how many fee-paying transactions you can put into a block.

If the fees were, say, 0.005 of a coin minimum fee, that would be 0.07616222 BTC per fee.

The coin would be merged-mined, along with many similar blockchains, lets say initially seven such chains, so if each chain yielded only one fee per block, that would add up to 0.53313554 BTC in fees across the seven chains, per block (on targeted average that is per ten minutes).

If no paying transactions are available, why bother mining? Wait until a paying transaction appears, then mine it.

Of course the more frequent paying transactions are, the more reward is available.

In practice, not all the chains would have quite such high-value coins. Sometimes some of them might have coins worth less than a bitcoin each. Then again, transactions might not be very scarce, possibly some of them might transact more than once per ten minutes on average.

Also, in practice, seven chains would be just the tip of the iceberg. More and more chains would probably jump aboard.

Is this too futuristic a concept still or is it starting to look reasonable nowadays, with all the experience gained in the last while?

-MarkM-

Except it is not random.

Everyone will know exactly which are the bonus blocks, and chain-hop onto just exactly those blocks, ignoring the chain the rest of the time.

Even if you use the hash of the previous block as seed, each time a block is mined everyone will immediately know what the reward on the next block is going to be, so again can immediately switch to that chain for that block.

So you have to use some kind of hash of the actual block you are mining, which only the miner will know, each miner seeing a different one until some miner solves the block.

Miners can re-arrange the transactions or try more nonces to try to not only solve the block but solve it in a way that gives the extra-large payout.

-MarkM-

It can easily be fixed.

Not a problem whatsoever.

The hard part is just the coding, to fix the future history.

The difficulty fix is just to >> 30 instead of >> 20, (or is it, 10 instead of 20? Hmm, think, think...), that will make it 2048 times harder, which hopefully will at least not be insanely easy.

The entire pre-mined blockchain will be rejected as having too low a difficulty, so will become a massive string of orphans.

So the new chain will replace it.

If a new genesis block is made, instead of simply skipping the test of whether the genesis block itself is difficult enough, then even the genesis block of the pre-mined chain will be rejected, the entire chain from genesis being orphaned.

-MarkM-

Did a fully accurate step by step guide to adapting p2pool to yet another litecoin clone get published yet?

-MarkM-