This thing isn't real scrypt, right? Its the deliberately bastardised pretend/fake scrypt deliberately nerfed for the convenience of botnets who are using other people's computers without their permission thus need to try to conceal the fact they are running?

How large a botnet are you running anyway, and why do you need a new coin to run on it, isn't litecoin already tuned ideally for botnet use?

-MarkM-

You seem to be shooting yourself in the foot by basing your claims of feature set of this new coin on features that, if you do in fact have the prowess to create them, would equally well be features if you did them using Bitcoin instead of some new coin.

You also are not really going full out on the one "feature" that does pretty much require a new coin: the ability to fully back every coin without your "reserves" being bled dry by "miners" creating coins and "dumping" them without any intention of "backing" them.

The folk who have been after me to make currency software for them to try their "backing" concept with at least do plan to go full-on with their concept: every coin will be issued in the genesis block, to them, at the outset. Thus no coins will be out in the wild for them to worry about "backing" unless/until they actually part with a coin, whereupon what they accepted in return for parting with it will be in their "reserves" for backing their currency with.

If your plan is to make cryptocurrency more accessible to grandma, soccer moms and the computer-illiterate, please apply those ideas directly to bitcoin. If you do a decent job of it, all the other alt-coins, of which we have plenty already thanks and more than you know of, can also adopt those same concepts thus each provide this very ease of use you claim to be hoping to bring about.

-MarkM-

This seems to have the one key feature that most of the people who had been having me experiment with blockchains for them have all along been asserting to be absolutely key: the "reserves". If all fiat that anyone pays for the coins on issue/minting of them is held as "reserves" with which to "back" the coins by "buying them back" (minus a small "spread", of course... but basically at close to what the buyer paid for them) then their value basically cannot crash massively, at most they can only creep down by the amount of the "spread".

It will be interesting to see this attempted on a larger / more public scale than the folk who have been having me muck about with code for them have yet been able to deploy. (Some of them have even put off the idea of deploying their coins in the form of a blockchain in favour of first establishing trade, a kind of "battle of the coins" in which only those that end up with enough transaction volume to support the idea of deploying them as a chain will ever end up actually doing so.)

-MarkM-

The "problem" seems to have been that the client recommended being a cheapskate instead of recommending paying a substantial fee.

Maybe this can be "solved" during install or something by asking the installer whether they want to install as a cheapskate client that is willing to wait days for their transactions to be processed, a normal home user client that won't be upset if some transactions take a day or few to be processed but would prefer most transactions to most likely be processed within a day or so, or a business client that would like a reasonable number of their transactions to most likely be processed within one business day or less.

Basically just multiply all fee estimates, starting with the current low estimate and multiplying by 2 or 3 for home users, 3 4 or 5 or so for business, Maybe two questions: home user or business user and low, medium or high priority. Then tell them also how to increase it even beyond that estimate/guess for very important transactions, like maybe tell them to double it or triple it for such transactions.

Since the only thing actually seemingly wrong is the client recommending paying too little, maybe forcing the user to make their own choice as to how stingy or generous the client's recommendations should be will "fix" it?

-MarkM-

SInce Gavin apparently does not have time to explain why Luke's solution is bad, can someone else maybe do so?

Or is everyone still flailing around trying to find something bad about it and maybe not having much success in doing so?

-MarkM-

I am able to log in to the DevTome wiki now, but I still do not see how one actually goes about editting a page. Is that something that needs separate activation? (My username there is knotwork).

-MarkM-

How is a 51% merged mining attack on Bitcoins not free if such an attack on other coins is?

Actually I'd think such an attack on bitcoin might even be better than free, it might be profitable, for example if the bitcoins gained by the attacker cause their electricity bill barely or not quite covered by the other coins to be more than covered, or even if the other coins already cover their operating costs any money they can make from also mining bitcoins at the same time would be almost pure profit.

Arguing that they might lower the value of bitcoins by attacking them doesn't really change anything except for people who already have quite a few bitcoins before considering the attack.

-MarkM-

Its fun to have huge quantities of cryptocoins, even ones thought to be pretty much worthless.

Since pool users evidently do't mind pool operators mining umpteen atlcoins without giving them a cut, all the pools might as well do it. We can use the coins in all kinds of games or something. It'll be fun.

-MarkM-

Cute. I was thinkiing of calling is Lukecoin or Dashcoin and then I find you seem to be thinking along the same lines.

(Last time I'd checked the block count was still increasing so it evidently wasn't dead, just being pre-mined by it's owner uh I mean pwner.)

I have been wondering if one potential solution might simply be to outbid other pools in the amount of reward offered to miners. Basically paying them in just one currency, probably devcoins, bitcoins, paypal, pecunix, or that liberty silver thing, and doing it as residual where the shares they submit all count toward perpetual (until they sell the shares; the pool would be trying to buy them as well as paying out on them) share of proceeds of all the ever increasing numbers of blockchains (not necessarily only coin blockchains) the pool works on.

Since there are many more blockchains that still do not have pool support, and at least some might potentially have some value, I am thinking such an approach might actually end up being able to pay more per unit of work than pools that merge only a few best-known chains.

-MarkM-

Well now you have me wondering, if I forgot to re-upload to SourceForge after some last-moment update to the github. I had had the impression that after the github version was completed I then made the packages that are now on sourceforge. So the sourceforge ones are intended to be the current latest working versions, I thought they are, but sleep/wake cycles lately have been such that you had me wondering. I was pretty sure they were fine until you posted that they aren't.

-MarkM-

Did something change on github since the packages on sourceforge were made?

-MarkM-

You still need to put the shared library (the .so) somewhere where your runtime linker will find it.

-MarkM-

The web-based Villages Online and Galaxies Online games have stepped up to the next level today: registration is no longer open to random passers-by.

Instead, players now need to develop their skills and/or resources using individual characters in order to accumulate or develop the requisites for founding a village or financing an intergalactic mining enterprise.

(The individual character scale of play is the CrossCiv server mentioned in my .sig ... You will need to make sure to pick a character type that will be in the Galactic Milieu not on the Fantasy world in order to have the potential to advance to the Villages or Galaxies scales of play.)

-MarkM-

After making and installing OT, you also need to make clean and make java to create the java lib, which you then need to put someplace where moneychanger will find it.

For me that place is /usr/local/lib, since the java client no longer seems to find it if it is in the same directory you are in when you run the client. I put moneychanger's jar and its lib directory in /usr/local/lib/ot, and have a shell script /usr/local/bin/ot_j that changes dir to there then runs the jar. I used to put the java lib in with the jar but that no longer works, thus nowadays I put it in /usr/local/lib and it gets found. (Albeit for a while my linker wasnt looking in /usr/local/ at all, dunno if that was standard or a result of some muck-up, but I fixed that too, had to else anything I built that put its shared lib in /usr/local/lib wouldn't work.)

-MarkM-

Thanks! Bitcoins received.

-MarkM-

Devcoin merged mining seems to be working elsewhere, but no sign yet that it is active at bitparking...?

-MarkM-

Are you going to also merge I0Coin and IXCoin?

I am mining at bitparking still, as he has also added DVC, but there is no sign yet that he has actually turned it on.

-MarkM-

I searched for 25000 in code cannot find it.

In the -qt I find it, with the word prodnet on same line.

Cannot find prodnet in code either except in -qt.

So I dont know what is up with my source code.

Ahh never mind, I was searching dev*, its actually in old-dev* directory.

Its >= GetAuxPowStartBlock so should start *at* 25000.

-MarkM-

Difficulty has gone down since few blocks ago, we lost a bunch of miners or something? Blocks are taking a while...

-MarkM-

Doublec wrote the patch, all I did was change 45000 to 25000. Does it matter a whole lot though?

-MarkM-