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

[RichG]

_igor wanted me to post these things:

Instead of compiling the whole thing, I just changed 4 bytes of the message start in the Balthazar's EXE file and it works.
https://docs.google.com/file/d/0B5vmhBdqYSg_ZTlONzdfYWZCcTA/edit?usp=sharing

Enjoy!

Please repost in the bitcointalk thread, I can't write there yet.

P.S. Just for fun: SMC: SB3nDmZ6ZLGErQzNaBMk11fsX9YUN6FzGm

and

Try it and give a feedback.
0% fee

http://smcp2p.mooo.com:9028

Donations:
BTC: 18PxUmhZqBhWgtM3iETS8NDdPBKs46DRdi
LTC: LfFwq1i5cBmpN3LR6Poabd9jUiXi6UGLck
SMC: SB3nDmZ6ZLGErQzNaBMk11fsX9YUN6FzGm

P.S. please repost on bitcointalk. can't post there yet.

These are from the forum I mentioned above.

[lightenup]

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.

Also did you change the max blocksize at all, and if so, what is one of the major things you have noticed?

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 .

[binaryFate]

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.

Also did you change the max blocksize at all, and if so, what is one of the major things you have noticed?

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 .

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?

[Balthazar]

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.

[Balthazar]

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

[Balthazar]

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

[muddafudda]

I thought this was the dragoncoin thread. My Mistake.

[Badman0316]

sounds good

[lightenup]

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?

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

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.

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.

[ronaldinho_07]

wow,so when will you officially release this coin 

[tim13n]

Do you need a cool logo?

[RichG]

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)

[RichG]

New forum:

www.smcforum.tk

Old site downed by spambots and bad databases.

[kaputt]

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

172.13.117.105:9030

[Balthazar]

Up

[binaryFate]

Is this coin still alive?

[Balthazar]

I have the same question.

[RichG]

It has been dead since June.

[kaputt]

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.

[binaryFate]

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