Author Topic: Network Health, Delegates Statistics and Block Tools  (Read 12524 times)

0 Members and 1 Guest are viewing this topic.

Offline Fox

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

Thank you.
Witness: fox

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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.

Offline 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?

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

Offline ripplexiaoshan

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 2300
    • View Profile
  • BitShares: jademont
Fantastic work! If you can add more information to the delegates, like pay rate, it will be better. +5% +5%
BTS committee member:jademont

Offline 8bit

  • Full Member
  • ***
  • Posts: 56
    • View Profile
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
« Last Edit: July 27, 2014, 09:03:14 pm by 8bit »
Code: [Select]
wallet_approve_delegate eightbitA VOTE FOR EIGHTBIT IS A VOTE FOR CRUDE DICK ART

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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?

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

Offline 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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline 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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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.

Offline 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

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc

Offline bytemaster

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

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

+1  This is very exciting :)   I am very happy with the reliability of the network compared to the test network.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline CLains

  • Hero Member
  • *****
  • Posts: 2606
    • View Profile
  • BitShares: clains
Sending you 8 PTS from the community fund in recognition of your amazing efforts Happypatty

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

Offline CalabiYau


Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█