hsjoberg / fork-explorer Goto Github PK

Wouldn't a Dockerfile be nice for building this project and running it within Docker?

I'm thinking of implementing this if there is interest.

(Problem in title)

https://taproot.watch/

DESCRIPTION

Add showDetails parameter to block URL.

https://mempool.space/block/681606?showDetails=true

CODE

FIX

<a href={`https://mempool.space/block/${height}?showDetails=true`} target="_blank">

It would be nice to see what percentage of blocks out of the last X blocks that signal readiness. This would be a very up to date "real time" signaling rate.

Right now you still need bitcoind and the RPC server even though it is configured with fake mode. This increases the barrier to be able to contribute to the project.

The reason for this is that getblockcount is still called, instead this should just be faked as well.

Why not reuse this nice explorer on a new website to trace all blocks maded by mining farm that use renewable energies?
And have a list of all green mining farm.. in order to force the old ones to switch on? And to help who want to join to a green pool?

https://twitter.com/Ziya_Sadr/status/1387159898794905607

On the Mining Pools overview page https://taproot.watch/miners please show at the top (or bottom) the total share of Taproot activated Mining pools.

Meaning: Currently there are 4 mining pools which have Taproot activated:

1. F2Pool
2. Poolin
3. Foundry USA
4. SlushPool
   Add those shares together and we'd get roughly 35.55% of Taproot activated Hashrate.

thx

Now sure how we should this one.

I rather not use WebSockets to keep the project simple.

Right now it's very difficult for contributors to change the "About Taproot" texts.
The reason for this is because of how generic this project is supposed to be (it's not only for this Taproot softfork but any further softforks as well), so there are no hardcoded info texts and the text is manually added to the production server.

The project is made in Deno, so it's not easy as it would be if using Node.

https://taproot.watch/stats is nice but we care about the 90%. How about adding the above chart?

Accumulated mining share of all miners above (when sorted after share) would make it easier to read which mining pool that would need to get onboard for Taproot to be activated.

Right now the design breaks when entering sub 400.

For example this is with 370:

Handling the 320 width standard seems like a stretch, but I think that 370 or 380 should be be able to work fine.

We've observed that a lot of pools have staged rollouts, where they seem to flip-flop back and forth between signaling and non-signaling blocks. Largely I think we should think of those as "eventually signaling" and it would be nice to sum up the percentages of pools that have a nonzero signaling block number in the current period and show that sum. So for example, right now the sum shows 60.47%, because BTC.com's latest block wasn't signaling, even though some of their blocks do signal. Same with Huobi Pool and 1THash, and probably others before the process is over. Those added up would add another 22.09% "eventual hashrate" to the total, taking us to 82.56%. Obviously the number should be qualified and explained, but it seems useful to report because it's likely that all these staged rollouts would be done within a couple of weeks.

I've been maintaining a fork of btccom/Blockchain-Known-Pools with the goal of better coverage and higher accuracy. This should help you detect e.g. blocks by WAYI.CN (bitcoin-data/mining-pools#31) which currently appear as "Unrecognized miners" on taproot.watch.

However, I'm not sure if you can 'retry' pool identification on your end.

Use different color for first block with soft fork signaling from pool, so we can easily see when pool mined first signaling block.

We will never serve content on HTTP, so to improve security it makes sense to enable HSTS.

Serving via HTTPS is currently out of scope of fork-explorer, so this has to be done on a reverse proxy (Nginx, Apache, Caddy, etc). taproot.watch uses Caddy, so I'll take a look there.

Can we change miners to mining pools?

This website is now used by lot of people and many newbies may assume there is no difference between miners and mining pools.

we could see if they are signaling intermittently or constantly. Not sure at all but it feels it goes on and off for some miners.

To prevent issues like #48, this project should considering using import maps: https://deno.land/manual/linking_to_external_code/import_maps

Not sure if we should do some funky calculations or if just assuming 10 min block interval is enough.

Some external tools are basing their data on the /blocks API call.
The application right now only saves the current difficulty period so we might want to provide a way to generate previous ones (perhaps even use it in this project (/?epoch=X)).

In preparation for colorblindness mode, styled-components theming support is needed.

When starting up bitcoind and fork-explorer at the same time, I've seen this error from bitcoind and fork-explorer exits:

fork-explorer_1     | Bootstrapping real block data...
fork-explorer_1     | Listening on: http://0.0.0.0:8080
fork-explorer_1     | error: Uncaught (in promise) Error: Verifying blocks...
fork-explorer_1     |     throw new Error(response.error.message);
fork-explorer_1     |           ^
fork-explorer_1     |     at getblockcount (file:///fork-explorer/backend/jsonrpc/index.ts:11:11)
fork-explorer_1     |     at async bootstrapBlocks (file:///fork-explorer/backend/blocks/index.ts:87:20)

This is only a temporary error, so I propose it should be retried until it's gone.

The green favicon could be interpreted as a summary of taproot.watch, which would make the user think Taproot will definitely be activated, because the icon is green. But that wouldn't be true, since the website says "Taproot cannot be locked in within this period", but the favicon is green. I propose the favicon have a question mark if it could still go either way.

https://taproot.watch/?miner=Unrecognized%20miners

getblockhash should probably be replaced by getblock.

Also AFAICT this will require call to getrawtransaction?
Not sure if our API call budget will handle this.

I think the signalling/ucoming/non-signalling percentages are calculated incorrectly.

This screenshot shows the page, as well as a calculator showing the expected values:

PS Love this project!

The config should set the fork key from getblockchaininfo and then the rest can automatically set up:

{
	"result": {
		"chain": "main",
		"blocks": 681524,
		"headers": 681524,
		"bestblockhash": "00000000000000000003f11f7ea1501c799a09530dd3c751665a5ac7818b8657",
		"difficulty": 20608845737768.16,
		"mediantime": 1619951663,
		"verificationprogress": 0.9999929291006103,
		"initialblockdownload": false,
		"chainwork": "00000000000000000000000000000000000000001cce4dd390f48bb3db350888",
		"size_on_disk": 388722795567,
		"pruned": false,
		"softforks": {
			"bip34": {
				"type": "buried",
				"active": true,
				"height": 227931
			},
			"bip66": {
				"type": "buried",
				"active": true,
				"height": 363725
			},
			"bip65": {
				"type": "buried",
				"active": true,
				"height": 388381
			},
			"csv": {
				"type": "buried",
				"active": true,
				"height": 419328
			},
			"segwit": {
				"type": "buried",
				"active": true,
				"height": 481824
			},
			"taproot": {
				"type": "bip9",
				"bip9": {
					"status": "started",
					"bit": 2,
					"start_time": 1619222400,
					"timeout": 1628640000,
					"since": 681408,
					"statistics": {
						"period": 2016,
						"threshold": 1815,
						"elapsed": 117,
						"count": 2,
						"possible": true
					},
					"min_activation_height": 709632
				},
				"active": false
			}
		},
		"warnings": ""
	},
	"error": null,
	"id": null
}

Currently the site says

xxx Taproot blocks left until softfork is locked in

which is a bit clumsy (also: what is a "Taproot block"??). How's about something like this instead

xxx additional signalling blocks are needed for the softfork to lock in

The application currently doesn't account for reorgs.

I'm passing in this config.ts snippet. These are the values for testnet.

  fork: {
    name: "Taproot",
    info: [],
    versionBit: 2,
    threshold: 1512,
  },

But on the rendered overview page, it shows 90% at several places. I'd expect something like 75%.

Very useful site, thanks for hosting it!! 🖤

The text view is especially sexy, but it is not aligned.
Are there symbols [signaling, not signaling, not yet mined] with the same width?

Would you welcome a PR with something which converts two columns on the Miners page "Signals" and "Blocks" to a single pie with the number of blocks for and against?

https://benpickles.github.io/peity/

If you're interested, I'll patch something up.

I cannot find the cum page.
I am pretty sure this is a mistake.
I don't know how to use Github.

I'm not sure what has been changed since I last successfully started fork-explorer, but right now I'm always getting this error when starting the server:

fork-explorer_1     | error: TS2345 [ERROR]: Argument of type 'Middleware<Record<string, any>, Context<Record<string, any>, Record<string, any>>>' is not assignable to parameter of type 'Middleware<Record<string, any>, Context<Record<string, any>>>'.
fork-explorer_1     |   Types of parameters 'context' and 'context' are incompatible.
fork-explorer_1     |     Type 'Context<Record<string, any>>' is not assignable to type 'Context<Record<string, any>, Record<string, any>>'.
fork-explorer_1     |       Types of property 'app' are incompatible.
fork-explorer_1     |         Type 'Application<State>' is not assignable to type 'Application<Record<string, any>>'.
fork-explorer_1     |           Property '#middleware' in type 'Application' refers to a different member that cannot be accessed from within type 'Application'.
fork-explorer_1     | app.use(router.routes());
fork-explorer_1     |         ~~~~~~~~~~~~~~~
fork-explorer_1     |     at file:///fork-explorer/index.ts:13:9

I noticed you pushed 8782314 which seems to be related, but rebasing my branch on current master didn't help.

Green block means that it signalled 'readiness' for Taproot activation, red block means that it did not. Transparent blocks are upcoming blocks within this period. <a href="https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/"> Signalling is NOT voting</a>

Lot of users consider miners signalling as voting which is not true I have shared a link of an answer by Pieter Wuille and there are lot of other posts by different Bitcoin devs to clarify the same thing. Hope you can add this and people do not consider it as voting.

In the screenshot at https://twitter.com/hampus_s/status/1389691680325001219 there is a green-background symbol which is very readable. Now I see a transparent gray one (gray on dark-gray).

I may be understanding this wrong, but the activation threshold for Taproot on mainnet is 1815 blocks, according to BIP341.