It compiles, the DiabloMiner is mining with it right now but hasn't found any blocks yet.

I don't know yet whether it might have messed with any of the finicky things we did in last few changes though, as it might have tried to fix the timetravel exploit which might laready have been fixed by the changes Unthinkingbit had me put in previously.

So hey, give it a whirl and see if it works with your merged mining pool...

The USL, again, is https://github.com/knotwork/old-devcoind

Basically all I did was apply patches provided by doublec.

-MarkM-

EDIT: it just mined block 23405, anyone have any problems with that block?

EDIT2: its a good bet that the same patches will work on GRouPcoin too!

EDIT3: now it has mined block 23406. Anyone seeing any problems?

EDIT4: ouch, I also mined 23407, 23408 and 23409, isn't anyone else mining? I am onlyt using about 220 MH/sec, it seems to be finding blocks awfully fast... Maybe something *is* wrong?

I have made at least a start at adding merged mining to the currenct devcoind code, which is now referred to as old-devcoind because I already created a clone of current bitcoin that hopes to become the new devcoin and devcoind.

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

I just tried to compile it using

make -f makefile.fedora15 bitcoind

and it didn't make, giving the following error:

rpc.cpp: At global scope:
rpc.cpp:1887:28: error: ‘getblock’ was not declared in this scope
make: *** [obj/nogui/rpc.o] Error 1

I altered the makefile.unix and makefile.fedora15 but not any of the other makefiles unless some patch did so.

I will push it now before trying to fix this error so other eyes can get at it as it is unlikely I got it right first time (as this error merely begins to hint at...)

-MarkM-

SLOSH - Simple Lucid Overlay System Heuristics

Also known as Slush's Lucid Overlay System Heuristics.

SLUSH - Slush's Lucid Underground System Heuristics (Or Simple ...)

-MarkM-

Hmm namecoin is a far more massive change from bitcoin than devcoin is, I had kind of been avoiding looking at namecoin because of that. It's entire transaction system and format is presumably different from all the other chains, all of which really don't change the actual chain much. Hmm.

Can namecoin basically just pull the bitcoin changes to keep up with fixes made by the bitcoin team or are they far too different for that?

I was glad to get away from wxWidgets, I do not relish the idea of going back there.

-MarkM-

The Galaxies and Villages games both need complete new grahpcis, open source. The more I glimpse of the commercial games they were intended to be similar to, the more of the graphics look to me to be stolen from commercial games. So I cannot trust any of the current set. A total complete full new set is needed for each.

The Villages game started off from code that said anyone can use it for anything, but then people working on it kept adding all kinds of outrageous claims to the whole thing every time they made some small change, even one that broke it all, anywhere in the thing. Basically the whole "ragezone" forum population seems to be about pirating games and trying to make money on their pirated versions, despite the site's claim it is about free stuff and its its rules against directly asking for money there. Most of the people clamouring for games there actually *want* then to use stolen graphics it seems.

Both the games use a system known as "skins", which seems to be intended to allow players who have a commercial "skin" (collection of graphics) at home to configure their account to look on their local disk drive for graphics. If they want to use stolen graphics that is how they should do it, but the developers seem to tend to just put stolen graphics right on the site, not onlyt as default "skin" but even as alternative "skins" for people to download.

We need "skins" that use truly open source graphics.

Also, I am not all that keen to try to directly "clone" an existing commercial game. So the efforts of those cloner people aren't really on the mainline of where I want to go. For example I had added to the Villages markets the ability to trade in the so called "gold" and also a few types of blockchain based currencies. That all got walked over in an early round of pulling "fixes" from others back before they started trying to add "all rights reserved" crap all over the thing any time they contributed a "fix".

Villages turns out to be a major "gold" hog, you really do seem to pretty much *need* to always have gold to spend. Trying to play it with "gold" seems like it would be pretty crippling. One guy who seems to be trying still has only one village wihile other players have 6 or 7 villages. Though he also doesn't put much time in either I think. I expected it to be one of those "put in time or put in money" type games where the proverbial kid living in his mom's basement keeps up with the folk who have real life jobs by being able to put in a lot more time than they can. But I think no matter how much time you put in you will still really need to at least be able to get 20 gold a week to keep all four types of resource at +25%. The bigger you get, the more actual resources 25% amounts to, so as time goes on gold should in theory be "worth" more and more resources per gold.

The "oases" and "heroes" don't work, nor the "treasury and relics" stuff. That all is maybe sidetrack stuff anyway, needless complication. Right now it seems to be a nice peaceful agricultural world. But there seems to be a problem with transportation: production is so high that the puny merchants system provided seems unlikely to be able to actually move all the resources produced to a starport or wherever to ship them out to the rest of the planet / solar system / galaxy / milieu. I think at very least an "autoship" system is needed that will have your merchants automatically shipping your produced resources for you. Right now most players' storage is full most of the time, it is inconvenient to manage to keep getting back to it often enough to spend the stuff fast enough to make space for more stuff.

The Galaxies one is much better in that regard, it does not take long to get enough storage set up that you need only log in to it once a day, and after a few months you can easily miss a day or few here and there. That is more the kind of laid back pace my players seem to prefer, sicne most of them are just using these systems as background bean-counters limiting the supply of resources much as mining speed limits the supply of *coins.

Income is still a bit of a puzzle, the Villages game assumes "gold" will be bought from the admins or hosters but that direct a model tends to end up with most players not bothering to buy any. As economies are the main way so for of linking many games into one larger milieu, most of the players expect to be converting assets they already accumulated in other parts/aspects of the Milieu into each particular world's local influence / favours / currency / "gold" when deciding to operate in/on a particular "world". In the long term, many of those assets did cost "real money" to create somewhere along the way in some sense, but it does mean each new game added tends to "sell" most of it's own local specialty item speciality resource or "local currency" to characters/entities that already built up a warchest / operating capital fund through various other games already.

If the Open Transactions server actually attracts traders possibly we will find that trading on such markets will provide ways of working on "the funding problem".

-MarkM-

I looked at merged mining code and it looked easy enough to add but we never got mining to work in the qt client due to some non thread safe problem that didn't exist in devcoind only in the -qt version. I wasn't sure if merged mining would fall afoul of that.

Plus, I we do not even know yet whether merely trying to use the new bitcoin that includes the -qt will break mining even in the daemon, so I figured we should get an up to date bitcoin-turned-to-devcoin first and make sure it works before trying to put merged mining into it.

Basically doublec wanted to try to add merged mining but I pointed out our code is from a way back when version of bitcoin.

Maybe though he could go ahead with adding merged mining to what we already have, in only the daemon not the -qt version, as if it turns out that bitcoin having brought the -qt into mainline bitcoin already breaks our mining we will end up having to use the old daemon for merged mining.

If anyone can figure out what the threads problem is i nthe qt and how to prevent it from killing mining in the old -qt devcoin, that could be helpful.

-MarkM-

Open Transactions seemed the most promising existent code for such things, and so I have been testing it. We have found a lot of showstopper bugs but they are getting fixed. Once we have Open Transactions working robustly we will have a better idea as to whether and how to integrate it how closely with blockchain-based systems...

-MarkM-

I think doublec figured out exactly which bitcoin I built from.

I hadn't used github nor git itself before so just grabbed tarball.

Then later a tarball of another newer bitcoin.

Now that bitcoin has included the -qt, I think it is probably best to fork from latest bitcoin, rename to devcoin which I hadn't been able to do in the past but doublec told me how to do it, then start trying to get all the changes we made to turn bitcoin into devcoin back in, this time with git's tracking helping us keep track.

A diff of the current devcoin against the bitcoin version doublec figured out as its origin should ensure we see all the changes that were made so we don't forget something; at first making alt coins was simple and I did it so often I knew offhand the few places one needs to change. But devcoin ended up running around all over the place chasing down all places where cents or minimum fees were mentions and figuring out which of the two to use; then also had a few fixes added latet like the anti dust-spam fee.

I guess its time to go try to actually make this new fork of bitcoin, lets see if I can manage to do that...

EDIT: git@github.com:knotwork/devcoin.git   BUT!!! WARNING!!! IT IS NOT DEVCOIN *YET* !!!

I need to figure how to put a warning on it, I'll start by trying to modify the README and pushing it back. People have to realsie it is really just a recent bitcoin that is about to hopefully get turned into a new latest devcoin.

Ideally we should try to do the fixes in such a way that one doesn't have to run around all over the place to turn bitcoin into devcoin, maybe not go so far as multicoin did where there is an actual runtime configuration file that makes it one type of coin or another, but maybe a compile-time similar concentration of the differences into one handy place where you define the coin type or something. As we will see as we go along with this that the changes are all over the place by now. Especially in the GUI interface where the name of the coin as visible to end-users needs to change.

So we should probably try to make it in a way that pretty much any of the alt chains could easily use the same code just by changing a few key things in a central file. Heck maybe if we do it right we could even get Gavin to pull it back into mainline bitcoin, since if it is done with compile-time defines it should still result in mainline bitcoin when those defines are not set to make it some other type of coin.

-MarkM-

I haven't any complaints so far about Unthinkingbit's management of the DeVCoin project.

Maybe a get rich quick mentality tends to drive a lot of altcoins into rush rush rush, I rather like the more relaxed / sedate pace that DeVCoin has been progressing at, and wonder if the lack of hype might be part of why it has been sailing along so smoothly so far.

-MarkM-

But the alpaca isn't a marsupial!

-MarkM-

In my opinion a lot of the delay has been simply waiting for merged mining in order to be perceived as having any chance against attackers.

The Coin Wars Two concept I just posted is one approach to trying to work-around this by permitting trading of coins of privately mined chains or even chains that are moving all accounts out of their old blockchain implementation to get away from the "you have to give miners the minting of the coins in order to get started initially" paradigm. (For example, chains that want to "back" any coins they allow to fall into other people's hands, keeping whatever they managed to sell them for as "reserves" with which to buy them back.)

How many chains can be practically merged-mined at once? Will any fast deployment of the entire allotment of coins chains ever reach enough transaction volume to attract miners on the bassis of transaction fees alone? Unfortunately the Coin Wars Two approach loses some of the perceived / perceivable benefits of using a blockchain, but what the heck, it might yiel;d some kind of insight(s).

Coin Wars Two is being implemented using an Open Transactions server, so smart contracts are definitely on the roadmap; but currently we have not quite finished getting markets working quite the way we want them to work so fixes in the markets system have delayed some further smart-contract work a few days lately.

-MarkM-

Okay, ready for Coin Wars version two?

There are folk who think that actually *backing* your currency might actually be helpful/useful.

There also might at some number of blockchains start to be limits to how many pools/miners you can convince to merged-mine your chain along with all the other tens, hundreds, thousands (whatever) of blockchains competing for a position on their merged mining priority lists.

Thus is born Coin Wars Two:

1) We don't actually implement the blockchains until we have first proven there is enough interest and enough volume of trading to make merged mining of it worthwhile. Thus we don't open it to 50%+1 attacks for example.

2) The folk who think *backing* might help will be able to do so without the barrier-to-entry aka moat that would be imposed by having to pay miners right off the bat before even having enough transaction volume for the transactions fees to be attractive to miners. (Most who want to "back" their currency do not want to "back" coins minted by someone else, thus in their vision miners earn transaction fees, not free coins out of thin air. In their vision coins do not come from thin air, they come from having assets stashed with which to redeem them.)

3) We might get to see whether "backing" coins can actually help stabilise prices.

4) Some blockchains that had been running privately are already setting up for this; most of those are based on bitcoin, that is, 21 million coins in total, ten minute blocks, eight decimal places, same fees as bitcoin etc etc.

5) They are setting up on my alpha test Open Transactions server whose thread is at https://bitcointalk.org/index.php?topic=53329.0

-MarkM-

I wonder how to illegally invent something.

Inventing something illegal is easy, but illegally inventing it?

Was he under some kind of non-competion contract at the time, binding him to avoid inventing things of that kind?

Did the writers of Ocean's ## illegally invent ways of stealing from casinos or just invent illegal ways of steal from casinos?

Is "illegally inventing" some kind of special highly technical legal terminology?

Under what circumstances is it illegal to invent something?

I could understand some inventions possibly being illegal to explicitly detail to the public or something like that, but one has already invented the thing proably prior to illegally revealing what exactly one has invented or how it works.

So this seems a very peculiar turn of phrase.

My best guess, I guess, is the ban of some kind, under a court order not to invent things, or not to invent certain kinds of things. But that would be very different from Satoshi's story wouldn't it?

-MarkM-

Try googling "Know Your Customer" ...

...And related regulations; money-laundering laws; war on terrorism; etc.

Meanwhile, after more debugging marathons we have done some essential fixes to Open Transactions to get markets working, and are re-starting the server "from scratch" with new version 0.75c asset contracts for all the assets. Everyone will need the latest Open Transactions and the new asset contracts. This time hopefully will be "for real".

-MarkM-

I am setting up my exchange to treat each asset (currency, coin, etc) as integer.

That not only eliminates the offers of 0.001 BTC, it also forces larger offers for larger numbers of decimals of price granularity. For example you can offer 1 BTC for 1, 2, 3, 4, 5 etc of something else, but to do fractions you have to make a larger offer, such as 10 BTC for 11, 12, 13 etc of something else, or 100 BTC for 101, 102, 103 etc of something else.

Comments on that idea are welcome. It is what I am actually currently doing but will anyone actually use such an exchange?

Its engine seems to tick every few seconds by the way; I suppose the rate of ticking could be adjusted too if need be.

-MarkM-

I have set up i2p tunnelling that in theory should allow people to connect to my Open Transactions server over i2p.

I haven't yet found anyone who uses i2p and has an interest in Open Transactions / *coin exchanges / *coin stock-exchanges to actually make the attempt to connect to it yet though...

-MarkM-

I have set up i2p tunnelling that in theory should allow people to connect to my Open Transactions server over i2p.

I haven't yet found anyone who uses i2p and has an interest in Open Transactions / *coin exchanges / *coin stock-exchanges to actually make the attempt to connect to it yet though.

-MarkM-

I sounds kind of strange to talk about friends playing poker together as a bad thing, whatever happened to weekly poker nights amongst friends?

Maybe one could start with two extremes: either you all agree together that you want a table, or each player plays as a lone human against a table of artificial intelligences that do not collude with each other. Basically either you want a particular group of players to play together because they all agreed exactly who they are and that they want to play together or you insulate everyone from each other with layers of artificial players.

Then you can get into securing the code of the AI players to be sure what code each is actually running.

Or you could digress into the fun game of each writing their own A.I. to do their playing for them, teaching it to recognise and collude with A.I.s written or deployed by friends or sockpuppets and so on.

You could do like blackjack, where there is a fixed set of rules the house has to play by, so examination of the hands afterward can check all the A.I. players strictly followed their rules.

Also, isn't anonymity in the sense of not having live video you can zoom in on each player's face in real time kind of against the spirit of poker? It is all very well not to know the player's real name and profession and place of birth and such, but surely a key element of poker is high resolution real time observation of body language and facial expression and so on?

Being able to cheat by keeping the other players from watching your face eyes body language mannerisms etc is surely so much of a cheat in itself that worrying about people colluding is kind of secondary, since if you cannot watch them in real time you cannot see whether they are chatting with colluders during the game?

If you eliminate the human element of actual observation of the skin tone, perspiration, respiration, eye movement, twitches and all that, then you might as well play A.I. opponents. Otherwise you are deliberately setting up almost ideal conditions for cheating then complaining that people might cheat! (You need good audio too of course, in case they try to mumble under their breath into a concealed mic or something...)

-MarkM-

Does the primary chain have to be more difficult - or at least as difficult - as the merged ones? Or could someone use some private chain no one else even knows about as primary and all the known chains as child chains?

-MarkM-

Not in any of the bitcoins or knockoffs I have looked at. The whole checkpoint thing exists only within the initial download section.

-MarkM-