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

Where exactly?

New windows binaries are built successfully, publishing it now.

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.

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

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.

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

looking good:

old target rate algorithm (still active until block 15 000)
vs. the new one:

i'm really looking forward to it 

Awesome, thanks a lot 

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

I wll publish updated windows build today.

is there an updated windows GUI build out yet?

If not please could someone make it

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.

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

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

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!

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.

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

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.

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

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?

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

waiting for official publishing 

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.