Block stats: historical winning deadlines & times?
Is there a source of data for the winning deadlines and response times for each block? If not, is there a way to extract/derive this information from the burstcoin blockchain. Modifying the wallet software to start logging this information going forward would be one way to start collecting an analyzing, but it's definitely worth asking if this information already exists. This would be extremely helpful data to use to optimize pools and mining rigs, time versus capacity tradeoffs, solo versus pool mining, etc.
MineSomeBurst last edited by
There are a few API calls listed on Burst Explorer here: https://explore.burst.cryptoguru.org/api
I don't think it goes back very far if you're looking to grab a bunch of blocks.. but those are stored in your local wallet database anyway. You just need to query them. If you're using a local webserver like WAMP, you can configure phpMyAdmin to grab them.
If you're not already running something like WAMP, I'd be realllllly realllly careful if you're going to install it. It shouldn't conflict with the stand-alone MariaDB in your Qbundle folder, but please don't take my word for that. It would be painful to re-sync your wallet if something messed up.
A SQL statement to grab the last 360 blocks would be:
SELECT `height`, `block_timestamp` FROM transaction GROUP BY `height` ORDER BY `height` DESC LIMIT 360
You would then either copy & paste into a spreadsheet to calculate the timestamp differences between blocks, or write a little script if you have that knowhow. Timestamps are in seconds from the first block ever created.
If you're running a local wallet, there's also some API info here: http://localhost:8125/test (your wallet needs to be running to view this).
If you're interested, check out this article from a few days ago on block times: https://www.minesomeburst.com/valid-deadlines-last-360-blocks/
I was curious about the same thing.
Energy last edited by
@minesomeburst Thanks. This is very helpful, and I will explore the API option first. I'm not currently running MariaDB just to lighten my wallet footprint. The default H2 data store corrupts if you look at the wrong way, but I have a backup script that can restore quickly. Using a relational database for blockchain storage seems like extreme complexity/footprint overkill, so I've avoided it out of principle. LevelDB, LMDB, RocksDB seem like they would be much better choices with much lower chance of corruption.
I have about 120TB that I'm currently solo mining with. I've hit some single digit deadlines without winning a block and my total scan time is pretty good (less than a minute). I'm considering where to optimize next: faster scan times versus adding more capacity? The two pieces of data I mentioned would help with that decision. It would also help pool miners because the uncertainty around actual and effective capacity seems to be an ongoing point of confusion.
@zpoch Single digit DL's that don't win would be extremely surprising. What wallet (version and local/remote) are you mining against ?
@haitch I had been upgrading within a couple of days to the new Qbundle versions, but then found out there was a solo mining bug with v2.0.X. I recently reverted back to v1.9 which is the 1.3.6cg core wallet version. I'm going to run that right up to the hard fork I think.
@zpoch The 2.0.4 wallet works okay for solo with the addition of a couple of parameters to the brs.properties file - it's what I use. But reverting to 1.3.6cg until the fork also works.
@haitch That's helpful. I will definitely look into the parameters in 2.0.4+ nearer to the fork. Thanks again.