.

[MicroGuy]

.

[TierNolan]

What exactly are you trying to do here?  You want to fork litecoin, but remain backward compatible for pre-fork?

[coinerd]

What exactly are you trying to do here?  You want to fork litecoin, but remain backward compatible for pre-fork?

They're trying to clean up the code.

I assume from what's posted that GLD (and possibly some of the other flaky coins) is having some issues - crosstalk of some sort with LiteCoin.

The reason I mention other coins is because this could have something to do with several wallets trying to sync with a 300k+ block chain all the time.

The problem is (again extrapolating from this post) that changing these values is such a hard fork that you might as well call it a new blockchain. And they don't want to invalidate the entire block chain.

So they need to mod the wallet in such a way that the network identifiers change mid-chain, while accounts and transactions from both ends of the split are still recognized as part of the same chain.

Close enough, microguy?

Sounds like maybe the hardest fork-around I've heard of yet.

[TierNolan]

The fundamental issue is that litecoin users can connect to your network and will spam blocks/transactions?  Your clients ignore the blocks and the transactions, but it still causes spam.  This should only affect the nodes they are linked to, since they blocks/transactions shouldn't be forwarded, since they are invalid.

On connect, you can tell what prefix the other node is using, since it is in the version message.

An easy change would just be to make it so that any checks that happen will accept both prefixes.  Finding these locations could be done with a string search?

The timeline could be something like

until date A:
Outgoing connections: try new prefix then try old prefix
Incoming connections: will accept both
Network prefix: Use prefix that the peer accepted [ * ]

date A to date B:
Outgoing connections: use new prefix only
Incoming connections: will accept both
Network prefix: Use prefix that the peer accepted [ * ]

after date B
Outgoing connections: use new prefix only
Incoming connections: will only accept new prefix
Network prefix: translate old block's prefix to the new prefix
Break connections: if a message is received with the old prefix

If you have the keys to do alerts, then you could "spam" between A and B that people need to upgrade.

The effect is that internally, both prefixes are always permitted.  However, if a client connects with the wrong version message, the connection is refused.  This should eliminate accidental crossovers.

[ * ] This means that 2 new nodes will use the new prefix, but if either is old, then will use the old one

[markm]

It is not a blockchain fork, the handshake bytes are not in the blockchain.

it is purely a client-version fork.

Clients using the new handshake sequence will not talk to clients using the old sequence.

Other coins that have done this fix in the past have just used system date/time I think. Sure that means a few hours of ambiguity while some clients can be confused but it sorts itself out pretty quick if people's system clocks are not too far out of whack.

-MarkM-

[Stouse49]

It is not a blockchain fork, the handshake bytes are not in the blockchain.

it is purely a client-version fork.

Clients using the new handshake sequence will not talk to clients using the old sequence.

In the code (for Litecoin and Goldcoin) I found three places where the handshake bytes are saved into the block chain files or verified to match pchMessageStart.

1.  LoadBlockIndex
2.  LoadExternalBlockFile
3.  CBlock:WriteToDisk

Could we leave these parts as using the old sequence, while the rest (communicating with nodes, etc) uses the new sequence according to the transition plan (migrating old to new).

Other coins that have done this fix in the past have just used system date/time I think.
-MarkM-

markm, do you have an example in mind of another coin that has does this fix in the past?

[defaced]

It actually does split the network and you have to get everyone to download the new client because the old one will stop working. It wasnt that big of a deal for FRK because the diff was only around 0.001 and all 5 pools upgraded fairly swiftly. They will have to edit their pool code too btw.

The blockchain and everything else will work with out flaw. I hope my answer gives you some hope and guidance into the right direction.


Good luck!

[TierNolan]

It actually does split the network and you have to get everyone to download the new client because the old one will stop working. It wasnt that big of a deal for FRK because the diff was only around 0.001 and all 5 pools upgraded fairly swiftly. They will have to edit their pool code too btw.

Another option would be to have a few "bridge" nodes.  These nodes would connect to an old and new client and simply forward packets in both direction (without checking and just adjusting them to be compliant).

This would keep both (sub) networks in sync for a while anyway.

[defaced]

It actually does split the network and you have to get everyone to download the new client because the old one will stop working. It wasnt that big of a deal for FRK because the diff was only around 0.001 and all 5 pools upgraded fairly swiftly. They will have to edit their pool code too btw.

Another option would be to have a few "bridge" nodes.  These nodes would connect to an old and new client and simply forward packets in both direction (without checking and just adjusting them to be compliant).

This would keep both (sub) networks in sync for a while anyway.

This.

[markm]

It is not a blockchain fork, the handshake bytes are not in the blockchain.

it is purely a client-version fork.

Clients using the new handshake sequence will not talk to clients using the old sequence.

In the code (for Litecoin and Goldcoin) I found three places where the handshake bytes are saved into the block chain files or verified to match pchMessageStart.

1.  LoadBlockIndex
2.  LoadExternalBlockFile
3.  CBlock:WriteToDisk

Could we leave these parts as using the old sequence, while the rest (communicating with nodes, etc) uses the new sequence according to the transition plan (migrating old to new).

Other coins that have done this fix in the past have just used system date/time I think.
-MarkM-

markm, do you have an example in mind of another coin that has does this fix in the past?

Oh litecoin is a lot different from the SHA256 coins then I guess. I have never messed with litecoin based coins.

Either that or you are talking about something other than the 4 magic bytes the bitcoin based coins use to do p2p connections to each other.

Or heck maybe all the coins started to use it for more stuff later after all the years ago batch of coins had been assigned unique handshake byte sequences.

I don't remember which coin we first noticed the problem, after whichever it was then all new coins made it was already known that those bytes were among the things you change when making a new coin.

As to just changing the port number, that doesn't suffice, as people can pick any port number nowadays so malicious folks will of course deliberately do that.

The first ones changed might even have been UKB, CDN, GMC, GRF etc etc etc, even though they were based on testnet not mainnet so would only have potentially conflicted with testnet not the main net.

-MarkM-

[TierNolan]

Oh litecoin is a lot different from the SHA256 coins then I guess. I have never messed with litecoin based coins.

My understanding is that they simply have a different header to output hashing function.  It just needs to change that one function.  Even getwork is the same.

Midstate probably doesn't make any sense, dunno.

However, the network code is used to mark coins for save purposes.  I think when the blockchain is saved, each block is prefixed by the magic number.

[TierNolan]

Any thoughts, suggestions, ideas? Thanks Sunny and all others helping us with this problem.

Seems reasonable, he replaced all checks to a function call.

The persist parameter for the function is used to indicate if it is a disk or a network operation.  Network operations use the new prefix and disk use the old ones.

[Stouse49]

Any thoughts, suggestions, ideas? Thanks Sunny and all others helping us with this problem.

Seems reasonable, he replaced all checks to a function call.

The persist parameter for the function is used to indicate if it is a disk or a network operation.  Network operations use the new prefix and disk use the old ones.

This is from ppcoin 0.2.0 for the logic of determining the value for pchMessageStart:

Code:

void GetMessageStart(unsigned char pchMessageStart[], bool fPersistent)
{
    if (fTestNet)
        memcpy(pchMessageStart, (fPersistent || GetAdjustedTime() > nMessageStartTestSwitchTime)? pchMessageStartTestNew : pchMessageStartTestOld, sizeof(pchMessageStartTestNew));
    else
        memcpy(pchMessageStart, (fPersistent || GetAdjustedTime() > nMessageStartSwitchTime)? pchMessageStartPPCoin : pchMessageStartBitcoin, sizeof(pchMessageStartPPCoin));
}

When fPersistent is true (which happens in CBlock::WriteToDisk), then the New Prefix is used.  However, in my code searching, I found no instances in ppcoin where the value of the Prefix is verified when loading the block chain from the disk.

Litecoin derived coins have a new function called LoadExternalBlockFile, which allows the loading of an external block chain file using the command line option "-loadblock=<file>".  A change in prefix would break this code in the sense that an older block chain file couldn't be opened, but if it is never used, then it doesn't matter.