New Ixcoin fork -> I0coin

[lightlord]

Send me i0coins and make me go 

I0coin add: jNijCd2j8aZW9KHySKJwcL5YqFwtYoBpkJ
Ixcoin add: xbdzj6wDQW86jjUZgQE77EhcQpzewj4Jk3
Btc add 19w8rFvE4wrd4K1VuVkdj7jUCs6fxKRssa
Sc add: sg81t9ordAaPFDGhVaD9fVMBCP2cyfoKw2
ltc add: LV5BP1BxqoDCUu6ysJ53sgZAC6866mioCR
fbx add: fVExye5RYL1FFwhFLFcaV2a5Wi2S5Mtr7L

[1714054567]

1714054567

[1714054567]

1714054567

[1714054567]

1714054567

[DutchBrat]

What ? NO Namecoin adress ? Too bad then 

[doublec]

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.

[worldinacoin]

Is there a need to upgrade to the latest version or can we continue using 7?

[doublec]

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.

[markm]

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.

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.

-MarkM-

[doublec]

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.

[lightlord]

Coinotron is using the new i0coin logo;
http://coinotron.com/coinotron/AccountServlet?action=home

Doublec use it on http://i0coin.bitparking.com/, I0coin + logo on top.

[markm]

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.

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

-MarkM-

[doublec]

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.

[kano]

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.
i0coin was created because of iXcoin and the fake scam person who created iXcoin - not to join with it.

Also note that merged mining anything means more LP's and more LP's equate to more stales and invalids.
People should consider that when considering merged mining also.

[doublec]

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.

[kano]

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.

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 ...

[doublec]

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?

[kjlimo]

Countdown to merged mining

160000-158101 = 1899 7:28 PST 12/18/2011
1617 => 2:02 PST 12/18/2011   

I think your math is a little off.. And this isn't really well summarized...

[DeathAndTaxes]

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?

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.

[doublec]

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.

[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-

[doublec]

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.

[DeathAndTaxes]

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.

Like I said if the pool is PPS then it doesn't need to advertise blocks so that is always an option.  Then again in a PPS pool you are simply being paid a contracted rate per share.  Who cares what the pool does w/ the hashing power.  Technically someone could open a PPS merged mining pool which gives you an option of payout currencies.  Totally hypothetical numbers:
1 BTC per 1,028,000 shares
1 NMC per 90,826 shares
1 IOcoin per 4,284 shares
or hybrid where pool pays out all 3 maybe even letting the miner set the % (i.e. 50% BTC, 25% NMC, 25% IOcoin).

In that case there is no deception.  The pool is simply paying you a set rate per share.  You can accept the offer or decline it.

The only "cheating" would be a pool which claims to be proportional and keeping part of the reward (hidding merged chains) to itself but that is very easily detected.  Any proportional based pool is going to need to provide records of the blocks it mines and catching the pool is trivially easy.  Remember the pool sends the block header to each miner on each getwork.  If the getworks don't match the blocks reported by the pool well it isn't going to be long before pool's hashing power goes to zero (regardless of the reason).  If a proportional pool refuses to provide records of blocks found it isn't going to survive either.