Depends on version of Mini UPNP, its old code so wants old version.

If you've installed newer version the newer bitcoin versions use then yeah turn it off or figure out how to have two versions on your machine at once. (Or maybe make a virtual machine with old stuff to compile old stuff on and compile it statically, or whatever).

-MarkM-

Facebook basically removed a key -is-it-a-bug-or-a-feature of MySpace, to wit the ability to make such insanely horribly "gaudy" psychedelic pages that they hurt the eyes.

So for many it was a lack of a highly visible feature that attracted them to facebook.

Of course facebook has since bloated itself disgustingly so it eats so much system resources to keep a tab of it in browser that removing a shit-ton opf "features" from facebook to make something a heck of a lot easier on the end-user's resources might be able to blow facebook away similarly though hmm, makes you wonder, what about the famous "no one ever went broke by underestimating the taste of the American public" quote? Hmmm...

-MarkM-

EDIT: Twitter is an obvious no-go, right? Just a puny 140 character blurb and thats it?!!?! Never catch on...

It is on GitHub: https://github.com/knotwork/old-devcoind

So is the devcoin-qt: https://github.com/knotwork/old-devcoin-qt

I called them "old" because I wanted to take a newer bitcoin version as base to start making "new" versions of them.

Also, you do not have to put the receiver files into ~/.devcoin/receiver directory, they can actually be anywhere at all if you simply  change directory to wherever they are before you run the program (the devcoind or devcoin-qt program). It will notice them and copy them over itself into the "receiver" subdir of the datadir.

Another way of saying the same thing is to say if they are not in the devcoin data dir's "receiver" subdir then they must be in the so called "present working directory" of the program when you run the program.

Thus putting them in ~/devcoin should have worked fine IF you had been "sitting in" ~/devcoin when you ran the program.

-MarkM-

All the old stuff about the old Ripple thing all took the idealistic stance that you would issue credit to your neighbors/friends out of nothing, basically giving them a line of credit.

But surely you could equally well only issue credit in an amount equal to actual "deposits"?

Afterall, banks tend to have two types of credits they give you, the easiest to get is your account balance, which you get by making deposits and they grant in amoujnt equal to your deposits. Getting an actual "line of credit" is harder.

So here is how I see it non-idealistically working, taking that hard drive at the restaurant case for example:

1) The restaurant deposits with/in you a meal worth one hard drive, so you issue them credit equal to one hard drive.

2) The restaurant gives the employee one hard drive, so the employee issues them credit equal to one meal.

I am not sure why you give the hard drive to the employee, it seems to me you'd give it to the restaurant, and any deal they make with the employee is out of scope. So lets try again:

1) The employee deposits the meal with/in you, so you issue the employee the hard drive (deposit the hard drive with the employee).

2) The employee buys the meal from the restaurant with their wages.

That maybe works.

The important thing is, you don't issue credit until you receive a deposit, in this case a meal, and the employee does not issue credit to you until you deposit the hard drive.

This way it works like the credits known as "bank account balances"; the credit represents a deposit you already received.

The old Ripple system's documentation/propaganda/literature  jumped right over that stage, directly to "lines of credit", in which you issue credit before receiving the corresponding deposit, which is, of course, risky.

There is risk the other way around though too: the restaurant takes the risk that after depositing the meal in your stomach you will not see fit to assign them any credit in the Ripple system...

So its still the same old same old "who sends first" thing...

TL;DR: Want me to grant you $10 credit? Easy peasy: just send me $10 and once I have it secure in hand, I will grant you $10 credit...

-MarkM-

People are offering a bitcoin per hundred FReiCoin???

Isn't litecoin only about half a bitcoin per hundred? So that you are saying people are valuing freicoin at about twice the value of litecoin???

-MarkM -

Is the unpredictability of a kind that will make ASIC impractical? How about GPU? Does it give CPUs a massive advantage over GPU and/or ASIC, or any real advantage over them at all?

-MarkM-

All the merged mined coins need updating, so it makes sense to first update the merged mining patch to work with the latest bitcoin before worrying about the details that make the various merged mined coins different from each other.

Basically one can view the merged mined coins as being made by applying two patches to bitcoin, one being the merged mining patch the other being a patch that makes it into a specific coin variant. A patch that changes the name, the ports, the irc channel, the dns bootstrap, the hard coded bootstrap nodes, the checkpoints, the difficulty and reward details, the details of how to form an address from a key, to make the different-looking addresses some coins like to use, and the handshake four bytes that keep the different coins from accidentally crosstalking with each other.

-MarkM-

Is the version of bitcoin that i0coin is based on the most recent version that any merged mined chain is based on?

If not maybe it would make sense to take whichever merged mined chain used the most recent bitcoin version and make an i0coin based on that?

Or maybe just go ahead and apply the merged mining patch to the latest stable version of bitcoin or even just the most recent version of bitcoin, and make all the various altcoins up to date based on that?

Maybe if i0coin is the most up to date version of bitcoin that any merged mined coin has been built from the problem i0coin has is just waiting to hit all the other coins whenever they try to get more up to date with bitcoin? Maybe there is a gotcha waiting for all of them, maybe the merged mining patch isn't so simple to apply to recent bitcoins and all the coins are going to have to adapt in whatever way i0coin is going to have to?

-MarkM-

Actually I think the differences between namecoin addresses, bitcoin addresses and so on are merely cosmetic really, you take the same key and put a different prefix on it resulting in a different checksum and that gives you a different type of coin's so called "address" based on the key.

Thus you could actually take the same key you used for a namecoin address and create from it a bitcoin address, or litecoin address, or i0coin address, or ixcoin address, or whatever, using the exact same key.

Thus it should technically be possible to pay someone any type of coin simply by taking their namecoin address and building instead the equivalent address for some other blockchain.

It is even helpful that namecoin does not (at least not yet) have so called wallets out there yet that send coins on people's behalf without the person actually controlling the address the coins are sent from, as this means it is currently pretty certain tht an address someone sent namecoins from is an address they have the private key of, thus an address they could accept any kind of coins at on any blockchain simply by importing that\ key into the appropriate blockchain's wallet.

-MarkM-

Many times it has occurred to me that bitparking hosts various exchanges, so I go to bitparking.com to look what ones exactly they have but it just redirects me to their mmpool which does not seem to link to exchanges for the various coins so I give up and try vircurex instead where I can find mention of the various coins they deal in.

So maybe the problem is simply that bitparking does not provide any links to its various subdomains saying what subdomains actually exist and what services they offer?

-MarkM-

Ah so I have just been hitting it at a bad time when I visit, eh?

I didn't know this, hadn't seen this error with other block-explorers. Thanks.

-MarkM-

The purported explorer at http://www.darkgamex.ch:2751/ is still showing just an error 500, was this just another "put up a site for a day to get a bounty" scam or what?

-MarkM-

Free hosting with database and php is listed in my .sig, but I don't know about .asp, I didn't even know it was a kind of data file I thought it was a microsoft-specific page language one can use instead of php on windows systems.

Is there some reason why php backed by MySQL or postgresql would not suffice?

-MarkM-

http://darkgamex.ch:2751/ seems to be down.

-MarkM-

Characters running around actively foraging and crafting and so on 24/7 do consume server resources so obviously cannot be free.

So to some extent the sheer cost will prevent unlimited production, and by setting the cost on a per account or per character basis it will tend to be a losing proposition for characters who do not either do lots of rote labour or leverage their time by some kind of cleverness, possibly of kinds that scripts are not good at handling. Basically a human player who does not spend 8 hours a day playing might well be able to earn more than a same cost account fully populated with its maximum allotment of characters all doing dumb scripted work all their waking hours.

(As a really simple example, the human's character might be an employer, employing lots and lots of other people's scripted characters to do stuff the human player ultimately makes a profit on, in typical capitalist approach of employing lots of workers and profiting a little from each of them, adding up to more that you would make by being just another worker like them.)

-MarkM-

Not very clear on how to even create an account let aone actually play:


The Galactic Milieu uses Freeciv, with the Galactic Ruleset, to provide the large-scale backdrop against which individual-character scale activities take place. Since when a unit of settlers on Freeciv scale settles down, forming a small city, that city is listed as population 10,000 it seems evident that one Freeciv scale unit of colonists consists of 10,000 individual character scale characters. Thus a reasonable test of a wannabe civilisation's readiness to embark upon the Freeciv scale of play could be to have them demonstrate that they can muster 10,000 individual characters to all work together as one coherent unit.

That provides a motivation for fielding a lot of characters, but it also provides quite a large economy, since when a unit of settlers embarks upon a voyage to another planet to colonise it will be in space for most of a year, and in any case needs to be supported for the full game year that is one game turn (probably about a month of real time), which if we don't want scurvy happening on the voyage means probably millions of oranges or servings of orange juice or lemonade will be wanted as well as three meals per day per colonist. This adds up to a heck of a lot of foraging and crafting.

It could be argued that the colonists themselves could be gathering and crafting all the stuff they will need, during the turns some city spends building the unit of colonists prior to shipping it out, however realistically once some civilisation has graduated to the Freeciv scale of play it seems likely they will prefer to deal directly only with the Freeciv scale themselves; thus once they are a Freeciv scale civ they might not even bother with the individual character scale at all, to the extent that this is possible. They might well even prefer not to have individual characters sitting around in some individual character scale representation of their civilisation's capital city where individual character scale assassins might be able to sneak up on them and assassinate them.

But really the main purpose of the Freeciv scale is to serve as backdrop for the players who do enjoy individual character scale. Thus even if the Freeciv scale cities get to just keep creating settlers each game-year and sending them off to other planets with all the food and supplies needed being abstracted into generic resource units and food units by the Freeciv scale system, nonetheless all of that abstract economy should be reflected in the individual character scale. Thus even if the players who graduated to the Freeciv scale no longer care about details such as whether their starships are stocking up on oranges or berries or juice or whatever, the fact that those starships are active, the fact that X number of units of 10,000 colonists per unit are being shipped out still presents opportunities for individual characters to sell a whole lot of oranges or orange juice or lemonade or whatever. Millions of servings of such things. A lot of work for a lot of foragers.

That kind of thing is what motivates the kind of "CPU mining" I am thinking of, for which CoffeeMUD seems useful.

-MarkM-

Rather than even making a new chain that can be merged-mined with bitcoin to gain some of bitcoin's existing hashing power it might make more sense to use coloured coins right on the bitcoin blockchain, along with buying up ASICs constantly to keep increasing the hashing power.

-MarkM-

Mint all the coins from the start. Then who would even bother to compete just for a share of the transaction fees?

I suppose how much there is in fees would decide that, but hey if they made it merged mine able with bitcoin, they could get a whole lot of bitcoin's hashing power on board as well as whatever ASICs the founding banks choose to deploy.

Probably the main reasons this did not work out well for the Bank of Mars, Canuck Bank, Britclan Bank etc etc with their Martian BotCoins, Canadian Digital Notes, United Kingdom Britcoins, etc etc etc was insufficient transaction fees and an irrational hatred of altcoin on the part of bitcoiners.

Rather than try to depend on keeping their connection ports secret to prevent attack, they moved to Open Trnsactions for now, figuring they can move back to blockchain format when transaction fees are sufficient to attract miners to merged mine them, or maybe nowadays it might turn out that they might as well just use the coloured coins concept.

With coloured coins each bank could issue a new set of coins any time they want to inflate, and they can all deploy ASICs if they like to help the blockchain or just leave that to bitcoin miners.

-MarkM-

Three to six months might be too short a time to really see this, but now that even bitcoiners have actually felt a reward-halving I suspect that the faster the reward halves the better, as miners dumping coins ridiculously cheap might be a lot of what is keeping bitcoin prices so ridiculously low.

Maybe it is just taking a long time for all the massive hauls of coins from hacks and scams and thefts and ponzis to get cashed out, and for some time I figured ASIC makers dumping coins for fiat to build their ASICs with was doing some of it too, but I do think miners dumping coins does have an impact so for all coins the sooner the block rewards go down the better for the price, provided it does not result in a major exodus of miners.

Coins with no minting did run into the problem of not being able to find miners, but moving away from using a blockchain for the time being to prototect themselves from blockchain attacks does not seem to have hurt them, they seem to indicate that not having any more coins created ever is much more of a factor in price than being a blockchain is. Though whether they will plummet in price drastically come the day that they do move back to the blockchain format, possibly due to perceived danger of attack or even perceived danger of losing coins to hacks, remains to be seen.

-MarkM-

Last time I updated some altcoins to a newer version of bitcoin code, I created a patch file afterward to record what I had had to change, it is merged_mining.patch, at https://sourceforge.net/projects/galacticmilieu/files/

Bitcoin code has changed a lot again since then so I doubt it would apply cleany to new versions of bitcoin. But basically all the altcoins that can be merged-mined need to be updated.

Basically a r3ecent but stable version of bitcoin needs to have the merged mining patches applied and a new diff taken to give us a new merged mining patch that works with recent bitcoin code, then the patch can be applied repeatedly, once per altcoin, adding also for each coin the changes other than the merged mining as secondary chain, that make it different from bitcoin. Diffs should be taken then too, to get a patch for each altcoin that shows how it differers from a vanilla bitcoin with a vanilla merged mining patch applied.

Possibly various chains might like to offer some bonus/reward for their own chain's part of such a task, and going forward maybe the first step for any of them should be to first update the generic merged mining patch and release it, before going on to apply it to each chain.

-MarkM-