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

[Otaci]

ah yes a friendly reminder: That's a research coin. The changes to the litecoin codebase could have killed it from the start (as indicated in the second post of this thread).

Thank you for this, it's been fun setting this up, I've learnt quite a bit. I also intend to look at setting up a pool (I know there is one already but more than one should exist). For me it is a fun project, not a financial investment.

[1715202517]

1715202517

[1715202517]

1715202517

[lightenup]

ah yes a friendly reminder: That's a research coin. The changes to the litecoin codebase could have killed it from the start (as indicated in the second post of this thread).

Thank you for this, it's been fun setting this up, I've learnt quite a bit. I also intend to look at setting up a pool (I know there is one already but more than one should exist). For me it is a fun project, not a financial investment.

Okay - if it's not only fun for me then everything is fine

btw: please update as soon as possible, latest before block  15 000
Based on Balthazar's suggestion I've adjusted the difficulty retargeting algorithmus slightly to react a bit slower but be more robust with respect to sudden hashrate changes.
Now instead of 8 hours, the algorithm will look 1.5 days into the past to determine a new difficulty setting.

[ronaldinho_07]

waiting for official publishing 

[237]

So the rewards start after 3 days. Is that bound to a specific block or will it sart with a update?

[sdp]

I wanted to say to everyone that I have inspected the sources of smallcoin using kompare with the sources of litecoin.  I am a University graduate and a programmer (though no longer in that career at this time).  The changes were largely search and replace litecoin for smallcoin with care to preserve case the changes advertised from the author but there was something unexpected.  The functions for returning the estimated number of blocks were altered to only return 0.  Why this change?

[c4n10]

So the rewards start after 3 days. Is that bound to a specific block or will it sart with a update?

Rewards should start at block 17,280 (I think).

[lightenup]

So the rewards start after 3 days. Is that bound to a specific block or will it sart with a update?

Rewards should start at block 17,280 (I think).

Yes - that's correct. --> Might be a bit sooner than 3 days.

The functions for returning the estimated number of blocks were altered to only return 0.  Why this change?

You mean the code in src/checkpoints.cpp ? I couldn't enable checkpoint checking before there is something to check
Anyway: thanks for reviewing the code.

[Anon136]

the problem with really fast blocks is that one person with very high hashing power can potentially reliably out produce the legitimate network even if the total hashing power of the honest network greatly outweighs his own because he wouldnt have to deal with latency between nodes. This is why the block time needs to be at the very least set somewhere above the average time a block can be reliably propagated across the whole network in addition for a little bit of time for everyone to mine on it, or else confirmations give no security at all.

Now you have to consider that fast blocks can be much smaller than 1 mb bitcoin blocks and still hold much more in a given span of time so they could propagate faster than bitcoin blocks do so their is that. My guess is though that you are always going to have to wait atleast an amount of time that is at-least some what of a nuisance for face to face transactions and that is why gold and silver will always be best for day to day transactions. And when making a transaction over the internet, litecoins 2.5 minutes is a pretty good tradeoff imo.

[lightenup]

the problem with really fast blocks is that one person with very high hashing power can potentially reliably out produce the legitimate network even if the total hashing power of the honest network greatly outweighs his own because he wouldnt have to deal with latency between nodes.

Still new here, but why would the others have to deal with latencies between nodes? Even as a legitimate miner I'd mine as fast as I can. As soon as I have found a block, I blast it out to the others and start to work on something fresh. I wouldn't wait for any confirmations. If an incoming block interrupts me, I need to restart anyway.
So far, the one person with 'very high hashing power' has no advantage over the others (beside the very high hashing power).

This is why the block time needs to be at the very least set somewhere above the average time a block can be reliably propagated across the whole network in addition for a little bit of time for everyone to mine on it, or else confirmations give no security at all.

Under the assumption the network delay has more influence on the block generation rate of the legitimate network than on 'bad nodes', yes.

Now you have to consider that fast blocks can be much smaller than 1 mb bitcoin blocks and still hold much more in a given span of time so they could propagate faster than bitcoin blocks do so their is that. My guess is though that you are always going to have to wait atleast an amount of time that is at-least some what of a nuisance for face to face transactions and that is why gold and silver will always be best for day to day transactions. And when making a transaction over the internet, litecoins 2.5 minutes is a pretty good tradeoff imo.

I am not seeing this problem yet (coming from an entity that has higher than average hashing power but still has less than 50% (minus variance) of the total network hashing power).

But I admit that SmallChange surely has a long way to be considered practical in any way. If network delay is a problem with the 15s target block generation rate then it only adds to how to deal with very high transaction rates/bandwidth  (originating from the nature of microtransactions) and the required pruning... Also the difficulty adjustment algorithm probably requires a complete redesign... aw that's going to be great fun!

[lightenup]

And when making a transaction over the internet, litecoins 2.5 minutes is a pretty good tradeoff imo.

Imagine you want to get some snack from a vending machine at the airport ... and you need to wait 2.5 minutes... even 15 seconds is long!
I am not saying that this couldn't or even should be solved differently (e.g. by centralized systems/proxies where you transfer in advance an amount of your favorite currency to and vending machines can 'instantly' withdraw), but I wanted to explore the possibilities with a cryptocurrency based on Bitcoin. Might work, might fail horribly

/edit: it's a vending machine!

btw: we are at block 11087 --  in case you haven't yet: please update soon.

[Rubberduckie]

And when making a transaction over the internet, litecoins 2.5 minutes is a pretty good tradeoff imo.

Imagine you want to get some snack from a vending machine at the airport ... and you need to wait 2.5 minutes... even 15 seconds is long!
I am not saying that this couldn't or even should be solved differently (e.g. by centralized systems/proxies where you transfer in advance an amount of your favorite currency to and vending machines can 'instantly' withdraw), but I wanted to explore the possibilities with a cryptocurrency based on Bitcoin. Might work, might fail horribly

/edit: it's a vending machine!

btw: we are at block 11087 --  in case you haven't yet: please update soon.

is there an updated windows GUI build out yet?

If not please could someone make it

[Balthazar]

Hm... I made it yesterday, but forgot about publishing...

I wll publish updated windows build today.

[Rubberduckie]

Hm... I made it yesterday, but forgot about publishing...

I wll publish updated windows build today.

Awesome, thanks a lot 

[ronaldinho_07]

Hm... I made it yesterday, but forgot about publishing...

I wll publish updated windows build today.

i'm really looking forward to it 

[lightenup]

looking good:

old target rate algorithm (still active until block 15 000)

Code:

nActualTimespan = 44838  before bounds
GetNextWorkRequired RETARGET
nTargetTimespan = 30239    nActualTimespan = 44838
Before: 1e01a34b  000001a34b000000000000000000000000000000000000000000000000000000
After:  1e026db8  0000026db8e33dcae290693f7801041274a49c5918528f3129526eaedabddb23

vs. the new one:

Code:

nActualTimespan = 36350  before bounds
GetNextWorkRequired RETARGET
nTargetTimespan = 30239    nActualTimespan = 36350
Before: 1e01a34b  000001a34b000000000000000000000000000000000000000000000000000000
After:  1e01f807  000001f80723e76196177bfff754b7d861303aec2e6d4b6c2f82b471235cad13

[hashunter]

I'm using only unix systems (mac and linux)
Can someone compile for me? 

[Anon136]

the problem with really fast blocks is that one person with very high hashing power can potentially reliably out produce the legitimate network even if the total hashing power of the honest network greatly outweighs his own because he wouldnt have to deal with latency between nodes.

Still new here, but why would the others have to deal with latencies between nodes? Even as a legitimate miner I'd mine as fast as I can. As soon as I have found a block, I blast it out to the others and start to work on something fresh. I wouldn't wait for any confirmations. If an incoming block interrupts me, I need to restart anyway.
So far, the one person with 'very high hashing power' has no advantage over the others (beside the very high hashing power).

This is why the block time needs to be at the very least set somewhere above the average time a block can be reliably propagated across the whole network in addition for a little bit of time for everyone to mine on it, or else confirmations give no security at all.

Under the assumption the network delay has more influence on the block generation rate of the legitimate network than on 'bad nodes', yes.

Now you have to consider that fast blocks can be much smaller than 1 mb bitcoin blocks and still hold much more in a given span of time so they could propagate faster than bitcoin blocks do so their is that. My guess is though that you are always going to have to wait atleast an amount of time that is at-least some what of a nuisance for face to face transactions and that is why gold and silver will always be best for day to day transactions. And when making a transaction over the internet, litecoins 2.5 minutes is a pretty good tradeoff imo.

I am not seeing this problem yet (coming from an entity that has higher than average hashing power but still has less than 50% (minus variance) of the total network hashing power).

But I admit that SmallChange surely has a long way to be considered practical in any way. If network delay is a problem with the 15s target block generation rate then it only adds to how to deal with very high transaction rates/bandwidth  (originating from the nature of microtransactions) and the required pruning... Also the difficulty adjustment algorithm probably requires a complete redesign... aw that's going to be great fun!

well if we had an honest monopolist than 10 second blocks could work ok =P. 

But just imagine that we have one actor with 20% of the total network hashing power and the other 80% is broken up among 80 actors with 1% of the total network hashing power each. Imagine that we have 15 second blocks and it requires 30 seconds for a block to propagate across the network. So lets imagine that in one experiment 10 blocks in a row are found by the honest network each by a different actor with 1% total network hash rate. So each block was solved in 15 seconds like the protocol dictates but inorder for each new actor to build upon an existing block it had to be transmitted to him and if it requires 100 seconds to propagate across the entire network lets say hes somewhere in the middle at 30 seconds, the fastest the chain could be built is one block every 65 seonds, 15 to mine 30 to transmit. Now the dishonest actor can build his own chain with out worrying about transmission thus each hash produced by him is roughly (65/15) 4.333 times as effective as a block produced by an honest actor and if he owns 20-30% of the total hashing power than he will be more powerful than any individual honest actor.

Sorry its a bit harder to explain with words than it is to picture in my own head.

[Anon136]

And when making a transaction over the internet, litecoins 2.5 minutes is a pretty good tradeoff imo.

Imagine you want to get some snack from a vending machine at the airport ... and you need to wait 2.5 minutes... even 15 seconds is long!
I am not saying that this couldn't or even should be solved differently (e.g. by centralized systems/proxies where you transfer in advance an amount of your favorite currency to and vending machines can 'instantly' withdraw), but I wanted to explore the possibilities with a cryptocurrency based on Bitcoin. Might work, might fail horribly

/edit: it's a vending machine!

btw: we are at block 11087 --  in case you haven't yet: please update soon.

Bitcoin is secure enough at 0 zero confirmations for a vending machine purchase.

[Anon136]

You need to make it re-target every block. you can do this by adjusting based on an aggregation of data from blocks over a long period of time. Here is my 0.02btc on how i think retargeting should be handled for a fast coin (or any coin for that matter)

for example lets say the following sequence of numbers represents how quickly a block came in relative to how quickly it should have come in. So if the number is 1.4 and the block was supposed to come in at 15 seconds than the block actually came in in (15*1.4) 21 seconds.

block 1 = 1
block 2 = 1
block 3 = 1.5
block 4 = 1.7
block 5 = 1.4
block 6 = 1.8

ok so now lets say we are looking for the target dificulty of block 7 and the difficulty of the last block was set too 5000 (yes its a totally arbitrary number). Take each of the numbers on the right and multiply them times their block number than divide the total by in this case the 6th fibonacci number (since there are 6 items in the list). This will give more recient blocks more weight in deciding what the hash rate should be but still not enough weight for miners to see an advantage in arbatraging diferent chains and creating chain destroying ossilations by doing so.

((1*1)+(2*1)+(3*1.5)+(4*1.7)+(5*1.4)+(6*1.8 ))/(1+2+3+4+5+6)=1.5285

so in this example blocks are coming in to slowly, so we take 5000*1.5285 to give us a new difficulty of 7642.5

we then wait to see how long it takes for the next block to come in, and we devide the amount of time it took by the amount of time it should have taken and append that list now we have a 7th element

block 1 = 1
block 2 = 1
block 3 = 1.5
block 4 = 1.7
block 5 = 1.4
block 6 = 1.8
block 7 = (time the block in the previous example took/time it should have taken)

and just repeat the process above with the new data

The longer you set the sampling of blocks the less adaptive it will be but the more secure it will be from miners hopping back and forth on this chain and other chains and causing destructive reverberating oscillation. You would need to set the right balance. My guess is 1 years worth of samples would be about right.

I apologize if this made no sense, if it didn't than maybe ill see if i can code it in python to explain better.

[Balthazar]

New windows binaries are built successfully, publishing it now.