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

I think this was a great experiment with lots of valuable data, and I've used it to learn a lot about high speed transaction verification.

I want to conduct my own experiment.

Could someone please show me what to change in the code to set a 1 second block solution time?

Thank you so very much in advance!

Whish it'd get more interest, I still have few smc somewhere 

For the most part, this coin is inactive, but it is still functional and has two full time nodes.

172.13.117.105:9030
122.99.120.206:60513

There are other nodes at times, but these are the only two that have been constant for over a month.

If you are looking for something to test on, this is a good one.

Difficulty is at 0.00024414 . I haven't seen it lower than that, no mater how slowly the blocks are found.

But yes, it had good activity and interest until around June.

It has been dead since June.

I have the same question.

Is this coin still alive?

Up

The usual node does not seem to be up. Please add:

172.13.117.105:9030

New forum:

www.smcforum.tk

Old site downed by spambots and bad databases.

We already have one. But, please do make us an alternate.

In fact, we have two:

-The one in smallchange-qt

-and the one on the forum (http://forum.smallchange.tk)

Do you need a cool logo?

wow,so when will you officially release this coin 

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.

sounds good

I thought this was the dragoncoin thread. My Mistake.

https://docs.google.com/file/d/0B4cZ4tPn0KAtS1d1NzRPQWVaTTA/edit?usp=sharing

I see that there are some protocol changes... So, I started rebuild from repository and will publish new win32 builds today.

Don't forget that high blocksize provides an additional latency. If you are maintaining a fast blockchain (like SMC), you should minimize blockchain syncronization latency. Latency could cause chain forks, which will neutralize all benefits of fast chain, because REORGANIZE will be called too frequently. That's why blocksize limit should be adjusted.

Thanks a lot for the feedback
In your opinion, the oscillations are due to a too small hashing network (thus varying a lot when people join or quit it), or are inherent to such a very short block confirmation target, or something else?

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://bitcointalksearch.org/topic/m.2040013
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 .