wrong forum section.
Also this is no FPGA device and requires special software (probably not written yet) to do any kind of mining. It appears to me that it has a lot similarities to a GPU card, but without *a lot* of documentation about the design of the card and its programming model I don't see that you can use it for mining anytime soon :/

I think its the first possible cause you suspected: imo, the oscillation mainly occurred because of the small user base where especially users with relatively high hashing power only contributed when difficulty was low.
Further, I think that problem can be mitigated technically by a more advanced diff/block reward adjustment (or a higher (competing) user base).

True, but it might be better to further increase the max block size and also increase the target rate a bit if latencies become a problem.. but that's probably better evaluated in a faithful model of smallchange (e.g., Matlab).
Smallchange's main goal is to provide a high transaction per second (tps) rate to be feasible for micro transactions.

Here the data up until about 2 days ago:
https://github.com/bfroemel/smallchange/blob/master/data/20130520/blockstat.dat?raw=true
It includes extinct blocks -- at least the ones I could obtain.

and some visualizations:

https://github.com/bfroemel/smallchange/blob/master/data/20130520/hashratevsdiff.pdf?raw=true

https://github.com/bfroemel/smallchange/blob/master/data/20130520/blockrate.pdf?raw=true

For both plots, I use the block height as 'time' and not real time. Blockrate is only up until block 90 000 (before the switch to the new network magic).

Most interesting are the startup phase (16 000 to 40 0000) and the network fragmentation caused by the network collision (starting at around 92 000) until it is resolved by the switch to the new network magic number (~ 104 000).

As can seen in the blockrate plot, difficulty adjustment has room for some optimization. Each time difficulty went down, people threw their hashing power in and mined as long as difficulty remained low.. causing the diff oscillation of about 72 hours - that's about 2 times the time that is considered for the current difficulty adjustment algorithm.
Interestingly (not visible in the graphs, but the raw data), the extinct/stale block rate (blocks that divert from the main chain) is rather low - even during the times where several blocks were found within the same second/timestamp. That rate peaked during the network collision period.


see my argument here:
https://bitcointalk.org/index.php?topic=182430.msg2040013#msg2040013
which basically is: max blocksize remained unchanged, because it only restricts the number of transactions per block. Smallchange pursued the goal to be a microtransaction currency and that means we'd need to support lots of tps.

Overall, the network hash rate has peaked during the period where block rewards started (about 30 MHashes/sec). We are currently at block 136 436 and the current estimated network hashing power has stagnated to 0.25 MHashes/sec which means that this little experiment is basically at its end
-> It's been fun, I've learned a lot - thanks for all. I might work on difficulty adjustment in the midterm future - if anyone wants to try out things with what I started, I am always happy to review/comment on them or take code contributions.

\edit: small error in the blockrate plot: it's not blocks per second, but diff time between two blocks -> should have applied f(x)=1/x .

Not to devalue your work and efforts in any way, but I don't think that an exchange or a whole forum is currently needed for SMC, but SMC is in desperate need of novel ideas and implementing them
-> of course, if it is (still) fun for you to make those things, do them by all means.

Thanks - a permanent non-NAT node is very appreciated (if you don't change your mind ).

Also even without providing a list of nodes, I can find and maintain right now 4 connections.

Hmm.. that should not have happened; strange. Any more (earlier) messages in the debug.log? At least on Linux with the command line node software I had no problems. Even the peer database was gracefully reinitiated because of the changed network magic.

As soon as I find a few hours free time (probably next weekend), I'll upload some metrics with a timeline of the 'major events' and try to interpret those metrics (also towards your questions).


Me too. From the 9 nodes still in the IRC channels, currently only mine appears to be on the newer version.

Good idea, done.

If the older version overwrites the newer, REORGANIZE messages with high disconnected blocks should appear in your debug.log. Another indicator is that you lose mined coins. If the newer version overwrites the older, then everything stays 'normal'.
Each time someone from the old version updates and joins the new version, he or she resynchronizes the two block chains. If the older has been faster, the newer is overwritten (from the split/fork point). -> At most the mining efforts starting from the update are lost.
Currently, the network hashing power of the newer version is rather large (about 6 MHashes/sec), we are at block height 100 941.

--
now is a good time to update (see https://bitcointalk.org/index.php?topic=182430.msg2102353#msg2102353).

The several thousand *incompatible* peer addresses causes sever problems to connect to legitimate network nodes, ultimately causing network fragmentation. I thought of several, but the fastest/simplest and imo most appropriate and even most interesting solution for this (spare time) research coin is the one I carried out.

I'd somewhat understand that reaction if you attached any monetary value to SMC. I thought I made that point clear, but speaking of retards: SMC is research and its only value is its blockchain, freely available to any participant. If you want to learn how those coins and tools around them work, you can play around with SMC (I already expressed interest in trying out any reasonable modification suggestions) or use your own fork (full source control) or do the real thing with established coins (invest hashing power, but have little/no influence on the coin itself).

Nevertheless, thanks for the hashing power - bye!

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.

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.

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

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.

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

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.

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.

Considering that in the last couple of days there has been a max. total of ~15 active clients, 60 connections are unlikely. Sure it has been SMC and not some other coin?

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.

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

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

Well - I am still playing around with difficulty and tx fees. I also left the max block size unchanged for now as I don't see any benefit to reduce it. Currently, the coin would support approx. 160tps i.e., 4 times higher than Bitcoin which is still small compared to real world microtransaction rates.

Nevertheless, I updated the code base w.r.t:
- max. coins corrected to 42 007 680
- added a option to dump block chain statistics
- added a few checkpoints for current block chain + reenabled code that does the checkpoint checking
- new icons (finally distinguishable from Litecoin)

The update is not mandatory but improves security.

I'd like to comment on the experiment part and the purpose of SmallChange: The coin is research only, I explicitly (from the start) expressed that and included some red text in the first post of this thread. It's going to stay 'research only' unless someone announces it as a real currency (and then its up to the people using it or not). In case I am the one to announce*), there is going to be a fresh start; I certainly will not do this in the next couple of months (years?) because I am very new 'to the scene' and still like to play around + 'get a feeling' for this first. I want to add novelty and solve *real* problems instead of just pseudo-managing another rebranded altcoin.
I plan to update the codebase a few times a month and welcome any helpful/useful contribution (which will be duly credited of course; ah yes, and it must survive my(/the community's?) criticism).
Other than that: I wanted to devalue some of the "weaker" coin spinoffs by showing that really any (idiot? ) can release a cryptocurrency nowadays. Also a few people expressed that the coin has been/is helpful to let them setup/try out services (e.g., mining pools) and get started with the inner details of cryptocurrencies.
So from my part: please expect something slow boiling, maybe useful but probably not. If you have extra resources or have fun experimenting with an alive block chain where you might end up credited as a hashing power contributor or even author: please join - otherwise wait until this is over or becomes something good.

btw: the hash rate is currently ridiculously high. Please mine LTCs or something else .. a few KHashes/s are currently (where we are still very close to the original Litecoin code base) really enough...


*) what others do with the codebase or blockchain is already out of my hands -- never has been in my hands

5 years later... wtf, where are the remaining ~378 000 000?!

Thanks, binaryFate.. a slight but embarrassing mistake!