Author Topic: Block Explorer and Delegates Listing  (Read 51267 times)

0 Members and 1 Guest are viewing this topic.

Offline svk

hi svk

first - good work!

at the moment i can not go from X to DNS. is it not possible to integrate something to switch different blockscans from the "main" side www.bitsharesblocks.com? i think it would be much better for the new chains coming.

thanks. that is indeed on my list of things todo, just haven't gotten there yet! easy transitions between chains will come soonish :)
Worker: dev.bitsharesblocks

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
hi svk

first - good work!

at the moment i can not go from X to DNS. is it not possible to integrate something to switch different blockscans from the "main" side www.bitsharesblocks.com? i think it would be much better for the new chains coming.

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
That could be an option yes, although I would have to poll your node every 10 secs to update the blocks. If that's ok with you then I guess it could work.

This shouldn't be a problem. Send me a PM if you decide to implement this. I'll setup a node for you.

Offline svk

That could be an option yes, although I would have to poll your node every 10 secs to update the blocks. If that's ok with you then I guess it could work.
Worker: dev.bitsharesblocks

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
There are still delegates with not properly synchronized timer.
This usually hurts other delegates (missing blocks) and the stats are not properly showing who is responsible for that.

As a result I have the following feature requests:
On delegate pages:
Latency last X blocks
Reliability last X blocks
Perhaps all stats for last X blocks ?

Yea I know the latency stats would be useful and it's already implemented but hidden at the moment. I'm just not sure how reliable my latency measurements are, since some of the values are surprisingly high. You can still see them on the individual delegate pages though (for last 50,100 and 200 blocks if available), the current top delegate bts.coin had an average latency of 7.7s over the last 50 blocks for example.

I could add reliability over the last 200 blocks produced as well.

Do you want to include data from another node ?
If you are only using RPC calls and you are willing to do it, I could grant you access to a node on my end. This way you will be able to check the latency on both sides and get better results.

Offline svk

There are still delegates with not properly synchronized timer.
This usually hurts other delegates (missing blocks) and the stats are not properly showing who is responsible for that.

As a result I have the following feature requests:
On delegate pages:
Latency last X blocks
Reliability last X blocks
Perhaps all stats for last X blocks ?

Yea I know the latency stats would be useful and it's already implemented but hidden at the moment. I'm just not sure how reliable my latency measurements are, since some of the values are surprisingly high. You can still see them on the individual delegate pages though (for last 50,100 and 200 blocks if available), the current top delegate bts.coin had an average latency of 7.7s over the last 50 blocks for example.

I could add reliability over the last 200 blocks produced as well.

Worker: dev.bitsharesblocks

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
There are still delegates with not properly synchronized timer.
This usually hurts other delegates (missing blocks) and the stats are not properly showing who is responsible for that.

As a result I have the following feature requests:
On delegate pages:
Latency last X blocks
Reliability last X blocks
Perhaps all stats for last X blocks ?

Offline svk

interestingly one can add a cleartext message to burns .. thats nice :)
Yea, there's another one by the account "dump" with the message "like that dump" :)

Worker: dev.bitsharesblocks

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
interestingly one can add a cleartext message to burns .. thats nice :)

Offline svk

I recently discovered that when the collateral mechanics were changed for shorting, a new transaction type was added called "short_op_v2_type". I added this to my code, but it made me wonder what other transactions I might be missing. So I made a little script to determine what transaction types had actually been used so far, here's the list if anyone's interested:

Code: [Select]
    "types" : [
        "register_account_op_type",
        "withdraw_op_type",
        "create_asset_op_type",
        "define_delegate_slate_op_type",
        "deposit_op_type",
        "withdraw_pay_op_type",
        "update_account_op_type",
        "issue_asset_op_type",
        "ask_op_type",
        "bid_op_type",
        "short_op_type",
        "update_feed_op_type",
        "cover_op_type",
        "short_op_v2_type",
        "burn_op_type",
        "add_collateral_op_type"
    ]

I was actually missing a couple, notably burn_op_type and asset creation/issuance. I've now added these to the code and reindexed the transactions. I found an interesting thing too: the transactions BM used to correct the BTSX supply! I know some people were asking for the exact amounts etc, if you're interested it was these two transactions:

http://bitsharesblocks.com/blocks/block?id=555282
http://bitsharesblocks.com/blocks/block?id=555294

The total amount burned: 187,250+100=187,350 BTSX
Worker: dev.bitsharesblocks

Offline svk

Hey svk, can you provide a json api?
Hey, the server is already pretty strained so it depends what you're looking for..
Worker: dev.bitsharesblocks

clout

  • Guest
Hey svk, can you provide a json api?

Offline svk

I've reworked the transactions database and everything to do with votes and ranks for the DNS site, and am currently migrating it to the BTSX server. This means I need to re-index all the transactions, and although it's faster than before it'll still take a little while. Sorry for the disturbance.

The good news is this should make those things much less taxing on the server in the future :)
Worker: dev.bitsharesblocks

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Ahh ... that should be possible .. though is some work I guess ;)

Offline bitcoinerS

  • Hero Member
  • *****
  • Posts: 592
    • View Profile
there are no downvotes, only net votes, the negative ones you're seeing are simply votes for someone being removed cause they were unapproved.

My understanding is a delegate can lose votes in two cases:
1. Due to shares voting for that delegate being transferred to a different account with different voting preferences or to a market order.
2. Due to account owner un-approving that delegate.

First is unintentional and second is intentional. Distinguishing between them would be useful.
>>> approve bitcoiners