Network seems to be stuck at block 46575

Arcurus · 31 December 2015 16:31

My Sakia client displayed now since hours that he is on block 46574.

two clients have 46575
the others have 46574 or lower

What is happening?

All the good,
Arcurus

Arcurus · 31 December 2015 18:26

now urodelus is at block 46578

threee cliets are at 46577

two are at 46575

my node is still at 46572

why are the blocks distributing so slow through the network?

and showuldnt there be round about 6 blocks per hour?

cgeek · 31 December 2015 18:33

We just unstucked it.

0.12.x is not very good at knowing the network, 0.13 will make nodes actively check the network on a regular basis.

Arcurus · 31 December 2015 19:53

great!

another thing: just saw that the universal dividend from 30.12 is 4.21
and from 29.12. 3.65

3.65 * 1.1 = 4.01… and not 4.21…

scith · 1 January 2016 13:33

I still seem to be stuck at 46572 in Sakia.
In my ucoin node, I see:

TypeError: Cannot read property ‘number’ of null
at /root/.ucoin/app/lib/dal/fileDALs/BlockDAL.js:178:47
at GeneratorFunctionPrototype.next (native)
at onFulfilled (/root/.ucoin/node_modules/co/index.js:65:19)
at runMicrotasksCallback (node.js:337:7)
at process._tickCallback (node.js:355:11)
e[32m[2016-01-01 14:27:15.858] [INFO] ucoin_default - e[39mMesured max speed is ~108 tests/s. Proof will try with ~22 tests/s.
e[36m[2016-01-01 14:27:16.865] [DEBUG] ucoin_default - e[39mProof-of-work computation canceled.
e[33m[2016-01-01 14:27:16.940] [WARN] ucoin_default - e[39mundefined
e[33m[2016-01-01 14:27:16.941] [WARN] ucoin_default - e[39mundefined
e[33m[2016-01-01 14:27:16.941] [WARN] ucoin_default - e[39mundefined
e[32m[2016-01-01 14:27:16.965] [INFO] ucoin_default - e[39mTransaction added to block
e[32m[2016-01-01 14:27:17.012] [INFO] ucoin_default - e[39mGenerating proof-of-work of block #46573 with 4 leading zeros… (CPU usage set to 20%)
e[32m[2016-01-01 14:27:18.688] [INFO] ucoin_default - e[39mMesured max speed is ~168 tests/s. Proof will try with ~34 tests/s.
e[32m[2016-01-01 14:27:34.545] [INFO] [default] - e[39me[90m168.253.158.26 - GET /blockchain/current HTTP/1.1 200 1184 - 7 mse[0m
e[32m[2016-01-01 14:27:34.548] [INFO] [default] - e[39me[90m168.253.158.26 - GET /node/summary HTTP/1.1 200 98 - 1 mse[0m
e[32m[2016-01-01 14:27:34.556] [INFO] [default] - e[39me[90m168.253.158.26 - GET /network/peering HTTP/1.1 200 658 - 1 mse[0m
e[32m[2016-01-01 14:27:34.564] [INFO] [default] - e[39me[90m168.253.158.26 - GET /network/peering/peers?leaves=true HTTP/1.1 200 undefined - 4 mse[0m
e[32m[2016-01-01 14:27:34.577] [INFO] [default] - e[39me[90m168.253.158.26 - GET /wot/lookup/2qwGeLWoPG7db72bKXPfJpAtj67FYDnPaJn2JB7tyXxJ HTTP/1.1 200 2921 - 26 mse[0m
e[32m[2016-01-01 14:27:35.608] [INFO] [default] - e[39me[90m168.253.158.26 - GET /network/peering/peers?leaf=74A351A0850D0E3F0B172CA2D93F3A2AFBAF80A1 HTTP/1.1 200 undefined - 4 mse[0m
e[32m[2016-01-01 14:27:36.282] [INFO] [default] - e[39me[90m168.253.158.26 - GET /network/peering/peers?leaf=2089AB644919590024CA9C2E3733CFB88F5CAD4F HTTP/1.1 200 undefined - 3 mse[0m
e[32m[2016-01-01 14:27:36.961] [INFO] [default] - e[39me[90m168.253.158.26 - GET /network/peering/peers?leaf=7DC120C56617F903B2B6495B64C18BA0BA957992 HTTP/1.1 200 undefined - 4 mse[0m
e[32m[2016-01-01 14:27:37.635] [INFO] [default] - e[39me[90m168.253.158.26 - GET /network/peering/peers?leaf=AB305A8CADD3913851E5B822CACB631DA311A602 HTTP/1.1 200 undefined - 2 mse[0m
e[32m[2016-01-01 14:27:38.314] [INFO] [default] - e[39me[90m168.253.158.26 - GET /network/peering/peers?leaf=636F35842EB41F14F7F4CF4DC3A171C6F020BEA2 HTTP/1.1 200 undefined - 2 mse[0m
e[32m[2016-01-01 14:27:38.993] [INFO] [default] - e[39me[90m168.253.158.26 - GET /network/peering/peers?leaf=C8F4FE01E028B3CFD38E0CBE30DA42E8453F176F HTTP/1.1 200 undefined - 3 mse[0m
e[32m[2016-01-01 14:28:13.482] [INFO] [default] - e[39me[90m109.193.240.232 - GET /blockchain/current HTTP/1.1 200 1184 - 2 mse[0m
e[32m[2016-01-01 14:28:13.488] [INFO] [default] - e[39me[90m109.193.240.232 - GET /network/peering/peers?leaves=true HTTP/1.1 200 undefined - 2 mse[0m
e[32m[2016-01-01 14:29:07.599] [INFO] [default] - e[39me[90m95.157.211.148 - GET /blockchain/current HTTP/1.1 200 1184 - 1 mse[0m
e[32m[2016-01-01 14:29:07.613] [INFO] [default] - e[39me[90m95.157.211.148 - GET /network/peering/peers?leaves=true HTTP/1.1 200 undefined - 1 mse[0m
e[32m[2016-01-01 14:29:07.621] [INFO] [default] - e[39me[90m95.157.211.148 - GET /network/peering HTTP/1.1 200 658 - 1 mse[0m
e[32m[2016-01-01 14:29:07.647] [INFO] [default] - e[39me[90m95.157.211.148 - GET /wot/lookup/2qwGeLWoPG7db72bKXPfJpAtj67FYDnPaJn2JB7tyXxJ HTTP/1.1 200 2921 - 18 mse[0m
e[32m[2016-01-01 14:29:07.648] [INFO] [default] - e[39me[90m95.157.211.148 - GET /node/summary HTTP/1.1 200 98 - 1 mse[0m
e[32m[2016-01-01 14:29:07.874] [INFO] [default] - e[39me[90m95.157.211.148 - GET /blockchain/block/46573 HTTP/1.1 404 15 - 4 mse[0m
e[32m[2016-01-01 14:30:13.590] [INFO] [default] - e[39me[90m109.193.240.232 - GET /blockchain/current HTTP/1.1 200 1184 - 15 mse[0m
e[32m[2016-01-01 14:30:13.594] [INFO] [default] - e[39me[90m109.193.240.232 - GET /network/peering/peers?leaves=true HTTP/1.1 200 undefined - 2 mse[0m
e[32m[2016-01-01 14:30:42.772] [INFO] [default] - e[39me[90m95.157.211.148 - GET /blockchain/block/46602 HTTP/1.1 404 15 - 5 mse[0m
e[32m[2016-01-01 14:30:42.881] [INFO] [default] - e[39me[90m95.157.211.148 - GET /blockchain/current HTTP/1.1 200 1184 - 2 mse[0m
e[32m[2016-01-01 14:30:43.004] [INFO] [default] - e[39me[90m95.157.211.148 - GET /blockchain/block/46601 HTTP/1.1 404 15 - 7 mse[0m
e[32m[2016-01-01 14:30:43.845] [INFO] [default] - e[39me[90m83.99.17.58 - GET /blockchain/current HTTP/1.1 200 1184 - 2 mse[0m
e[32m[2016-01-01 14:30:43.852] [INFO] [default] - e[39me[90m83.99.17.58 - GET /network/peering HTTP/1.1 200 658 - 1 mse[0m
e[32m[2016-01-01 14:30:43.857] [INFO] [default] - e[39me[90m83.99.17.58 - GET /node/summary HTTP/1.1 200 98 - 0 mse[0m
e[32m[2016-01-01 14:30:43.858] [INFO] [default] - e[39me[90m83.99.17.58 - GET /network/peering/peers?leaves=true HTTP/1.1 200 undefined - 11 mse[0m
e[32m[2016-01-01 14:30:43.878] [INFO] [default] - e[39me[90m83.99.17.58 - GET /wot/lookup/2qwGeLWoPG7db72bKXPfJpAtj67FYDnPaJn2JB7tyXxJ HTTP/1.1 200 2921 - 25 mse[0m
e[32m[2016-01-01 14:31:04.493] [INFO] [default] - e[39me[90m168.253.158.26 - GET /network/peering/peers?leaves=true HTTP/1.1 200 undefined - 2 mse[0m
e[32m[2016-01-01 14:31:04.496] [INFO] [default] - e[39me[90m168.253.158.26 - GET /blockchain/current HTTP/1.1 200 1184 - 4 mse[0m
e[32m[2016-01-01 14:31:04.857] [INFO] [default] - e[39me[90m88.164.245.189 - GET /network/peering/peers?leaves=true HTTP/1.1 200 undefined - 1 mse[0m
e[32m[2016-01-01 14:31:04.873] [INFO] [default] - e[39me[90m88.164.245.189 - GET /blockchain/current HTTP/1.1 200 1184 - 1 mse[0m
e[32m[2016-01-01 14:31:07.578] [INFO] [default] - e[39me[90m95.157.211.148 - GET /blockchain/current HTTP/1.1 200 1184 - 2 mse[0m
e[32m[2016-01-01 14:31:07.586] [INFO] [default] - e[39me[90m95.157.211.148 - GET /network/peering/peers?leaves=true HTTP/1.1 200 undefined - 1 mse[0m

Arcurus · 1 January 2016 13:39

and what does this mean?

Moul · 1 January 2016 14:56

@scith,
I think you should reset data && sync

urodelus · 1 January 2016 14:59

Like said Moul, try ucoind stop, ucoind reset data, ucoind sync metab.ucoin.io 9201, ucoind start !

scith · 1 January 2016 16:59

Thanks, it works again with these commands

Arcurus · 1 January 2016 17:24

thx, done

seems to work, at least partially. my node manged to generate a block which was displayed in Skaia. But still sakia does not display my node

now my node is visible again

cgeek · 1 January 2016 23:28

That’s normal. The exact UD formula is:

UD(t+1) = CEIL(MAX(UD(t) ; c * M(t) / N(t+1) ))

So two rules here:

the next UD is at least equal to previous UD (this is the MAX clause)
the UD computed from c * M(t) / N(t+1) is a UD growing at a rate higher than c if N(t+1) is lower than N(t)

Indeed, with N(t+1) < N(t) makes M(t) / N(+1) relatively higher to M(t-1) / N(t), since the total monetary mass is now shared by less people. So the resulting UD(t+1) has a higher c (c_actual) than UD(t).

From this formula, you can deduce that c_actual >= c, always. In metab_brouzouf, you can observe this in the following graphs: http://www.metab.ucoin.io/#/graphs

Arcurus · 1 January 2016 23:44

nice graphs
year I see now that the UD depends very much on the member count…If new members join the money is less ¨inflated¨.
if members drop the money is more inflated…
Have you thought about making the UD independent of the member count like:

UD(t+1) = c * UD(t)

this would give a more predictable increase of money supply per member per year.

the old formula is also little bit counter intuitive.
if more members drop out you would expect to have less needed money supply and not more.
and the other way round if more members join you would to expect have more need money supply and not less (but of course with the min UD here it is not that tragic like the other way round)

cgeek · 2 January 2016 00:28

Yes you could use such kind of formula, however this does may lead to high asymmetry for some users as N drops out or take off.

The current formula is one of those @Galuel proposed on its Wiki, I’ve chosen this one so we avoid the asymmetry of a big increase of N.

Also, the formula isn’t that hard once you dig in it

Arcurus · 2 January 2016 01:02

I understand the formula, just though about the usability.

If the increase of UD is fixed per time, then people could count on that.
The asymmetry relative to the total Money supply per member would adjust very quickly with the default 10% increase of UD per year.

Further as outlined above it looks contra productive if the money is inflated even more if users drop out.

What do you think?

Galuel · 2 January 2016 11:00

You can study the demonstration in the RMT chapter dedicated to that point.

No this is false. According to RMT demonstrations it is not the same to share 100 units of money between 100 people, than sharing 100 units of money between 100000 people.

[quote=“Arcurus, post:14, topic:628”]
The asymmetry relative to the total Money supply per member would adjust very quickly with the default 10% increase of UD per year.[/quote]

“quickly” is not defined, and this assertion is false. You could make a study for that for example with numerical examples if you cannot follow the mathematical demonstrations.

Let’s suppose the following case for which you will make a numerical simulation, make Libre Office Calc Graphs (or similar), and publish the results in your own blog :

100 people in which 50 reached the M/N average money. And then 100 people more joining the money. Following two different formulas for UD, calculate and show the speed with which 40 years later, and what their account will change in time (graph) for the middle case of equilibrated exchanges (what you spend is equal to what you earn, so you only count the UD as a change in the accounts).

Compare the results for any people, people in the 100 initial members, and people in the 100 new members. Take into account the fact that some of the 100 initial members will be die in 40 years, and some of the 100 members will be die also but less people (they are younger since they come after).

This is false too for the same reasons.

[quote=“Arcurus, post:14, topic:628”]
What do you think?[/quote]

I think you probably didn’t study the RMT fundamental principle of the time symetry.

Because thinking only about “the money” is not thinking about freedom of the men who use, and will use when the first ones die, that money.

In RMT development, men are the fundamental principle, not the economical values that are relative, neither the money itself that is relative too.

It is so not a question of “what do you think”, it’s a question of mathematical demonstration in space-time.

Arcurus · 2 January 2016 15:28

Thx for your answer! I will read more into your outlined details.
Currently I do not fully agree with this statement:
¨such as the trivial but dangerous theoretical form¨
But you are right, good to plot that in graphs and so on, to see the implications more clearly
But for the moment to get started just some small calculation:

DU(t+dt)=(1+c) DU(t)
DU(t)=10
c=0.1
M=10000
N=90

that would simulate that 10% of the members left in this year

DU(t+1)=(1.1) 10 = 11
m/n = 111,1… --> UD(t+1) should be 11,11… --> 11,11 / 11 = 1.01 --> the ud with the current ucoin forumla would be one percent more, that looks quite good

M(t+1) = 10000 + 90 * 11 = 10990
M(t+1) / n *c=12,21…
DU(t+2) = 12,1 --> 12,21 / 12,1 =< 1,0091 --> the difference is now reduced with round about 9%, so in round about 11 years the UD would be round about the same like with the current formula.

Only if more then 10% member leave in one year the two formula would become significant more different…

Galuel · 4 January 2016 06:15

“just small calculation” is a good start but far from being enough to understand it deeply.

For instance, if you look some triangles and only look to rectangle ones, then you will conclude “so with small calculations I conclude that many times c²=a²+b² with those triangles”

You need to simulate different N(t) models, with individuals I1,I2,I3,…,In, that go and come into your community, during a long period of times (40 years of living of each, at least 80 years for all), and compare if time symetry is respected for every model and any individuals.

And because the formula DU(t+dt)=(1+c) DU(t) doesn’t care at all about N(t) you will, for sure, face some big problems.

Now let’s go to simulations and publication of results.