WEKU: Block number: 9585616
Monday 4 am france time
Monitoring 6 witness servers, all seems to be good, waiting for the RPC nodes to synchronize, go to bed...
Monday 9 AM France time
Prepare the boy, bring the car... 800 Km to Paris to drop him with his mom.
At the same time someone started a witness node running the old version of the code, this node took over a week work and brought back the infamous Integer overflow error.
Status:
Right now only 1 witness is running to restablish service with a patched version.
We are working in a reverse split to reduce the number of vests in the system, i am still tracking down why the number is so high.
And hunting for the reason the rewards pool seems abnormally low, i am running 6 witnesses 3 on the old HF20 and 3 with different versions of HF21 tracking down bugs and errors.
WEKU is back oncce again
A shame my three explanatory posts from last monday were lost.
Al final usaste el código que te pasé? porque cuando un hardfork es aplicado ya no es necesario preocuparse de que otro nodo corra la versión anterior... que veo que es el caso que comentas.
No, no se hizo el reverse split
Al final forzamos el SP de un initminer a 0 para salir del int overflow de total_vests
Estoy revisando porque el número es anormalmente alto
En la version anterior, el número de testigos necesarios para un hardfork está muy bajo porque hay pocos testigos y por eso entraron en competencia y al final ganó el otro y el int overflow volvio.
La solución no es elegante pero había que poner el sitio en línea y yo quiero encontrar la raíz del problema.
La cadena del ReV la tengo corriendo desde hace un par de meses y los vest no son tan altos y puedo hacer power up de todo en initfunds por ejemplo.
Pienso que hay algo en el código de esta comentado que está causando este problema.
En bearshares Bilal tienne los vests 1 a 1 con los Bears pegged y a él se le tranco la cadena también una vez y no supo repararla y creo que es por eso que los puso en paridad