Network Health, Delegates Statistics and Block Tools

[bytemaster]

Use the btsx://bitmeat/transfer url to request support and also include the robo hash. 

[vikram]

Minor: it's "reliability" not "realiability"

[bitmeat]

Thank you, bytemaster!

I compiled 0.4.7. from scratch, which seems to be really stable so far. Site has rebuilt the data from scratch and is up and running again!

[bytemaster]

Hmm I did a fresh checkout of 0.4.5 and seems I'm stuck on block 284575.

Any ideas? This is on Ubuntu 14

Yes.. this is a known issue.   Try this work around.  Clear chain folder and connect via chain server:

 https://github.com/BitShares/bitshares_toolkit/wiki/Using-Chain-Servers

We are preparing a fix for the next iteration.

[bitmeat]

Hmm I did a fresh checkout of 0.4.5 and seems I'm stuck on block 284575.

Any ideas? This is on Ubuntu 14

[bitmeat]

Recompiling and will update shortly. In a perfect world hard forks won't happen, but they still do, so... it is what it is.

Thank you all for alerting me!

[GaltReport]

Yeah, something's not right about it.  Probably just needs to be updated somehow.

[vikram]

The website seems to be on a minority fork.

[bitmeat]

That's a great idea and, you will soon see a "delegate profile page". Where can look at historical voting / reliability charts.

[king]

Please forgive my poor English! ! !
About Delegates statistics, I think it is very good!
But I think the general BTSX users will not be too concerned about how many blocks delegate production, are more concerned about the reliability of the most recent Delegate, therefore, on this basis can provide delegate details:


Green triangle in the figure can be dragged to learn recently that the Delegate's reliability as whether to vote or concern basis.

Figure information just to show, of course, if you like,
 you can vote for my delegates "mister" or "delegate.mister",
 thanks!

[bitmeat]

Added you to rank list. Thank you!

[liondani]

 

[GaltReport]

I didn't know that.  That's cold man.

Think about it... let's say the slate for block production is as follows:

D1, D2, D3, D4, D5. Let's say D1 is a good honest guy and D2-D5 are playing dirty.

D1 produces a block, but as soon as he does, D2 builds a longer chain based on last block before D1 and marks it as missed. Then D3 confirms it, and so does D4 and D5. Now they have the longest chain of decent looking blocks. While good guy D1 has bad rep.

That's a shame but I guess I shouldn't be surprised.  Too bad there's no way to fix that.

[BTSdac]

 

[bitmeat]

Directing a portion of my delegate pay to happypatty for the effort put forth on delegate statistics.

Thank you.

Appreciate the recognition of my efforts! Anything donated to bitmeat will help keep the monitoring service up & running, as it is not cheap.

Include a topic ID from this forum, and the senders name will automatically be highlited and listed in the donations section with a link to the topic on this forum. Amounts will not be shown, however they will be sorted in a descending order in the donations section.

e.g. if you include 6142 in the memo it would link to this thread. (Look in the URL web address in your browser you will see topic=6142)

100BTSX will be the minimum that will be processed using this system. If you want to be removed send again with "remove" in the memo, simple as that.

(this is work in progress, wanted to get some early feedback)

[Fox]

Directing a portion of my delegate pay to happypatty for the effort put forth on delegate statistics.

Thank you.

[bitmeat]

I didn't know that.  That's cold man.

Think about it... let's say the slate for block production is as follows:

D1, D2, D3, D4, D5. Let's say D1 is a good honest guy and D2-D5 are playing dirty.

D1 produces a block, but as soon as he does, D2 builds a longer chain based on last block before D1 and marks it as missed. Then D3 confirms it, and so does D4 and D5. Now they have the longest chain of decent looking blocks. While good guy D1 has bad rep.

[GaltReport]

I think the latency metric is very important (only valid if your data collection node stays online the whole time).   A good node will have a median latency of 0.   

Right now I just connect to the client via JSONRPC. Any pointers as to where/how I could get that data from so I can include in analysis? Or do I need to plug into the toolkit source code directly?

Another metric is "who came before and after me" when I missed a block.  Sometimes it is the node that comes after you that "skips" your block and makes it look like you missed it.   Because of the shuffle it would appear as if everyone is "randomly" missing a block when in reality it is everyone who goes before Attacker always misses a block.

Funny you should mention that, I was just about to start doing an analysis of missed blocks before each delegate! Since as we all know a bad delegate could simulate missed block for someone else, so that they get kicked out. It gets worse - if you have a few delegates, you could target one specific delegate you want out, and collaborate to create bad rep for the good guy. It will be interesting how it unfolds, as the competition heats up. This is why I thought limiting to 100 delegates is tough because it will produce fierce competition and some bad behavior will ultimately come out of it. That said - it's also a good thing because we will analyze and find ways to strengthen the network. This is uncharted territory.

I didn't know that.  That's cold man.

[ripplexiaoshan]

Fantastic work! If you can add more information to the delegates, like pay rate, it will be better.

[8bit]

Happypatty, are you using RPC to pull data from the blockchain? Could I look at your code? I'm having trouble connecting.

See here: https://bitsharestalk.org/index.php?topic=6270.0

[bitmeat]

I think the latency metric is very important (only valid if your data collection node stays online the whole time).   A good node will have a median latency of 0.   

Right now I just connect to the client via JSONRPC. Any pointers as to where/how I could get that data from so I can include in analysis? Or do I need to plug into the toolkit source code directly?

Another metric is "who came before and after me" when I missed a block.  Sometimes it is the node that comes after you that "skips" your block and makes it look like you missed it.   Because of the shuffle it would appear as if everyone is "randomly" missing a block when in reality it is everyone who goes before Attacker always misses a block.

Funny you should mention that, I was just about to start doing an analysis of missed blocks before each delegate! Since as we all know a bad delegate could simulate missed block for someone else, so that they get kicked out. It gets worse - if you have a few delegates, you could target one specific delegate you want out, and collaborate to create bad rep for the good guy. It will be interesting how it unfolds, as the competition heats up. This is why I thought limiting to 100 delegates is tough because it will produce fierce competition and some bad behavior will ultimately come out of it. That said - it's also a good thing because we will analyze and find ways to strengthen the network. This is uncharted territory.

[bytemaster]

I think the latency metric is very important (only valid if your data collection node stays online the whole time).   A good node will have a median latency of 0.   

Another metric is "who came before and after me" when I missed a block.  Sometimes it is the node that comes after you that "skips" your block and makes it look like you missed it.   Because of the shuffle it would appear as if everyone is "randomly" missing a block when in reality it is everyone who goes before Attacker always misses a block.

[bytemaster]

The primary thing causing forks right now:

1) Network propagation delay (sometimes caused by CPU load)
2) Nodes with their timestamp set to the future (or past)
3) Delegates with their key loaded and active in two different nodes.

I think we need to rename them from "forks" to "orphans" if they are only one block long.  A fork would be a case where a subset of delegates disagreed with main fork for some reason un-releated to timing.

[bitmeat]

happypatty, please be sure to let us know if there are any stats you think we should be tracking directly in the blockchain database that would be useful. For example: https://github.com/BitShares/bitshares_toolkit/issues/580

Yes, I would like to understand more about the forks command. The output of that seems to be huge. I want to track how forks are formed, identify what causes them, so that if there are bad delegates causing the forks they are out.

One thing that would be nice, is to get the vote selection for candidates as of specific block in the past.

[vikram]

happypatty, please be sure to let us know if there are any stats you think we should be tracking directly in the blockchain database that would be useful. For example: https://github.com/BitShares/bitshares_toolkit/issues/580

[xeroc]

[bytemaster]

Sending you 8 PTS from the community fund in recognition of your amazing efforts Happypatty

https://bitsharestalk.org/index.php?topic=4909.new

  This is very exciting    I am very happy with the reliability of the network compared to the test network.

[CLains]

Sending you 8 PTS from the community fund in recognition of your amazing efforts Happypatty

https://bitsharestalk.org/index.php?topic=4909.new

[CalabiYau]

well done, kudos to happypatty 

[cass]

great work

[Riverhead]

Nice one!
What about a site where you can see the realtime graphs?

Here you go: http://x.bitmeat.com/

Mmmm....meaty.  I like that there are 22 delegates with 100% over the last 10k blocks.  Would it be possible to add rank in there too?  So people could make an observation like, "Wow, delegate.smith has 100% reliability over the last 50k blocks but is in 101st place.  They need my support!"

[bitmeat]

Nice one!
What about a site where you can see the realtime graphs?

Here you go: http://x.bitmeat.com/

[bitmeat]

If you need beta testers let me know.  I have both Windows and Ubuntu environments.

Thank you! It will be put live on a website shortly. Just working out some kinks with the configuration.

[Riverhead]

If you need beta testers let me know.  I have both Windows and Ubuntu environments.

[bitmeat]

Another preview, this time a bit more readable:



I think so far we are doing OK, but alerts would probably be very useful.

[Riverhead]

Right now the data I'm collecting has already been collected by the client. You all have it, it's just not visualized very well. It can easily be verified by looking at the block chain.

However once I release this, I plan to start gathering more interesting stats, like current forks, who are the delegates that produced the most forks, etc. <-- this stuff is very important, since you could have good guys be bashed by bad guys, if they fake missed blocks. We will see how it plays out, and also what the community needs most.

You certainly have my votes.  We need more people like you.

[bitmeat]

Right now the data I'm collecting has already been collected by the client. You all have it, it's just not visualized very well. It can easily be verified by looking at the block chain.

However once I release this, I plan to start gathering more interesting stats, like current forks, who are the delegates that produced the most forks, etc. <-- this stuff is very important, since you could have good guys be bashed by bad guys, if they fake missed blocks. We will see how it plays out, and also what the community needs most.

[Fox]

I'm doing this entirely as a hobby and a pet project at the moment.

Completely respect this statement. 

Are you willing to share you data dictionary describing the information you are currently collecting? 

Respectfully,
Fox

[luckybit]

We definitely need this.

[bitmeat]

Very much looking forward to your progress.  How may interested parties connect with your efforts?  Are you providing your code for peer review at this time?  Are you willing to share a small subset of your collected data  (perhaps a few rounds)? 

Thanks,
Fox

I plan to make it possible for people to make an API call and use the data however they wish. I'm doing this entirely as a hobby and a pet project at the moment.

[Fox]

I'll do much more over the weekend.

Very much looking forward to your progress.  How may interested parties connect with your efforts?  Are you providing your code for peer review at this time?  Are you willing to share a small subset of your collected data  (perhaps a few rounds)? 

Thanks,
Fox

[ripplexiaoshan]

Looking forward to seeing the real time graph

[bitmeat]

Few notes:

I did 100 because it is good for calculating percentage. The math will need to be fixed as well, because it is based on last 100 produced blocks. But each produced block could have many missed delegates until it's produced.

So if in the last 100 produced blocks we had 20 missed blocks I show 80. However that's 20 out of 120 expected blocks missing.

I'll do much more over the weekend.

By the way the most consecutive misses were 5, which overall is not that bad.

Cheers!

[Riverhead]

Very nice!!

Also - Isn't it the percentage of produced blocks rather than missed?  Otherwise we're in REALLY bad shape .

[CLains]

 

[bytemaster]

100 is close enough because it is all random anyway.


Sent from my iPhone using Tapatalk

[Fox]

Here to whet your appetite are just some network health stats:

This data visualization is much needed.  Thank you.

Change request: I believe the rounds are 101 blocks each (rather than 100). 

[puppies]

I'm glad you're happy now rather than krabby.  I look forward to your public release.

[bitmeat]

Nice one!
What about a site where you can see the realtime graphs?

All of that is coming. Like I said I already have real time data aggregation, just working on the various views. Once happy, I'll put it up live.

[emski]

Nice one!
What about a site where you can see the realtime graphs?

[bitmeat]

So, I decided to engage this community a bit more seriously. I started last night and imported all the data. (It is continuosly being imported)

Now I'm starting to build some very rough visual tools around the data, to help us understand what goes on, let us monitor the network and delegates health and hopefully help select decent delegates. Sometimes a delegate goes down and it could just be a network issue, the delegate owner probably prefers to be voted down for the time being instead of gathering bad stats.

And it's now Live, go at it:

http://x.bitmeat.com/

I plan to also add alerts, so delegates can get notified if there are issues. Please keep in mind I am only able to put in a few hours here and there. With community support I am hoping for a transition in this space full time.

Current preview: