It sounds like what you are proposing, in essence or in effect, is that in some far future year when the 50 coins per block that GRouPcoin constantly mints happens to work out to be 2% of the number of coins generated up until that moment (up until that block, in practice), the time will have arrived for GRouPcoin to adjust its rate of coin-minting if, by that far future time, your theories as to what would be the perfect mining curve still seem to be as valid as they seem today and the benefits are actually worthwhile enough to actually bother to change the number of coins per block.

Thus I suggest that the coin you want is already up and running, has been for years, and still has years to go before it will need a tiny tweak to make its generation rate stick at 2% (or whatever percent has been determined, by that future point in time, to actually be the exact precise perfect percent rather than just some guess made by you years in advance of the actual coming into effect of such a rate change).

So we might as well just keep chugging along using GRouPcoin and simply add to our over the coming years concerns the concern that possibly it might prove beneficial, at some future date, to cause the generation rate to stick at some percentage of the total coins minted, so that over those coming years we can make observations and track statistics and so on that will enable us to know, come that far future, what exact percentage is in fact ideal. (If it does turn out to be 2%, how many decimals of accuracy is that? 2.0%? 2.00%? 2.000%? To what number of decimals has it been determined that "zeroes all the way down" is in fact the ideal?)

Basically though, there are years yet to work out the exact best percentage, in the meantime the 50 coins per block has been chugging happily along and will continue until the exact details of the later stage are worked out / negotiated.

Please note also that your concept of "annually" can be a whole can of worms, because nodes are not synchronised in time, their synchronisation is by block number. So we also will not even know how many blocks any given year will actually consist of until we know how much up and down see-saw of hashing power will be happening during that year...

(For example the advent of ASICs is likely to make a "blocks counted year" much shorter than a "calendar year" this year for bitcoin...)

-MarkM-

Adding our stable nodes to the client is, I am pretty sure, trivial, it is mostly waiting for an actual list of actually stable nodes. It is silly to need a bounty for that, it just needs me to input some IP addresses into the code in the same place where long ago I removed the IP addresses of bitcoin nodes. A minute or two's work, with the puublishing of the new version being motivated mostly by the desire to get another checkpoint out there to further secure the cold-wallet devcoins the DigiDeVCoin tokens on the Digitalis Open Transactions Server represent.

Doing things using hostnames instead of IP addresses I am less eager about because as I mentioned before i0coin dies on boost's failure to look up an IP address from a hostname. It is possible that the reason I0coin is the only coin I see doing that could be because it is trying to look up a network-time server by hostname, it might not, or might not *always*, be trying to look up a seed node by name or do some lookup related to clients it is connected to or trying to connect to. But it indicates that using boost to look up hostnames might not be a great idea.

Also, we are supposed to be plugging in STABLE nodes. If they are STABLE we should reasonably be able to expect at least some of them to still be at the same IP address for at least a few years. That is part of being STABLE.

The bASIC guy hijacked our entire devtome even though that was based on domain name not on IP address, so really if you cannot rely on someone to keep a server at a STABLE IP address I do not really think there is a whole lot more chance, really, that they will maintain a STABLE hostname either. A fuckup is a fuckup, I tried to warn the people ordering bASICs that the guy could not even administer the complicated task of renewing a domain when it expires (or was deliberately stealing our domain and content) so expecting him to actually produce an ASIC was massively stupid. They shrugged it off as if oh well who cares, so he cannot do the simplest frikking thing, so what, he will do this amazingly complex thing just fine...

So basically if people cannot even just frikking keep paying for the same damn IP address for a few years expecting them to maintain a DNS is like are you frakking crazy that actually takes maybe some knowledge not just throwing money at a hoster saying "I demand a fixed IP address".

If it IS safe to do DNS lookups in the code though, I don't mind putting in some hostnames on a domain whose DNS I control, and plugging our list (where is that list, by the way, I do not see it ha ha please lets come up with one) of STABLE nodes' IP address into DNS as hostnames. I can even spread the DNS providers / domain name providers out, as I have domains with Network Solutions and with Godaddy and with NameCheap, so even if two out of three of those providers goes down there will still be one provider left doing DNS for a host record that is (supposedly) the IP address of a STABLE node.

But, again, if the IP addresses are good its almost easier to put them into the code than into all three DNS/domain providers' DNS systems. And that allows us not to use boost's seemingly not all that great to use DNS-lookup code.

Maybe we should consider putting a "time to die" trigger in the code too, so people HAVE TO update their development-coin code regularly, it is after all all about development...

-MarkM-

I have been playing with DVC/BTC on Vircurex, and found simple tunnel-vision sets in. Basically I do not care what dollars happen to be worth or not worth, I only care that both my BTC holdings and my DVC holdings are increasing.

If LTC/BTC traders feel the same way, then as long as they are getting more bitcoin for their litecoins and more litecoins for their bitcoins as they trade it would require some third party arbitrageur to bother to notice whether dollars are going up or down relative to the LTC or the BTC or both.

This might well not be at all similar to the silver/gold markets because, well are there even any actual XAG/XAU markets at all or are there only XAG/fiat and XAU/fiat markets?

By XAG/XAU markets I mean markets where people are trading gold for silver and silver for gold and basically need not pay attention at all to whether all fiat or any fiat goes up or down since either way they are getting themselves more silver and more gold and those are afterall the things they are interested in. I have not noticed any major markets structured in such a way but maybe that is because I do not hang out in the back rooms of coin-and-bullion dealers?

-MarkM-

I don't hold the domain the devtome is running on, I hold a bunch of other domains that point to it or try to point to it. I say I hold them because they were bought for the project, they are not my personal property.

I have two dedicated servers that are my own (as opposed to the project's; I don't mean they are in my home they are third party hosted dedicated servers thus not secure, not good for hosting wallets and such. They have taken a while to get up and running as basically I got a good deal on evidently some old server hardware and we ran into some memory, disk and even ethernet-cable problems but hopefully now they should be pretty stable. I also have a plain old just-webhosting (php+mysql type webhosting) account elsewhere which can hold some small number of domains, an old spare devtome wiki is on that for example.

They have unlimited bandwidth so I am running all the merged mined coins on one of them with a p2pool instance to do the merging, and all the coins get to have "unlimited" connections. (Ports open; not sure if there is some default limit to number of connections that allows.)

So I now do have resources that could be used for hosting and such. I had not yet been thinking in terms of running a normal webserver such as Apache or whatever so don't have one fired up yet; I had been rather looking at things that act like a webserver themselves, java stuff such as Cyclos for example.

Something that would be really useful would be software that can read p2pool's data -r the bitcoin blockchain itself - and be used to pay people extra based on how many bitcoins a specific site's instance of p2pool paid them or how much actually productive mining they did on a specific site's instance of p2pool.

Basically p2pool cannot pay out more than 100% of the bitcoins it mines, so although it enables all the merged mined coins to be merged mines it does not seem to track the merged mining at all so there is not easy way to pay people more for mining on my Massively Merged Mining instance of p2pool than just their share of all the bitcoin that it mines. (So basically people can use it as a zero-fee pool but do not get any extra bonus for the fact that by using my p2pool they are providing hashing power for DeVCoin, GRouPcoin, IXCoin, I0Coin, CoiLedCoin and GeistGeld as well as for bitcoin.

The p2pool instance is at 198.154.60.183 on port 10332

You simply use a bitcoin address as username, password doesn't matter as its not used; and it pays you directly from the coinbase of the blocks the p2pool network finds. YOu can also point a browser at that port and it has stats you can see with pretty charts and such.

But it would be really handy to be able to run something monthly that I could for example tell an amount of devcoins to and have it divide out those devcoins to everyone based on how much mining they did. Since devcoin addresses are identical to bitcoin addresses and the users use bitcoin addresses instead of usernames it already has their addresses it could send devcoins to.

-MarkM-

EDIT: Note that this means 198.154.60.183 is usable as an -addnode for any of those merged-mine-able coins and for bitcoin. Hopefully it will be 24/7 stable now the initial settling in of the hardware seems to be completed.

Please do add it as an -addnode to devcoin because right now it itself cannot find any connections!

Latest git pull of feathercoind does not compile:


-MarkM-

No big deal, it just means you and your friend now have a permanent "joint account" you can both access/use.

-MarkM-

Be clear that DeVCoin goes to artists, designers, developers, musicians, authors, engineers and so on of free open source things; simply saying "developers" might lead people to think that means the developers of the coin itself, rather than to people working on free open source projects in general.

GRouPcoin is not a charity coin at all, it is plain old 50 coins per block, 100% for the miner who mines the block, forever.

Tenebrix apparently will address the pre-mined arguments when it officially re-launches, possibly even by simply destroying any coins that were pre-mined.

GeistGeld, like BBQcoin but for a much longer span of time, has been a haven for CPU miners for a long long time. It is unlikely to go away any more than BBQcoin did.

-MarkM-

I don't recall the exact details but I think when a bounty is proposed there is some number of days before which it goes into effect if not objected to.

So it seems reasonable that in a case such as this a few hours after the bounty was suggested someone would have objected "but that application already exists, someone just wrote it and put it online today, do we need a bounty to have more made, especially if more simply use that same open source code to make more sites using it for redundancy?"

On the other hand though such a situation (someone just went ahead and wrote something we would otherwise have needed/wanted to create a bounty for to get someone to write such a thing) seems like a potential case of aha what we have here is someone who already just goes ahead and writes free open source stuff that is useful, isn't that the kind of person who should be on the receivers list?

About that ten hours thing, is the receivers list thing ten hours a month not ten hours a week? Presumably since it is suggested one share vaguely corresponds to ten hours work?

I had written just recently somewhere that it is ten hours a week to be on the receivers list, if that is incorrect I hope it didn't discourage anyone who only does ten hours a month from applying to be on the list.

-MarkM-

Not to worry, I will pick up a bunch of them ready to do some market-making on the BBQcoin exchanges that are supposedly coming out any day now. Just a few million probably but every million helps, right?

I will be pleased to place them at more-appropriate prices.

-MarkM-

There should be a pre-order system where you can pre-order pre-mining licenses so that when (in 4 to 6 weeks...) actual ordering comes online you'll have a (pre-paid) position in the order queue based on your position in the pre-order queue.

To make sure the pre-mining is fair, it should not start until SHA256 and scrypt ASICs are in stock ready to ship at at least three competing ASIC-providers, so allow another 4 to 6 weeks for that...

-MarkM-

Both DeVCoin and GRouPcoin have constant rate of coin-production, also either Tenebrix or GeistGeld, I forget which (maybe both) maybe also does.

-MarkM-

Here is a start toward a plan or proposal to drive Alexa ratings.

We make for a few good reliable autosurf programs user-accounts for devtome.

These have multi-level, or at least one level anyway, of "referral credits" systems, so that if these devtome accounts on the autosurfs refer people to the autosurfs, they get a fraction of the credits earned by the people they refer (possibly even multiple levels down the downlines.)

A criteria for which autosurf(s) to use would that they must be ones whose reporting about your referrals reports how many credits each referral earns for you.

We then reward people in proportion to how many pageviews they cause these devtome accounts to earn.

Unfortunately we cannot know what sites or pages they themselves are spending their own credits on, so really this whole plan would be most useful to people who do have some use themselves for Alexa-reporting browser visits.

-MarkM-

 

You think writers would make multiple accounts to get around limits but that they won't make clever use of curl and, for example, Tor or open proxies or whatever means they can find to cause pageviews artificially?

Come to think of it, generating pageviews is exatly what auto, as distinct from manual, page-surfing sites are for. I could fire up autosurf.com or whatever it or its hundreds of similar sites are, and sit my browser(s) all night auto-visiting pages one page every five or six seconds, generating pageview credits at 1:2 ratio so for each page any of my browsers (including ones I run in dummy, headless Xwindows on various third party hosting) visits nets half a pageview-credit, those credits being automatically spent to buy pageviews for my devtome pages.

This would have the benefit of increasing the Alexa rating of the devtome, which is the main reason such pageviews are valued, because even though my browsers don't report to Alexa the browsers of a whole lot of people whose browsers my credits pay to have visit devtome will be using Windows, and Windows browsers apparently do report the user's pageviews to Alexa automatically by default.

(Yes, windows browsers are a form of spyware! Surprised, anyone?)

So hmmmm y'know, maybe using autosurfs to up my pageviews wouldn't be the worst way I could do it, Clever use of curl would avoid giving devtome any Alexa-rating boost and still give me lots of pageviews...

I suspect we'd be best off sticking to using advertising, so that the whole problem of figuring out whether the visitors are genuine/valid or not is foisted off to a third party advertising-agency that has staff and routines etc for figuring that stuff out.

If we could get pay per impression ads instead of (or as well as) pay per clickthrough ads we'd still end up getting paid based on pageviews but the work of figuring out if the views are good would be done by a third party. (Or, we'd simply get our adsense account cancelled for having too many fake visitors... Hopefully adsense though would simply only give us pay per clickthrough ads and no pay per impression ones if it only thought our visitors were bogus not our actual clickthroughs...)

This Alexa thing though... Apparently it was valuable once upon a time and might still be valuable. Having a bunch of people run autosurf programs all day and night could get us a ton of autosurf credits we could use to drive Alexa-reporting browsers to devtome pages. Even if no one actually sees the pages, Alexa apparently didn't used to know that and maybe still won't know that.

(I am not up on current state of the art. Autosurfs when last I used them deliberately did not care whether you were actually watching, even though some manual-surf programs that give you credits for spending X number of seconds on a page actually stop the counter while you are switched to another desktop and restart it when you return to looking at your browser. Maybe by now Alexa (maybe with Microsfot's help) has found a way to detect traffic that is driven by autosurfs. Seems not all that likely though else SEO people would not still be using autosurfs to increase their google pagerank by means of increasing their Alexa ratings...)

-MarkM-

I guess you could check the timestamps on the blocks to find out if there were any spans of time during which BBQcoin was "forgotten about",

My impression was that it was pretty much always running, even though probably most people who ran it just CPU-mined some number of coins they felt were enough of a stash to store away against some possible future time when the coin moved on from the early adopter CPU-mining stage to being dominated by GPU miners keeping the difficulty too high for CPUs.

Like Satoshi said, it makes no sense to ever delete a wallet, just stash them away in some dusty old repositories of backups in case some day they ever turn out to be useful. Since it is not old enough for even floppy disks people might have backed them up onto to have degraded from age it is pretty safe to say the vast majority of coins are surely safely stored in wallets in case they are ever worth the time it takes to go rummaging through your stashes of backup media looking for the disks or USBs or whatever that you happened to stash those particular files on.

I also know of lots of groups who have BBQcoins on their books at whatever nominal value they feel reasonable to list them at, as just another part of their inventory of assets.

I have not yet added the collated data to my historic tables and plots of asset values because I am still watching what values the collation routines obtain for that coin to get an idea of whether they seem sane before going to the trouble of pouring them into the archives of value and adding them to the scripts that build those web pages from the archival data, but for example right now I am being told the value is 0.96408952 DVC per BBQ.

That means I could probably pick up a few million - or maybe even several million - of them for that price, but I suspect as players start hearing about some outside the game exchange(s) offering better prices they are likely to start increasing their ideas of how much they are worth.

For comparison, the same cycle of value collation claims that GRouPcoins are worth 0.05756194 DVC each and I0Coins are worth 0.04324450 DVC each, so evidently BBQcoin are already imagined to be worth more than either GRouPcoins or I0Coins though not as much as DeVCoins.

-MarkM-

DeVCoin is crappy to mine.

It is good to MERGED MINE though.

-MarkM-

Back when I was making genesis blocks for oodles of altcoins for the Galactic Milieu project, it used to be that when the program crapped out saying the genesis block hash was wrong, it would show the current genesis block's hash (the hash it claimed was wrong).

Back then there was, near the top of main.cpp, a definition of what the expected genesis block was to be. That is what it was comparing to the actual hash of the actual genesis block we had coded in ourselves for our new coin.

So, we'd take the current hash the error complained about and plug it in as the expected hash to compare against.

So basically you run it once to find out what your actual new genes block's hash actually is, then code that in as the correct genesis block hash to expect and run again.

Of course since nowadays you want a nice high difficulty as initial difficulty, it could take many hours or days or weeks to actually compute a genesis block hash that is actually difficult enough to match the starting difficulty of the coin, but that is just a matter of pointing enough hashing power at it and waiting for however long it takes.

-MarkM-

An extended (to smoothly allow billions of people as receivers of generated coins) form of how DeVCoin works could do a "universal dividend".

You could maybe use a heirarchic pyramid of "receiver" files, to allow billions of people receiving coins without the clients having to directly deal with the full lists of all citizens of all nations on the planet.

So maybe for example put nations' national coffers into the receivers lists proportionally to their populations, then leave the actual splitting up of each nations' citizens' coins among the actual citizens to the national adminstrations.

90%, or whatever percent you can manage while still compensating miners for the dirt cheap task of merged-mining the coin, goes to the "receivers" instead of to the miners. Ultimately all people recognised by their nation as actual people eventually get some coins, provided they are responsible enough as citizens to ensure that they do not place into power over them, or tolerate in power over them, a government that fails to ensure each and every citizen gets their appropriate share of that nation's share of the universal dividend...

Not sure what to do about dictatorships etc - is there is any truth in the notion the people get the government they deserve?

-MarkM-

I had no trouble compiling Terracoin on Fedora 17.

I only had to make the same usual changes from makefile.unix to create a makefile.fedora17, those changes being to put in -I and -L pointing to my dependencies directory where I keep my "openssl with elliptic curves included" (because Fedora does not include elliptic curve stuff in its system-wide openssl) and to define the boost libraries suffix of -mt

Only Fedora, as far as I know, needs the fixes for including elliptic curves, most distros do have elliptic curves in their system-wide openssl.

So really only the -mt suffix for boost on some systems seems likely as something some other distros might need to do.

(Assuming you have the dependencies such as the right BDB libs, that is. The old version four BDB maybe isn't intuitively named in the packages system so has sometimes taken a bit of "yum search" to figure out which BDB package a particular coin needs that I don't have on some particular machine.)

-MarkM-

Well that might get political.

Basically it would be adding code into mainline bitcoin that it does not use, and its own usability will rely on that code sucessfully not being run when the code is running as actual bitcoin.

(Because the support for merged mining is a forking change: the blocks are different, so it requires the majority of the clients or miners or somesuch to all be using that new type of block some some day when it actually turns on.)

Basically you'd need to have an "#if BITCOIN" clause preventing actual use of merged mining if running actual bitcoin, in the same place where you would normally have "#if MERGED_MINING_NOW_ACTIVE" clauses in coins that actually do have merged mining activated as of some block-number.

Easier changes to get them to accept would be all the cosmetic stuff like putting all the names and icons and magic numbers used for handshaking and default port numbers and so on that distinguish one coin from another all into one place so it is easy to change the name and port and so on from one coin to another.

This is why I keep suggesting there should be a "bitcoin with ONLY the merged mining patches applied" repo maintained; all merged mined coins, even if they switch the hashing algo to scrypt, would benefit from such a repo.

-MarkM-

So give us the source code link! Your github repo for it or whatever!

Maybe even consider prepararing a pull request for it so it can be merged into the mainline.

Though ouch, it sounds like you may have wasted a lot of potential work-savings, because the very first thing one should do when working from newer bitcoin code is prepare a "bitcoin with ONLY the merged mining patches applied" repo, which can then be used by ANY/ALL merged mined coins as the basis from which to then make their coin-specific changes to go from "bitcoin if bitcoin had merged mining" to whatever specific merged-mined coin they are working on.

(Maybe though you didn't so much alter a new bitcoin to make it a devcoin but simply copy-pasted the wallet encryption code from bitcoin over to the currently in use devcoin?)

-MarkM-