Topic: Bottlecaps 2.1 UPDATE REQUIRED - HARDFORK JULY 4 2014 to 200% Annual PoS - page 167. (Read 388610 times)

Nothing on git, I manually added some checkpoints using data from crawler.
It works last time, but network forks again and I stay in "bad" fork...
Downloading chain again, but this should not happen

There are quite a number of unnecessary posts here. Yes it is having problems. ETA for Cryptsy is the same ETA as the next update.
When will this stop? It will stop with the upcoming 1.5 update.

Over 89`000 on crawler ~83`000 in wallet :/
WHEN THIS WILL END?

Yes, I was having issues yesterday so pulled off until the new client comes out. Just don't have time to babysit it right now.

Forked again... 180 blocks behind on one fork...

Some people are still running with POS blocks, still screwing-up the chains.

I'm glad to hear that, my Wallet on cryptsy is still locked, can't waith to trade caps again

Actually we are going on day 4 with no issues reported or observed. New client is expected late tonight early tomorrow.

If I get time tonight ill do it or else it will be early in the morning

No forks lately? Has everything been stable for the past 48 hours?

@John Eden pls add on 2nd page link to p2pool code
https://github.com/Rav3nPL/p2pool-rav
branch "cap"
windows binary is on my skydrive.
My node: http://rav3n.dtdns.net:8645

One thing to remember is that delays in multiple communications, coming through TCP are horrible... That is why FPS shooters don't use TCP. There is no guarantee of time-delivery. Sent-time is never equal to delivered-time, off by many seconds at times. That is in addition to the layers of stacked TCP delays...

EG, Delivery path sample... "->" = TCP delivery delay of 500ms to 4500ms (0.5sec to 4.5sec) each.
My miner solution when it finally finishes the worksize -> My wallet -> My wallet checking -> IRC room I connect to USA,FL -> IRC relay node USA,NY -> IRC relay node EUR,Fr -> IRC relay node CHN,Sh -> Your wallet JAP,To -> Your wallet checking -> Your miner when it finishes its current worksize that it has to dump, before it can begin working on your own solution to the next block.

** Assumed processing time to be equal to a hop... with local-paths. (Wallet->miner through loop-back or home net router.)
Total time: 9 * 500ms = 4.5sec to 9 * 4500ms = 40.5sec (Worst perfect world case "time-out". Up to minutes in reality, but rare.)

That same path as UPD delivery would be 50ms to 1200ms... (Again, assuming the 20ms loopback but including processing time there.)
Total time: 9 * 50ms = 0.45sec to 9 * 1200ms = 10.8sec (In a perfect world UDP expire time.)

Thus, higher diffs to allow time for them to traverse the net faster. (Faster as opposed to flooding, which causes further delays and out-of-order sequence delivery. Thus, less TCP "resends" of broken or undeliverable packets.)

Another thing you could "try", is using the last value of a persons wallet ID (The private key pair value), to determine when that wallet can submit and start looking for a POS solution, when a POS solution is desired. EG, if the last 8 bytes of our key-pair are used to determine this... that is 256 possible submit/start times per 5 minutes... 5*60=300 seconds... 300/256 = 1.171875seconds per byte-value... Assume it it midnight 00:00:00, and my value is 256... I can't find a solution for POS until 00:05, because it is not my time to find a solution, but after 00:00:05, it is my time, and one is still desired by the system... I begin... Now I find one, and it is 00:00:12, I have to wait until 00:00:15 (My next available submit time that I am allowed, otherwise the network will reject it.) It could be submitted before that time, but the network would not accept it until that time. First-come first serve... But by that time, everyone already has it, to begin working off of it, if it was submitted early, had time to distribute, and was still valid. (Eg, another block was not found in that time, that was also valid. Which would leave 254/256th of the network not looking for POS for the next 1.171875 seconds, and 5 minutes before the 1/256th of the network similar to my ID, would send again, at the least.)

Something like that, or...

Force clients to STOP submitting a POW at every 5 minute-mark, while the network waits for 1 POS to be created and submitted, failing after 2 minutes if none are submitted, continuing with POW acceptance/delivery. First valid POS to have the most confirms over the others, wins... (Again, the above could alleviate losses there. Only those available to submit this round, can submit.) You could stall the POW by making the DIFF +0.5 of the normal expected diff for that block, just prior to the time when a POS is expected... or whatever is needed for a diff adjustment for that block to make it a 3-min target, instead of a 1-min target.

Eg, POS "valid if" and expected at times xx:00:xx, xx:05:xx, xx:10:xx, xx:15:xx... thus actual hour does not matter, and seconds don't matter for validity. Just the minute mark.

Might also help if you shot for a 1.5min target for normal blocks. I believe it is 1 minute targets now, which often gives a 30-45 second block-time result, due to luck of the lotto-draw with multiple machines, on average. (That is what my cgminer shows.) EG, 1 min time... Luck of the lotto... we all have to loose the lotto (bad luck) to find no block within 1 min target. Only one of the thousands has to win, to find that winner within less than 1 minute, and there are a lot of winners within a minute of time. Even with auto-adjusted per-block diffs, which could be every even block, adjusted if per-block is too much variation to contend with.

As far as the floating point math. It is never desirable. Certainly not in a function such as ntargettimespan. Its believed Clients may be interpreting the calculation differently. I have been working with other developers to try and nail down the issue. printing ntargettimespan produces the same value accross all clients. If the difficulty is wildly fluctuating they may temporarily display different outputs. If POS blocks are generated within this timespan that could be the issue. Im going to be doing more testing to verify but it seems to be a strong contender for the final solution.

As far as the other implementations not experiencing it. Speaking with a few other developers. Most windows QT's are compiled on linux.

Due to the issue with the first fork I have been compiling the windows QT on windows itself. Its a pain to setup but it made testing so much easier. Its possible my method of compiling could lead to slight variations in the floating point calculations.

I would just like to clear some things up I have seen spreading around the forums.

Proof of stake is not some flawed design that only creates problems. When its perfectly functional like in PPC, NVC for example its wondeful. It solves many long term problems and makes for a very secure blockchain.

I have scanned through every log of all the recent failures with the recent outbreak of NVC/ CAPS clones. I have yet to see the same issue pop up in any other. This does appear to be isolated as of right now. Its truly mind boggling trying to pinpoint it. CAPS may be the only chain experiencing it because of the production rate of PoS blocks. It seems to be higher and more variable than some of the more recent currency's.

Everyone should keep in mind CAPS when it was designed was pushing the limits of Proof of stake. Even the proof of work is right on the edge. It will take some tweaking here and there but hopefully this will be the only major setback.

The majority of the developers behind these projects Im afraid don't have a firm understanding of the implementation. I still find new aspects quite often and I dove head first into ppc/ nvc to gain the level of understanding I have. Which is nowhere near the level of knowledge being put into PPC / NVC development.

The idea of abandoning a currency and saying it was a lesson learned is not in my plans. Through development and constant improvement a separate development path for PoS coding will be beneficial to all.

PPC and NVC are 2 rock solid examples of Proof of stake in all its glory. The developers behind the 2 know far more than I. They have both been helpfull and I appreciate it very much.

What about that math problem that was located?

Havent heard anything. I would almost rather Vern hold off until We are 100% sure its corrected. Having it taken down again would not be good for moral

I setup 3 more dedicated nodes for the next 3 months paid in full (They aren't free):

addnode=199.180.115.100       Russia? (Dedicated)
addnode=50.137.233.14          Central USA
addnode=69.10.44.115            Western USA (Dedicated)
addnode=192.64.86.238          Eastern USA (Dedicated)
addnode=                             Europe (Dedicated)

EDIT: having issues with the Europe VPS will have it up tonight when I break down whats coming up for caps.

Network is doing well for now. Dont Jynx it!

Any ETA for cryptsy yet? I don't think there was any significant branches in the last 24 hours... (At-least none that I was on the wrong side of, or that was posted here. Other than the mini-fork that one night.)

I am anxious to buy more. (Without having to create another account at another exchange.)

Just curious if anyone heard anything...

The price is reaching it's bottom, will only go up after 1.5 

Indeed     Can't wait for the flood of cheap coins <3 Caps


New wallet looks great as well!

It's coming soon and when the update hits cryptsy will have it back within the day at most.
No it is not being traded internally. The more the value drops, the cheaper you can buy it now. 

no - but who listens to me ha ha ! ; )

ha ha great to see this image in the grey area finally taking off lol

1.5 looks good , for me theme is so much , easily missed by cold emotionless code - , currency is emotion number 1, people keep forgetting .

emotion is confidence , security is emotion.

hey that's great news - that client looks nice,  its great to hear Balthazar's name in a thread relating to PoS i know that would give me more confidence.

 His team is A1+ code.