With a CPU, maybe. How crappy a GPU are you thinking of?

I merged mined with one 5870 and was getting I0Coins fairly often.

Less often lately maybe due to more other people finally bothering to merged-mine, and way the heck less back when it was in bitparking's merged-mining mix, but so what, there has always also been GRouPcoin, CoiLedCoin and GeistGeld, they have always been pretty darn easy and mostly still are even now I think. Though as I recall GRouPcoin actually is higher the last few months than it had been for many months.

If all you have are CPUs, mine Tenebrix and Fairbrix.

Also if you actually care about it, you could add to the bounty offered for tools someone running p2pool with merged mining can use to reward their miners over and above simply providing them a zero fee bitcoin pool.

-MarkM-

EDIT: "difficulty" : 28.78879813 ... That means maybe one needs 28.78+ CPUs to manage to get a block every ten minutes if you are the only one mining? Or what? Maybe 28.77 CPUs should get a block a day? Or every few hours? Or what?

I didn't look at the code. For all I know it does do some more-complicated divvying-up at some point when it sees the inequality coming. I haven't noticed ever getting paid odd amounts though.

I don't like not giving people their money directly though.

So I would prefer filler lines be added to fill it up to a number that does evenly divide, with some long term projects or something that isn't critical as to whether it gets anything in any given round but will be long term useful.

Like our open source spaceship or something. In a few decades maybe it could accumulate quite a fund.

Problem though is, who holds such funds?

Maybe once the code is updated so that it has multi-sig, if it doesn't yet have multi-sig, some complicated multi-sig stuff could be used.

But so far heck its only a few coins, get over it!

Also, "should" is a poor choice of words. The shares are what they are. If they are on a line that gets more they "should" get more, if that is what the code dictates!

(The code dictates what "should" happen... )

-MarkM-

There haven't really been enough merged mined coins to properly find out what the realistic limit is of how many coins you can merge at once, so actually problem ones like I0Coin and GeistGeld have been useful because they are more trouble to deal with than most.

I0Coin has been humming along all along, it is just that most of the time there have not been a lot of miners who bother to merged mine anything at all, let alone the most troublesome of the merged mined coins.

IXCoin is still humming along too, though I am not sure what exactly happened regarding its bounties, did the pre-mine ever actually get paid out in bounties or not? The fact we so seldom hear from the author might mean he has dumped all he had and moved on, or it might mean he is waiting for the "Mergecoin" repo to be ready so he can offer a bounty for updating IXCoin using that repo so it is up to date with recent bitcoin code.

Or heck maybe he sunk it into mining hardware and has been mining on bitparking's merged mined pool to recover the IXCoins he used to finance mining rigs. I don't know. Does anyone know how much was pre-mined and, of that, how much actually got paid out as bounties?

Also, does pre-mine even matter? Everyone knows full well that each new pump and dump coin is going to be pre-mined in a matter of a few hours before even most people on the forum wake up and get to be one of the pre-miners so what difference does it really make whether the people holding huge numbers of coins wrote them into the code or raped them in minutes with a huge mining farm at zero or close to zero difficulty?

One thing to remember about all the merged mined coins is a whole lot of people who wanted to support merged mining, including ones who have coins of their own they wanted to add to the merged mining lineup as their motivation for wanting to merged mine, have not gotten around to it thanks to the bullshit spewed by Butterfly Labs for the last year or so. They kept putting off buying mining gear another two weeks in order to start out with ASICs instead of wasting" capital on gear that was about to be obsoleted in "just another few weeks". Once ASICs are ready to ship off the shelf at reasonable prices they can start gearing up...

-MarkM-

It can probably be manipulated any time the number of lines or shares or whatever does not evenly divide into the number of blocks in a round.

Earlier in the file means more chance of getting used more times than later lines in the file get used, I think (By used I mean sent money.) Unless some other which line first system is used than just first line is first. I am not actually looking at the code as I write this.

When the number of lines was small each line got used lots of times per round so the slight edge one could get by being one of the odd lines left over that got into the last few blocks was maybe not so significant, but if for example we had 3999 lines so each line was one block but the first line was the last block to make the 4000 blocks of a round anyone on that first line would get twice as much as the people on the other lines.

So maybe at some point it willl be necessary to make the rounds longer (more blocks) or something to balance such asymmetries, or maybe long term it could be blaanced by rotating the sequence of the lines though that would onoy really work for long term beneficiaries.

So far I had just kind of shrugged at that since there were so few lines, used to many times each in the round, that it was like oh come on you are getting free money does that horse really need to be looked at in the mouth?

But if people start actually trying to live off their devcoin earnings, and the number of times a given line gets actually used during a round decreases, I expect people will be wanting to look that particular gift-horse in the mouth...

Maybe we could start by working out each time exactly how many lines will get used one time more than some other linesa, and use that slight difference caused by position in the file deliberately as a slight bonus or penalty, by having some system whereby it is chosen which lines exactly (admins? devtome authors? etc; and even which individual persons) get to be the ones that get used once more or once less than others...

-MarkM-

One approach that turned out to be extremely successful as far as making the coin valuable is concerned was standing ready to buy your coin at a certain minimum price.

The problem with that though turned out to be it was hard to find miners.

So it is now looking like maybe the important characteristics are not only to back your coin but also to making mining obsolete.

Thus for example maybe the most successful approach is going to be to wait for Ripple server code to be released then base your coin on Ripple code.

That way you can afford to back your coin (since the only way anyone is ever going to get one is if someone gave you something for it, in which case that something is in your reserves standing ready to buy it back) and the lack of miners is not a problem (since Ripple does not use mining nor need it).

-MarkM-

Okay well if you do apply the merged mining patch to a version of bitcoin, please make a repo of just that.

That way all the coins can go ahead and update that far if they want to instead of having to wait for the patches to successfully get applied to the latest bitcoin, which is not as simple as applying them to the versions of bitcoin that still used Berkely DB.

-MarkM-

P.S. Sourceforge only got 1.1 gigs of the doti0coin.tgz but shows it on the list anyway even though that is broken. I am trying the sftp again.

SInce I fired up i0coin temporarily on my other server too you could try temporarily adding 198.154.60.183 to your addnodes, maybe with more nodes to get blocks from it will have more success getting blocks.

Sounds like you are not familiar with XRP then, the excuse given for even having XRP exist at all is that they are the anti spam measure, by making it cost something to do transactions, with XRP being that something.

Have you actually read up on Ripple at all?

-MarkM-

The purported rationale for the existence of ripples is as an anti-spam measure.

Thus if they are too cheap to convince people not to spend them on spamming they are not in a bubble, but if they cost more than is needed to keep people from blowing them on spamming then maybe a bubble might be in progress.

Or they lied about the real reason for them existing, and anti spam measure is just yet another excuse for spawning yet another scamcoin.

-MarkM-

How many billionths of a Ripple does a transaction cost?

If that is massively more than it takes to keep people from spamming the system with transactions, yes it is a bubble.

If it is low enough that spamming is cost-effective, then no it is not a bubble and in fact they should cost more (per transaction, not necessarily per ripple).

-MarkM-

Oh that is easy. Just use the forum's search feature...

-MarkM-

Okay now re-phrase that as X number of transactions = $1 and compare it to other transaction systems...

-MarkM-

YOu cannot do profiling looking for memory leaks etc if you cannot run the client, so you just need the current client and blockchain and a debugger / profiler, no hard fork no new bitcoin code just find the damn bug and fix it.

But better might be to help get the merged-mining.patch applied cleanly to the latest bitcoin code.

Then all the merged mined coins, not only I0Coin, can upgrade to that.

Fixing some ancient version is pretty much a waste of time since whatever you end up with will be obsolete almost as soon as the applying of the patches to latest bitcoin is complete, because once that happens I0Coin, IXCoin, CoiLedCoin, GeistGeld, GRouPcoin, DeVCoin, heck maybe even NaMeCoin will all be upgraded using that so will all be up to date properly.

Whatever bug there may be evidently is in no other coin except possibly GeistGeld, and certainly not in the latest bitcoin code, so is going to go away anyway as soon as this "Mergecoin" repo is ready.

-MarkM-

Every block of the round pays someone. It goes through the receivers repeatedly, so whether you are paid anything in the last block of the round depends on what line of the receivers file it was on at that block.

In short, it takes the whole round to completely pay everyone for the whole round. But some people might get their last payout of the round before the last block of the round, depending how many lines there are and how many times that number divides into the number of blocks in a round.

-MarkM-

Please specify a price that you think is a bubble. SInce no price is evident there seems no way to begin to guess what you even refer to.

-MarkM-

Huh? Forking the chain is a worse bug than simply using a lot of RAM. Geistgeld uses a lot of RAM too. It might even really just be due to all the dust transactions, since all available to be spent all live in RAM don't they? So most likely the massive amount of dust causes a massive amount of RAM to be used. I think dust transctions may have already been dis-allowed so maybe just paying people to consolidate all their "dust" could help decrease the size of the in-RAM txout set.

-MarkM-

So you are trying to 51% attack the i0coin network?

Or steal the name for some new coin?

Or what?

All the merged-mined blocks will not validate as valid if you don't have the merged mining patches.

If you update to very recent bitcoin though, I don't' think it bothers to validate anything prior to the last checkpoint, maybe?

So very-recent bitcoin code maybe might let you get away with having the real blockchain even though you cannot actually validate any of it prior to some checkpoint. Not actually sure about that though.

Someone actually wants a branch of I0Coin they cannot muster hashing power to actually secure due to it not being able to be merged mined?

-MarkM-

You have to have the merged mining, the difference between being able to be merged mined as a secondary chain and not being able to be merged mined as a secondary chain is a breaking change, when first adding merged mining to a coin you need to schedule in advance a block number at which merged mining will be enabled, the blocks are different from there onward.

If you wanted to fork off a variant that no longer can be merged mined as a secondary chain you'd need to do the same, schedule a block number at which the block format that enables secondary chain ability is replaced with the old format the blocks used to have back before the merged mining was started.

So basically to base off of bitcoin you need a copy of bitcoin to which the merged-mining.patch has been applied. To base off some other coin you'd need to base it off of a coin that already has the ability to be merged mined as a secondary chain.

This is not a change a few constants "sed -i -e 's/bitcoin/scamcoin/g' -e 's/Bitcoin/Scamcoin/g' *" type of job, unless some existing coin that already can be secondary chain in a merge has already been updated to the version of bitcoin you are trying to update to...

-MarkM-

EDIT: I am uploading doti0coin.tgz to https://sourceforge.net/projects/galacticmilieu/files/ it will take a while as it IS large, but it includes everything so should just need download time, no CPU overhead nor the database overhead of building indexes and so on. It won't show on the page until the upload completes. It contains a dir called doti0coin, not .i0coin, so untarring it won't walk over any existing .i0coin dir

Ah so the merged mining patch applies fairly easily probably?

Can you maybe make a repo of that bitcoin with ONLY the merged mining patches applied?

That way all the merged mined coins can upgrade that far if they don't want to wait for the repo of 0.8.x bitcoin with merged mining apatches applied to be ready for use.

Actually the merged-mining.patch might even already be against that version or a version close to it.

-MarkM-

What are you basing the newer client on? I am currently trying to apply the merged mining patches to bitcoin to make a "Mergecoin" repo that all the merged coins can then use to update themselves to new bitcoin code...

-MarkM-

I am using an old client too. There is a big tendency to get some kind of memory errors when trying to get the blockchain.

Maybe I can put a .tgz of ~/.i0coin in my sourceforge downloads directory.

-MarkM-