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?
It does not need to be more difficult. You can merge mine i0coin or ixcoin right now as the primary with namecoin as the auxiliary even though those coins have a lower difficulty for example. You are correct that someone can use a private chain as the primary, one that no one knows about. For a pool though I suspect most people are interested in merge mining with bitcoins and that can only be a primary chain so 'pools mining hidden chains' probably won't be an issue. |
|
|
|
Merge mining leaves a signature in the coinbase transaction. A PPS pool which declares no blocks might be able to get away with it but no proportional pool could.
Yes but if a pool advertises it is merge mining 3 coins, but is actually mining 4 then it will hard for people to notice there's a 4th one there since there is a signature in the coinbase transaction for the others. They'd have to try and match up that signature with all known merged coins. A pool could even merge mine on a primary chain it doesn't advertise. Say, merge mine ixcoin, namecoin and i0coin with an unknown primary chain (a new one, devcoin, or some other). I don't know how users could track down what primary chain the pool is using. |
|
|
|
For example existing version of i0coin client has weired tendency to crash our pool every 2-3 days. I don't have time and resources to debug i0coind.exe.
Are you running any custom patches? What OS? The i0coind on my linux server running on my pool has never crashed or hung. |
|
|
|
I need to explain it to you?  I already pointed it out in the post you are quoting ... (LP's) Then of course you could easily check the blocks in both to tell ... The pool could not do LP's on ixcoin (or whatever they want to hide) blocks. They'll get more stales but it won't matter, they'll still get extra coins. What I'm trying to say is now that merge mining is out on lots of chains it's difficult to know if a pool is mining extra stuff on the side. Does it even matter if they are? |
|
|
|
Hmm, you mentioned in the other thread that you were considering merge mining of i0coin and iXcoin on a pool ...
That would certainly turn me away from it.
How would you know a pool was doing it? They could do it in secret and you'd be none the wiser. |
|
|
|
Not in any of the bitcoins or knockoffs I have looked at. The whole checkpoint thing exists only within the initial download section.
This is incorrect. The checkpoint is checked during normal operation of a node as it receives blocks from peers - only if it receives a block for the height that matches the checkpoint of course. You may be thinking of the fact that if a checkpoint is introduced but the hash is incorrect then existing nodes that are beyond that checkpoint continue to operate normally. This is because they don't re-validate the chain it already has. This is the issue the devcoin chain had with the invalid checkpoint that was introduced. If it were to receive a reorganisation that involved getting a block at the height of the checkpoint then it would check it. |
|
|
|
Seems to work, I've updated my nodes. I've also re-activated my ixcoin pool. Eventually i want to switch the pool to merge mine bitcoin/namecoin/ixcoin/i0coin when the chains become merge capable. |
|
|
|
Only if the code is changed to actually check the checkpoints during re-organisations.
Normally it is only checked when people grab the blockchain initially from scratch.
So if they do re-write, we have to hope someone has a backup that matches the checkpoints.
Correct me if I'm wrong but for the node to have got the block in the first place to be able to rewind back to it during a reorganisation then the checkpoint has been checked for it. The checkpoints are checked during the normal process of receiving a block from a node, not just the initial download. |
|
|
|
Is there a need to upgrade to the latest version or can we continue using 7?
The more nodes that upgrade the less risk there is of someone rewriting the blockchain back to the checkpoint in 7. |
|
|
|
Source and binaries for version v32508 of i0coin is now available at http://i0coin.bitparking.com. The only change is to add a checkpoint at block 155,000. I'm working on including the i0coin icons that were made by lightlord in the next version. |
|
|
|
|
You should not be using the patches from my branch as they've not yet been pulled in by ixcoin's creator. There are pull requests for them but they'll have to change the block switchover numbers. If you do use my branch you'll be on a fork which I doubt anyone will contribute to. It's unfortunate that the ixcoin creator didn't action the pull requests after requesting patches and offering the bounty.
|
|
|
|
Still don't see it in the newest client yet.
Still haven't gotten a response yet, looking to it hopefully.
I'm busy with other stuff for a day or two, but will take a look at what's involved in converting the images to what's needed for the client then. I'll checkpoint at the same time. |
|
|
|
The nodes go looking for the files based on the URLs provided in the previous files.
How do nodes know they've changed to get a new copy? Or do they try whenever a block is mined and they need to verify it? |
|
|
|
What do these receiver files do? Are nodes supposed to update to these new files or does it happen automatically? How can are node confirm that the files are valid - that the owner of one of the sites hasn't changed the file? |
|
|
|
/Volumes/video/working/i0coin$ grep -r Subsidy i0coin-v32507-for_building/src/*
../i0coin/i0coin-v32507-for_building/src/main.cpp: int64 nSubsidy = 48 * COIN;
../i0coin/i0coin-v32507-for_building/src/main.cpp: // Subsidy is cut in half every 2 years
../i0coin/i0coin-v32507-for_building/src/main.cpp: nSubsidy >>= (nHeight / 218750);
../i0coin/i0coin-v32507-for_building/src/main.cpp: return nSubsidy + nFees;
Don't understand the code here. I think COIN is 100,000,000. But what is nHeight and what does the operator >>= do. Is the nsubsidy halved every 218,750 blocks? Since nsubsidy is an integer I suppose it truncates it to an integer. 'nHeight' is the current block count. '>>=' is shift right and assign. Basically it divides the subsidy in half every 218,750 blocks. This isn't two years since i0coin has a different block rate time. It's about 230 days. |
|
|
|
Maybe i am completely wrong, but with PoolservJ made by Shadders, it's possible to add multiple alt-chains on merged mining, isn't it ?
I don't know if it's possible with existing versions of PoolservJ but it does work with the merged mining proxy so it should be. |
|
|
|
what what was the network hashing power during the double spent attack back end of september?
30-ish Ghash/s IIRC |
|
|
|
|
Looks like i0coin got past 150,000 safely so it has the timetravel fix activated. Next step, 160,000 for merged mining.
|
|
|
|
Most all IXC went to late adopters.
If you define bitcoin early adopters as those who mined in the first year then IXC has no late adopters... |
|
|
|
very cool design, now we have to get doublec to include it in the client  If I can get a patch, or files to replace the existing ones in the client in whatever format that uses, I'll do a build with those included. |
|
|
|
|
Show Posts
