Block Explorer and Delegates Listing

[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 :)

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

[emski]

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.

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

[emski]

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.

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

[emski]

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 ?

[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" :)

[xeroc]

interestingly one can add a cleartext message to burns .. thats nice :)

[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 Expand

    "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

[svk]

Hey svk, can you provide a json api?

Hey, the server is already pretty strained so it depends what you're looking for..

[clout]

Hey svk, can you provide a json api?

[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 :)

[xeroc]

Ahh ... that should be possible .. though is some work I guess ;)

[bitcoinerS]

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.