Topic: SmallChange [research-only] [Litecoin based] [15 seconds blocks] [*update now*] - page 3. (Read 26622 times)

Still if you are trying to make a new coin that is not litecoin, and litecoin supposedly derives in some way from bitcoin, the first thing you'd need to do is a diff of litecoin vs bitcoin to find out what things are different, that is, what makes them two distinct coins rather than one being a notwork-forking fork of the other's blockchain and network.

The name, the ports, the IRC channel, the address coding system that make the addresses start with different letters (assuming you even agree it is good to prevent users from being able to use one address for all coins, which is arguable), the magic bytes that make them distinct p2p networks and so on. Then change all such things, presto another distinct coin. RIght now you are basically just a hard fork of the litecoin network, forking from a point just prior to the genesis block (assuming you actually did change the genesis block?)

-MarkM-

For some updates (e.g. difficulty adjustment algorithm) that would be the proper way. Here the problem is that a few thousand peers of foreign nodes need to get out as fast as possible -- so I opted for this radical update-path.

that's the unfortunate side effect: the new and the old version will not talk to each other. As already offered, I can make connections to new version nodes if provided here in the thread or via private message.

Is there a node running the new update I can manually add to see if I can maintain a connection to it with my newly compiled build?  I can't even maintain a connection between the new version and the old version between my two virtual machines, which has me wondering if the two versions can talk to each other.

There are build instructions for Windows. Unfortunately I am Linux only for a long time already.. also I strongly believe in, everyone should compile his own binaries Maybe you could post if you run into compile troubles and we can help you fix them.

Depends on the transition speed. I expect the scenario to be like that:
assume there are only 3 nodes: n0, n1 and n2 with equal hashing power. At point t0 node n0 updates. At point t1, n2 updates and n0 looses all his mining efforts as n2's block chain must be higher because n1 and n2 mined on it up to the point where n1 moved. Finally at point t3, n3 also moves to the newer version, but his mining efforts are lost, because n0 and n1 naturally could build a higher block chain with their hashing power majority.


Please give it a few days time. In case you are on a permanent IP you can PM it to me and I'll connect to your node.

I had previously been using the windows binary.  I just compiled the new update on Ubuntu but am finding that it makes 1 or 2 peer connections at most, downloads zero blocks, and then disconnects from those peers with 30 seconds or so, and remains at zero peers.  Not sure what is going on.

So many questions, and all rhetorical.. I hope you're not disappointed that SmallChange never was intended as a real coin. You might want to check out the readme (github link), where I explained why I published the coin here at all

Some incompetent pretended to make a "new" coin without changing the "magic bytes" that differentiate chains?

That was, like one of the very first things learned about cloning bitcoin, where did whoever made this thing even get the diff they used to find all the places where one coin differs from another?

They compared a chain that also had not done it right against the chain that failcoin was cloned from, maybe?

Or just hadn't even heard of diff, maybe?

-MarkM-

After some testing and consideration the easiest way to fix is a hard move to a new network magic number which does not invalidate the disk stored block chain, but will only invalidate the disk stored peer information. This requires an update and the transition will most likely result in some loss of coins because the network will be split into two partitions until all have updated their client.
As more and more hashing power moves from the older version to the newer, the block chain of the newer version will at some point grow faster than the block chain of the older version which is going to be overtaken (but up to that point each time 'overwritten' when a client moves from the older to the newer version). Anyone mining on the lower chain looses out (which is going to be first on the newer version, but then on the older). Benefits to move to the newer version are that network connectivity will get better again.

Our hashing power compared to the LTC network or most other LTC based networks is low; hence our difficulty is also low and even if we achieve at some point a higher block chain than other networks, our block chain is most likely incompatible with other networks difficulty requirements.
Also - we have a different genesis block and our blockchain is also not going to fulfill checkpoint requirements of other networks.
Anyway: that's not so much the problem here. Part of the problem is that our network is very very small compared to others and unfortunately, someone seeded a few 1000 (~4000) node ips from a different network. Now the network code tries to establish connections to those other foreign nodes and because of a mistake on my part (didn't use a unique network magic number) those connections are successful up to the point where it tries to catch up with the block chain. All in all it takes a long time until it is found out that the block chains are incompatible, thus it

btw: IRC is not down, but the IRC nodes are only partly considered for connections. The clients exchange peer addresses independently of IRC.

The short version of this post:
--> Please update as soon as possible.

What would prevent us to do the opposite, that is, to build on purpose a longer chain than LTC, so LTC nodes would start to accept it?

Does the difficulty play any role, so that if LTC difficulty is larger than SMC one, the "disruption" can only be from LTC to SMC and not the opposite? Or it does not matter?

True, but how is that going to change this magic value in the user data files? I admit I could only look at the code briefly, but it appeared that the magic value is not only used in the network protocol. Also, as you mentioned: block explorers seem to require the (correct) magic value, hence I assumed changing it in a fast shot will invalidate the (disk stored) block chain.

I forked form Litecoin (see first post, github link).

Huh? Where else are they used?

You mean third party apps like block explorers etc?

The actual four individual bytes are defined only once in the entire code.

Change them there and all parts of the code using them use the new values.

You did not answer the question about whether you copied one other coin's unique magic bytes or copied the same ones it had already not made unique, so that maybe you and who-ever you copied from both are going to run into this collision of networks problem.

From where did you copy them? Had they made theirs unique?

-MarkM-

my bad; luckily such incidents help to improve things: e.g., the misbehaving client detection should have prevented that SMC clients believed they are behind the block chain. The problem is especially bad, because we got a few 1000 ip addresses from foreign network nodes seeded. Hence for now, please use something like that until I have an update ready*):
Any node ip from: irc.lfnet.org, channel #smallchange00 will do.


*) unfortunately it's not as simple as to just change these 4 bytes, as they are not only used in the network code.

How is it even receiving blocks from the BBQ network, though?

The 4-byte handshake magic-bytes are copied from BBQ to make it connect to them, presumably?

The whole point of the magic bytes that identify which network you are / which network you are trying to connect to is so clients know instantly whether an incoming call is actually for them not looking for some other network.

Was this coin copied from BBQcoin without assigning a new unique set of magic bytes to identify this network, or did this coin and BBQcoin both copy from some other coin and both fail to do that trivial but essential part of the process of creating a new coin network?

If the latter, both can also get into this same problem with whichever network their magic bytes are causing them to masquerade as.

-MarkM-

This has been possible because the SMC client got data from BBQ nodes and accepted it. All this with a bad receiving port.

So I guess someone with BBQ clients could easily send stuff to SMC client on purpose (just changing a port) to achieve the same things for all SMC nodes, right?

Interesting -- it appears that intentionally or not someone successfully disturbs the network.

\edit: yes at least a few clients claim that they already have a chain of size 349628.

My client suddenly says I'm 300 000 blocks behind.
We're around block 90 000 somethiong now, right 

 
It's meant to be a coin, silly!

The SC logo looks like a ball of dried dung. What is it meant to represent?

**Bump**

Hey, guys:

I created an SMC forum:

http://forum.smallchange.tk

An exchange:

https://docs.google.com/spreadsheet/ccc?key=0AgpTyKmDEFW1dFpJMGxsZEswcU56RElrUm5SVDFvbWc&usp=sharing

It's an excel thing.

Also, there is a bounty of 600 SMC set up by MaGNeT and I for anyone who sets up the first working exchange SITE!, and an optional block explorer.

SMC/BTC would be nice...

i dont even know what lightenup is waiting for ..
or maybe you want to make a perfect alt-coin )