No more minting of new coins.

Transaction fees will still be there if any transactions that require them or volunteer them are there.

There is supposed to be somewhere around one and a half years left or so before minting stops?

The folk calling themselves Ixians have already been active about a year on MUDgaard and a character named Ix a few years before that on the CrossCiv Crossfire RPG server, but so far they have not gained a whole lot of traction. Though both the family-type clans started by them on MUDgaard, the Ixians and the Darlings, have at least leased some land so they can accumulate stuff without it all vanishing the way stuff does out in the wild normally on MUDs. So far though they haven't even furnished their plots, instead they are still living kind of communally with the Canucks, making use of their fountain and jacuzzi and supplies of torches and magic berries (that act not only as food but also as healing berries) and so on.

Actually I guess they are kind of slacking in that regard, since player-accounts allow having ten characters, five of which can be online at once. RIght now there are just the two of them, Dracix and Darling, and a few of their kids, still NPCs at the moment, following them around. Maybe the lack of fellow Ixcoin-advocates in those venues discouraged them from really pushing to max out usage of their accounts.

-MarkM-

Not hiring hackers, being followed around by them to harass you.

-MarkM-

NaMeCoin already provides storage. Just go ahead and store whatever it is you want to store in that. It does not restrict you to only storing information about how to find websites and such.

-MarkM-

http://www.devtome.com/doku.php?id=wiki:user:ranlo page not found.

Maybe uses other names for spam accounts?

-MarkM-

Oh nasty, if the database is really losing information gosh knows what other data it might have lost in addition to some of the users...

-MarkM-

Its a fool born every minute. Back when I was in high school there was a person born every minute.

"You can fool some of the people all of the time, and all of the people some of the time, but you can not fool all of the people all of the time."

So if an idiot is someone you can fool some of the time, then by now they might be being born faster than one per minute.

But if an idiot is someone you can fool all of the time, well, the who you can fool quote isn't a lot of help in determining their birth rate.

-MarkM-

Hmm I am still logged in from yesterday. I am not eager to log out to test whether login would work for me right now or not.

But I have been editing pages okay using my current login.

-MarkM-

As you may be aware, Ixcoin is an experiment to see what will happen when no more coins are minted.

Unfortunately it is a "sudden death" experiment: Ixcoin will go on minting 96 coins per block until, one day in the not so far away future, suddenly there will be no coins minted per block.

That is maybe a little more radical than really necessary since most coins taper off their minting, so that by the time there is no minting at all the number of coins minted has declined over time.

Ixcoin, being a long-established merged-mined coin, has a difficulty that is quite respectable as alt-coin difficulties go, so it would be a pity if the sudden death of minting caused merged mining pools to drop it or miners who merged-mine privately to drop it from their merge.

So it would maybe be a nice idea to try to get some transaction volume going on the coin before minting stops.

The hope would be that if there is some reasonable volume of transactions there will be a corresponding reasonable quantity of transaction fees to entice miners into continuing to include Ixcoin in their merges.

Thus the thought has occurred to me that maybe the "CPU mining" concept could be of some use in this matter.

Hitherto the idea had been that that kind of "CPU mining" would typically be used as a means of distributing coins that either avoided the use of a blockchain (due to the huge expense/security problems that blockchains involve) or secured their blockchain by some other means. Maybe Ixcoin could be used as an example of a blockchain that is secured by some other means?

In other words, since the Ixcoin blockchain is already secured by means of merged SHA256-based mining, it could serve as a blockchain for the proposed type of "CPU mining" provided that some actual Ixcoins were available for such "CPU mining" to distribute.

The difference between using this kind of "CPU mining" for a new type of coin and using it for an already established coin such as Ixcoin lies, of course, in the fact that Ixcoin has already distributed a lot of its coins and its miners rightfully expect that the remaining coins it will mint up until the sudden death of minting will be distributed to them as usual.

Thus in order for this kind of "CPU mining" to work with Ixcoin, it would be necessary that Ixcoins somehow be available for this proposed kind of "mining" to distribute. That basically means that "mining" operations of the proposed kind are going to need "capital investment" of Ixcoins. That is, a capital sum of Ixcoins that can hopefully be used to establish steady streams of transactions on the Ixcoin blockchain. (As it would be better to use the "capital" to set up sustainable flows than to just spend it directly on transaction fees until it has all een consumed by transaction fees.)

This thus leads to the idea of sustainable "CPU mining" businesses that are able to sustainably conduct and attract fee-paying transactions on the Ixcoin blockchain.

Which in turn leads naturally enough to the idea that a business, in order to be sustainable, ultimately requires customers to "do business with".

Research, experiment and in the field practice of this concept of "CPU mining" so far has tended to lead to designs in which the server expenses are covered by annual account fees; usually these annual fees, the cost to participants of one account on the server, is about one BiTCoin per year. Annual fees have been found to be preferable over using shorter periods not only because of the administrative/book-keeping costs of subscriptions and the renewal of subscriptions increase the faster people have to renew but also because longer minimum subscription periods favour long term participants over "quitters", "tire-kickers" and such and might even also discourage "griefers" from subscribing on impulse just to "grief" other participants.

This Ixcoin proposal though differs from previous work in this field in that Ixcoins are not proposing to distribute "newly minted" coins in this way. With Ixcoin we do not have some vast number of coins being minted that we want or need to distribute. On the contrary, with Ixcoin the minting is going to die a sudden death in the not too distant future. So one may question whether the trivial subscription fees other deployments of "CPU mining" are using would suffice in the case of Ixcoin, by considering whether just those subscription fees alone could possibly provide enough Ixcoins to enable the project to generate enough on the blockchain transaction fees to keep SHA256 miners merged-mining Ixcoins.

Would it be useful to charge much higher subscription fees for accounts on the server than other deployments of this kind of "CPU mining" have thus far been charging, in order to generate more income in Ixcoins?

Or would it be better to incorporate some kind of "capital investment" scheme(s) in addition to subscription fees in order to come up with "enough" Ixcoins?

-MarkM-

I am not convinved that all the receiver-file sites "blindly" duplicating whatever garbage some hacker manages to put on one such site is a great idea; indeed it seems to weaken the theoretical robustness that having multiple admins maintaining multiple receiver-file sites ought to be buying us.

One time I noticed Unthinkingbit had left something out, as when I ran the file-generating scripts I happened to notice the resulting receiver-files were not paying me at all; I knew I ought to be getting at least a little something for maintaining a receiver-file site so I questioned what was up.

Despite that I didnt really look hard at all the rounds since, maybe checked the first time I was in the receivers file but then just figured whatever problem had happened before was now fixed.

So I think it is probably a good idea that admins actually run their "get latest receiver file from site X" script manually and take some kind of cursory look at what it gets before defeating the purpose of having multiple admins "maintain" copies by blindly copying whatever hack some hacker manages to get into one site and thus give the hacker automatically a hack of a majority of the sites, as the whole point had been one would have to hack a majority of the sites to accomplish a hack that would effect/affect end-users.

Also even if cron is used at all, it surely ought not to be, like, "every day in case the files changed that day", but, at most, "when a new round is due, to get the correct new files for that round."

Furthermore, typically Unthinkingbit PMs me that it is time to generate the files and upload them to my site, I do that, then he checks them (presumably) before then contacting other admins informing them the next round's files are ready. Or, at least in theory, he notices a problem, such as that he had forgot soemthing on his end before telling me to generate the files, and tells me to generate them again as he has made a fix.

So having "cron" propagate that initial erroneous file everywhere in the meantime while we are still not in consensus even just the two of us that we created them correctly would not be a great idea.

For example sometimes he will PM me to generate them and upload them, I do, then days later he PMs me again to tell me so and so had not put his tip address correctly on his Devtome author page or whatever so now that is fixed I should generate and upload again.

Only once he feels that what I have generated from the component datafiles he has put in his charity-git directory I git pull from is good, and the remaining days of grace authors get for getting their tip address right and all that does he then proceed to tell other admins that a new receiver file (or when we add another host to all receiver files going back in time to make even past history more robust, a new set of receiver files) is available for them to grab from my site.

It isn't a great idea to have "cron" pull the intermediate draughts that are part of Unthinkingbit and I working toward a consensus on what the new files should contain and whether the copy on my site is ready for others to grab yet.

Admittedly changing our working methods so as not to upload to my actual site others grab from until after consensus could avoid that but would then also add another potential place for a glitch in that we could end up in consensus that what we created is good, without it actually being on my site others pull from yet.

The way we do it currently, by the time we think it is good it is already on the correct site others will then be told to grab it from. So he is checking in effect not only that they built correctly but also in the correct place where they will thus actually get grabbed, both by other admins (who hopefully doublecheck them before putting them on their own sites) and by end-user clients.

TL;DR: I think thus admins should not use cron, and should have two scripts/commands: one very seldom used, that grabs all the files, for those rare occassions when we update the entire set of files to make all the files list all the current file-sites; and one for the usual every round case, that just grabs only the latest files. That one they might end up having to use more than once if somehow Unthinkingbit tells them my copy is ready to grab from before the grace days are over and some new author urgently convinces him to squeeze them in at the last moment due to some gltich with their tip address or something.

(For all I know, it might be that Unthinkingbit tells just one other admin the files are ready, and waits for them to confirm we don't seem to have screwed them up, before telling another admin or more admins or the rest of the admins... We should maybe figure out what we'd do if Unthinkingbit got run over by a bus without our knowledge thus we didn't hear from him at all, too, maybe... s/maybe/probably/ ... s/probably/certainly/ ...)

-MarkM-

What is new about it? Is it based on the new I0Coin code that reduces the RAM guzzling merged mined coins experience?

Basically what is changed that would make us want to adopt this new version?

-MarkM-

I like you, but you are an idiot. An idiot with a charming enthusiasm but very poor posting discipline.

At least you do seem to want to learn and maybe even try to but your enthusiasms often seem to get in your way in that.

Enthusiasm is great and all but there is a related word "manic"; one is well advised to question one's own enthusiasms lest  too much "manic" lead one astray.

-MarkM-

I think one of the block explorers or blockchain info sites, maybe most/all of them, can show you how much in transaction fees a block had, maybe even a whole table showing many blocks on one page summarising how much fees they included if you are lucky or if anyone previously imagine such a table might be useful in some way.

You could look at various coins' explorers, to get a feel for how much they get in fees compared to how "big" or "major" a coin you think it to be.

You could maybe compare number of transactions per block to fees per block, stuff like that.

-MarkM-

Thanks. It occurred to me to look at http://galaxies.mygamesonline.org/inbtc.html ... Supposedly one Martian BotCoin was worth 309.49363387 BiTCoins some hours ago when that table was collated.

Cryptsy should be so lucky as to have someone trade a Martian BotCoin there. Even though 21 million of them exist, all pre-mined.

-MarkM-

Yeah, hard to get more conservative than to assume fees will be zero.

Ixcoin is not a Proof of Stake coin. People don't get paid for having lots of coins.

Also like darn near all altcoins the transaction fees paid to miners - when any are actually paid at all - are not based on how many units of measure of the coin are transacted. I am trying to use words carefully here because there is a usage of the word "coin" in which what one means by "a coin" is, under the hood, an output from a transaction. The more such things you use to put together the amount of value you want to send as one transaction, the more bytes it takes to represent and store that transaction, and that can affect fees, it can actually cause mandatory fees, ones that are not optional.

Maybe lets use the terms "coins" and "Ixcoins" as meaning different things. The "number" of Ixcoins you want to send someone is the normal how much money of that type is it kind of number, the number your balance of account is measured in.

In your wallet each transaction sent to you is distinct, some people refer to those as "coins". So if I sent you three transactions, one of 1 IXC, one of 5 IXC, and one of 9 IXC, those people would say you have three "coins" in your wallet, one is a 1IXC "coin", one is a 5 IXC "coin", one is a 9 IXC "coin".

It you wanted to send someone 14.5 IXC, under the hood all three of those "coins" would be combined into a transaction, with one output of 14.5 IXC to the address you want to send to, and one transaction of 0.5 IXC change back to your own wallet. There is no deterministic way for a miner to know whether the 14.5 is change going back to you and the 0.5 is the amount you are transacting with someone (or with another of your own addresses). So trying to charge fees based on "how much Ixcoin" was transacted is doomed by design. No one would stand for having to pay a percentage fee on the change just to get to keep their own change when they buy something!

Combining three "coins" like that maybe might not take more than 1000 bytes so maybe it might not incur a mandatory fee.

But suppose you liked to gamble on satoshi dice and/or run around to lots of faucets picking up tiny fractions of a coin. When you wanted to send someone, say, a quarter of an Ixcoin as a tip or something, it might take 25 or more of the extremely low "denomination" coins in your wallet to add up to a whole 0.25. If you look at the bitcoin tip you sent me, for example, on blockchain.info, you will see my tip address has only received one transaction ever, but wow the number of little portions of a coin in that one transaction is quite a few! Quite likely such a transaction would have incurred a mandatory fee, especially if some of those tiny fractions of a coin had only relatively recently arrived in your wallet. (We don't want spammers to be able to send millions of millionths of a coin to themselvesround and round in circles to clog up the blockchain, so we prefer coins to have sat a while, and use fees to strongly hint to people how much we'd like them to sit how long. )

Thanks for the tip, by the way.

-MarkM-

Wouldn't it make more sense to measure how many bitcoins or dollars or something worth of coin traded?

Especially since what will pay for more disk space and so on - server resources - is presumably the actual fees, converted into whatever currency such bills get paid in?

Why does it matter whether a million dollars of trade in a coin happens to be one billionth of the number of those coins that exist, or 100% of them, or whether it is a fraction of a coin or a billion coins?

Even if more than 100% of all the coins of a given type that were ever minted trade (due to velocity, every coin of it changing hands several times a day), if the fees on that don't cover the server/hosting/etc resources consumed it is one of the ones that needs to go.

Just being popular shouldn't matter if it can't pay its bills...

-MarkM-

Well then at $300 for something that miners could provide for themselves in the form of one or more milk-crates, a raspberry pi, an ATX power supply and maybe some extra RAM for the raspi, I suggest saving them not only that $300 but also gosh knows how much in shipping costs by leaving those things out...

-MarkM-

Okay, if the "prediction market" is a cover, then presumably the "in game productive activities" of CoffeeMUD players in my MUDgoldat40 idea would also be, in much the same way, maybe even in exactly the same way, a cover, right?

So that what MUDgoldat40 would really be doing is simply printing play-money with which to reward players who buy in-game "gameprofitinstruments" from in-game shopkeepers or dealers or shops or whatever?

The third prong of the trilemma is, as I suggested earlier, possibly of interest (pun intended?) there, inasmuch as if the number of MUDgoldcoins in existence increases then the exchange rate(s) of MUDgoldcoins vis a vis other currencies that aren't "inflating" their "money supply" at the same rate might possibly change / might well change?

Or is the big difference between MUDgoldat40 and the bitshares/bitwhatevers proposal fundamentally the fact that MUDgoldat40 proposes to print more MUDgoldcoins instead of to obtain existing MUDgoldcoins from some players and use those to reward other players?

(If the MUD used a blockchain for its goldcoins, and a hard cap on the total number that will ever exist much like Bitcoin has a hard cap on how many will ever exist, would that "fix the problem"?)

-MarkM-

But is run by RealSolid, of more fame or infamy than just Solidcoin fame or infamy, for whatever that is worth or not worth or anti-worth, right?

-MarkM-

Now it sounds reminscent of Satoshi Dice, which evidently was quite sustainable; plus it also gives some of the gamblers some of the transaction fees of the blockchain it is played on.

What it has to do with dollar or bitcoin pegs is not really evident in this latest description of it, but maybe the use of the term peg was distracting, especially given that it could call to mind the dreaded trilemma.

Use of the term interest was also maybe acting as a distraction, inasmuch as that, too, is a word that comes up in the "impossible trilemma".

Now we have gambling, in a form known as a prediction market, plus some people other than miners getting portions of the transaction fees of the underlying blockchain.

If Satoshi Dice is anything to judge by, lack of transactions on which to charge fees does not sound massively likely, though I guess that depends on how much gamblers happen to like this particular game and how well the gambling site aka prediction market is marketed.

Presto, no "interest", no "peg", just people betting on whether other people will bet high(er?) or low(er?)...

They aren't even betting on what the value of dollars or "whatevers" is going to be really, are they? Aren't they really only betting on how much other people will bet that it is going to be? So ultimately the "whatever" is merely a word/label/textstring, some bettors will bet higher for one "whatever" than they will for some other "whatever", so if you happen to know what a particular textstring/label I am here calling a "whatever" means in the language or culture or subculture of a particular batch of bettors that could help you guess what they are going to bet that other people will bet that that particular "whatever"'s value is going to be?

Couldn't you thus have, say, bitPoundsOfFlesh, and Shylocks will bet different amounts on it than non-shylocks, for example? In effect having a prediction market to predict what the given population of gamblers is going to bet that they collectively are going to think is the most profitable amount to bet on bitPoundsOfFlesh?

-MarkM-

The receiver files are not linked from anything at all, you'd have to ask for them by name, knowing in advance what names you want to ask for, one by one. Same for the account_##.csv files.

Of course in any given round there ought only be one new reciever file you need and, if you want the account file to match, one new account file. The older ones you would presumably already have by then.

They are not behind any login prompt, that login thing is just the php scripts of a php+mysql intergalactic mining game.

-MarkM-