SmallChange [research-only] [Litecoin based] [15 seconds blocks] [*update now*]

[noyvpom]

OK I think found the problem? I had forwarded the port in my router, but I updated the rule from the one I had for QQBcoin, and only changed the internal port! So my router was forwarding BBQcoin stuff from the external port 59333 to the smallchange client! People must still have had my IP in the bbq network and were trying to connect to me.
This explains a lot, why my blockchain kept thinking it was much larger, the 60+ connections etc. I wonder if I mined any BBQcoins to my smallchange address!? haha!

Too many coins, doh!

[1713886266]

1713886266

[1713886266]

1713886266

[1713886266]

1713886266

[1713886266]

1713886266

[ronaldinho_07]

- added a few checkpoints for current block chain + reenabled code that does the checkpoint checking

By curiosity, what are these checkpoints exactly? How does it work?

Look at src/checkpoints.cpp - there is basically a table of blocks where their height and corresponding hash is stored.
Each entry is a checkpoint and when the client rescans or downloads the block chain, it verifies it against those entries (i.e., there is no divergence to another illegitimate block chain).
Checkpoints ensure that the block chain stays frozen up to the (last) checkpoint.

it's still in "research-progress",isn't it ?

Yes, but why the sad face? research is fun
I'd really like to have more transactions though.. we need games..

At least at the current scale, the rules implemented appear to work well.

I'll release some metrics soon.. The diff adjustment should work a bit faster. Multiple blocks per second should be avoided.
I also want to look into pruning the blockchain and adequate tx fees...

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

[RichG]

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

[Praxis]

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

[RichG]

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

 
It's meant to be a coin, silly!

[binaryFate]

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

[lightenup]

My client suddenly says I'm 300 000 blocks behind.
We're around block 90 000 somethiong now, 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.

[binaryFate]

OK I think found the problem? I had forwarded the port in my router, but I updated the rule from the one I had for QQBcoin, and only changed the internal port! So my router was forwarding BBQcoin stuff from the external port 59333 to the smallchange client! People must still have had my IP in the bbq network and were trying to connect to me.
This explains a lot, why my blockchain kept thinking it was much larger, the 60+ connections etc. I wonder if I mined any BBQcoins to my smallchange address!? haha!

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?

[markm]

OK I think found the problem? I had forwarded the port in my router, but I updated the rule from the one I had for QQBcoin, and only changed the internal port! So my router was forwarding BBQcoin stuff from the external port 59333 to the smallchange client! People must still have had my IP in the bbq network and were trying to connect to me.
This explains a lot, why my blockchain kept thinking it was much larger, the 60+ connections etc. I wonder if I mined any BBQcoins to my smallchange address!? haha!

Too many coins, doh!

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-

[lightenup]

OK I think found the problem? I had forwarded the port in my router, but I updated the rule from the one I had for QQBcoin, and only changed the internal port! So my router was forwarding BBQcoin stuff from the external port 59333 to the smallchange client! People must still have had my IP in the bbq network and were trying to connect to me.
This explains a lot, why my blockchain kept thinking it was much larger, the 60+ connections etc. I wonder if I mined any BBQcoins to my smallchange address!? haha!

Too many coins, doh!

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-

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*):

Code:

./smallchange -connect=76.105.190.218 -connect=37.46.43.200 -connect=64.188.173.187

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.

[markm]

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-

[lightenup]

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.

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.

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-

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

[binaryFate]

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?

[lightenup]

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.

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?

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

takes shitload of time to find valid nodes. It also takes shitload of time for SMC wallet to realise some node is not SMC wallet, even though that other node is
constantly doing "sinister" deeds.

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.

[markm]

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-

[lightenup]

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-

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

Code:

[..]
So actually, this 'new' coin exists for the following reasons: [..]

[Kyune]

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.

[lightenup]

2013/05/10  please update now (move to a (hopefully unique) network magic number)

I need Win binary. I'm moving to Ubuntu but it is slow, I have been on Win for way too long. It will take some time for me to fully understand how compiling and other stuff work.

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.

Network will hard-fork on what block height?

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.

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.

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.

[Kyune]

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.

[lightenup]

If I understood correctly, you already hard-forked SMC? If yes, LOL, you shouldn't do it like that! You need to set some future block height an give miners enough time to
upgrade to newest version of the wallet. Unless 51% hashpower is using that newest version of the wallet things will go wrong and many will be really pissed once they find
out they've been mining on abandoned blockchain for days or weeks. Terracoin had 3 hard-forks in very short period of time and network is still in complete chaos due to
many miners or mere users of TRC never upgrading, upgrading once or twice but not three times.

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.

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.

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.