lbryio / block-explorer Goto Github PK

It would be nice to be able to click on an item in the claims explorer and have it open up the content on LBRY.tv.

It shows 1 confirmation on block and transaction pages.

The repo "lbry-decode" aka "Python claims decoder" listed under prerequisites in README.md no longer exists

Add an endpoint + add info to stats page

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

On a block page, it would be helpful to know how many claims/channels are inside each transaction: https://lbry.com/news/dev-oct19

Since Block Explorer leverages Chainquery to get it's results, the queries sent to Chainquery must be NFD normalized for accurate comparisons. We need to implement NFD Normalization to normalize the query paramters sent to Chainquery. There will be a new column normalized_name that should be used for normalized comparisons for claim names.

This page should show this as a claim: https://explorer.lbry.com/tx/3fd8e167bd828ff5abf226550c8b5cab27acf1a0759778280085c9baf2ba482a

Not sure if it's an explorer bug or chainquery.... @tiger5226 can you take a peek?

From main explorer.lbry.com page: actual link: lbry://%40Kingbooger94/kingbooger94-fortnite-livestream-2

Displays as this on hover:

Should be the same as the link on https://explorer.lbry.io/claims/2e3bef9e80585613ddd95d30c1993f2d4ceae683 , or we should use open.lbry.com links.

This query takes a few seconds to run - maybe we can cache the results daily?

https://explorer.lbry.io/api/v1/supply

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

The development of this block explorer is quite firm, we have a stable old-fashioned explorer.
The current project is in php and uses the cakephp framework, particularly indicated for small projects see a comparison

Actual de facto standard for medium-large web apps for the backend is laravel, which also provides integration with main frontend frameworks, including vuejs. Is also good to have websocket instead of ajax for runtime update without page refresh.

I believe that the block explorer is a fundamental service for a cryptocurrency, I think we should have a new explorer: mobile first, super detailed (able to provide statistics even to the most hungry nerd), which exposes api to allow third-party software development, able to offer new services.

Below a list of juicy things to have in a new explorer:

• More stats about blockchain and its network, lbry upper layer network:
  • chain size / block size / txs in blocks
  • chain difficulty / hashrate
  • top supported content / tip-support stats
  • claims stats
  • blockchain network visualization on map
  • lbry-sdk network visualization on map
  • mining stat / pool hashrate / mining profit
  • lcb price / comparison with other stats
  • {suggest more}
• More services:
  • Email/telegram alert when blockchain see an input (output) tx to (from) an address in a "watch list" customized by the user [auth zone]
  • broadcast signed tx, useful for users who use a cold wallet (offline) to store lbc
  • address alias, in order to allow identification of pool addresses, explorer addresses etc.. [can be both general alias and user customized alias: auth zone]
  • {suggest more}

I created a repo in which I am developing a new explorer based on laravel, I'm still porting the functionality of the current explorer, but the classic "blockchain" part is ready.
I would like some feedback on what I have already developed, if you like it, if something could be better, if I have to continue or abandon the development, if there is a possibility that the project will be included under github lbryio organization.
Repo link: LBRYEXPLORER
Actually hosted here: lbryexplorer.tech

see #23 (comment)

Not sure where exactly, but would be good to link claim information to a transaction:

https://explorer.lbry.io/tx/c8f97c7d6a1f312563d0b624053fb71f5b54cabb6cd3b5865b0e1de74c3d3c4c#output-0

should show: https://explorer.lbry.io/claims/6a0fcce2b1a8103b6eb80c45440f95866113fc63

or

should show: https://explorer.lbry.io/claims/21a1dc5fc37e06bf6e551ce52de38f27c0e2cc11
https://explorer.lbry.io/tx/2438dea1ae1622084aa64efe9fa110ee7136e16d551e74a93baa9fca3445fd2a#output-0

The recent claims list shows things which are still pending and the link takes you to a "there's nothing at this location" message. Consider turning off links for mempool content and perhaps colour coding them so it's clear that they aren't mined yet.

https://d33v4339jhl8k0.cloudfront.net/inline/67942/1635135e12b6508f62cc212081c85985106dc9f1/ea07d100168142940e22d680676649f198bbcfbe/xc_9.png

We show author on claim pages, but this field is not used by the app anymore as it's been replaced by channel. We should remove or replace it with the channel (but the channel is already shown in "published by"

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

I've noticed this on a couple addresses, but here is one example: https://explorer.lbry.io/address/bRgPS3mfWTGhK6qsoeGjnCAfwakQvmpWpt

You can see that the # of confirmations are not consistent. You had mentioned this could be an issue with the SQL query as the blocks themselves have the right # confirmations.

Similar to the rich list, have a page which shows claims/channels that have top LBC bid amounts.

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

Sent you this one a while ago: https://explorer.lbry.io/address/bXikZS1g1jvjV1vSB83nPkaEXGZTKoms4f

Looks like it should only have 1 input from: https://explorer.lbry.io/tx/8694118779e15f97bbc79803a67e1f67528f1f6d0aaa5172bb473774aaa72328?address=bXikZS1g1jvjV1vSB83nPkaEXGZTKoms4f#bXikZS1g1jvjV1vSB83nPkaEXGZTKoms4f because the other one links to this tx: https://explorer.lbry.io/tx/0cb62edff9a3ec4478f0a8b8b57b227142cee626c559f5352a54fb333fec17ca?address=bXikZS1g1jvjV1vSB83nPkaEXGZTKoms4f#bXikZS1g1jvjV1vSB83nPkaEXGZTKoms4f which shows 0 coming from that address.

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

Support for new file/video metadata:
https://github.com/lbryio/types/blob/a6f2fd6d5f382f0012383b9076d650c1f6791ada/v2/proto/claim.proto#L29

includes:
file hash/name/size
video height/width/duration
release time (need to discuss how this will affect default sorting + sorting options)
NSFW/Mature field is changing to a tag

Here's an example image posted by spee.ch:
https://explorer.lbry.com/claims/94377e61712adf54ee2b78122d552682ac7d843f

It's not controlling the vanity name, because I just outbid it with a text file. The link on explorer should go to the image, not my text file. However, it goes to my text file.

It would be more useful if it said $0.0132 or $0.00745 for example, rather than saying $0.01. Would look super bad if it went to $0.0049...

"d33b00cb796d3fd510470a2dff741a5534c457d6e9468fc57dd122cbaeb2351c",
"02c8ede0b6c950a2067ab31fbfe162bf9614712fe673bd15ad4e55bbe54afbbb",
"98e93843c1d442e276761b387c260d0e620011b823f32b65eb28073c7a1fccf7",
"b8d2725b2f8e65de95a78114e6ac1dc728208a5989d1e5d65761197798bc2ca2"

vs

When typing 6a0fcce2b1a8103b6eb80c45440f95866113fc63 in the search, it returns you at the home page.

Would expect this result:
https://explorer.lbry.io/claims/6a0fcce2b1a8103b6eb80c45440f95866113fc63

https://explorer.lbry.io/address/bU2XUzckfpdEuQNemKvhPT1gexQ3GG3SC2

This balance should be 245K as of 10/20/2018. This is the LBRY hot wallet, ask Grin/Tom/Josh for balance if needed.

Internal Use

Acceptance Criteria

1. run the script to update balances

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

I think I found a bug while creating the chain query app. The address for p2pk vouts were different for lbrycrd vs blockexplorer.

https://github.com/lbryio/block-explorer/blob/master/src/Shell/BlockShell.php#L1855

We are using an associative array and we are assigning index 1 for the public key. It should be index 0 for the data to hash ( the public key ). This is why all p2pk outputs appear to be using the same address in blockexplorer.

https://explorer.lbry.io/address/bEBcZxhMCjLrgadsX5YupCmcu6D8iWRjpk

It is hashing the OP_CHECKSIG string. So it always gets the same hash hence always the same address.

Also there needs to be a check if the public key is compressed or not. The public key consists of an X and Y value. The compressed key consist of just the X. There are 3 options for the first byte of a public key compressed or not. 2,3, or 4. 2 and 3 are used for compressed public keys.

y2 = x^3+ ax^2 + b
so we need to perform square root to recover y from x. And it turns out that
sqrt(a) = a^(q+1)/4

Now you just have to pick either the positive or negative solution. If the y that you calculated is even, and the first byte of the key is even, then use this value, otherwise, use the negative value which is q-y.

https://bitcointalk.org/index.php?topic=162805

To validate you use the following

http://gobittest.appspot.com/Address

It automatically checks for compression.

Similar to our other apps, the explorer should also abide by the block list. It should not be possible to see blocked claim metadata. This should be done at both the claim and channel level.

Feature request/idea: Assign names to various known LBC addresses, similar to many explorers where large wallets are labelled, example: binance_hot_wallet, bitfinex_1, or eth_dev wallet so it can be publicly identified. Possibly also as a way to combat fraud and scammers, to label their addresses as possibly malicious accounts.

https://explorer.lbry.io/address/bHW58d37s1hBjj3wPBkn5zpCX3F8ZW3uWf - should say 0.

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

I merged lbryio/lbry.tech#254 and this encouraged me to test if the old URL formats properly redirected. They did not appear to, but they should.

https://explorer.lbry.io/address/bYAgA5W1bCTuLU1cVbCz7F3HTADqr49aGS

This is one of the most commonly reused addresses on the LBRY blockchain. I think this is happening because of performance reasons. There are just so many TransactionAddresses for this address.

Include the sdhash, claim bid, effective amount,

If there's an easy way to filter them out, it's probably good to do this, so people don't try to open abandoned things in LBRY.

... An overview of pools and a precise graph showing the distribution of mining power.
Among other things... Will write more here, later! Going to bed now.

Created time is when we find out about the transaction. Usually this is from when we read it from the mempool. However, with a full resync of chainquery this would be much sooner. In these cases the block explorer should show block time for both fields. If the gap is more than 1 hour a part make them both the blocktime value.

This would make it clear that those are ours rather than a whale's.

Feature request: Add the price of LBC in BTC (SATS) or ETH (Gwei) to the front page of https://explorer.lbry.io/ beside the price in $.

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

Per @akinwale - The #2 issue should be code cleanup, because I used some dirty shortcuts in some places. - look, you even got #2! lol

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

On the homepage, there are links served from insecure domains. This makes the padlock in Firefox's URL bar gray with a caution sign.

Here's a function I made for .tech:

function makeImageSourceSecure(url) {
  const originalUrl = new URL(url);

  if (originalUrl.protocol !== "https")
    return `https://${originalUrl.host}${originalUrl.pathname}`;

  return originalUrl.href;
}

Need a CI/CD solution for block-explorer. Currently, need to deploy changes manually.

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

https://explorer.lbry.io/tx/ffc95e511018815157c2a63c1818e16e9c61d8fe5a4fe7545264126e57dc7a39

Shows: https://explorer.lbry.io/claims/145ca931f4478344b2c1f6cd9a8359c00fe90430

Correct claim: ef3dbbed10ec1b72e38f7c712a4242c9995ff9d8

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

The numerical value shown for prices on explorer claims to be in LBC but it's actually in deweys.

Example: https://explorer.lbry.com/claims/7566d7bf31db2bec324d9d5ee0432418fd852a1c
which is actually priced at 199 LBC.

Add details to transaction pages which includes transaction size, script sig details and any data points we have. This should be in an "advanced" (show/hide) view, especially for scritpsig

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

Update README.md with local installation instructions and restoring data from backups.

https://explorer.lbry.io/claims/6bbd31d0e1bcbcf7735ff7b35bcca322a24ec64b

When clicking open in LBRY, the app fails to open the file because of a % in the URL.

https://open.lbry.io/@unclejed613/lbry2 works but https://open.lbry.io/%40unclejed613%2Flbry2 does not.

Feature Idea/suggestion: Add various notifications to users for incoming transactions

If users have a browser tab open on a certain LBC address, have the tab auto generate a notification sound similar to those found on insight block explorers.

Also give the users the ability to "watch" an address similar to etherscan where users can subscribe to transaction activity of certain address(es) via email or other forms, or possibly implement the functionality of users signing up with emails/passwords to contain their own LBC address(es), again similar to etherscan.

When I use the search function, I have various issues:

• Numeric searches seem to be assumed to be a block number search. If I search for a filename that is numeric, the result returned may be a block number or nothing at all (because the block numbers don't go that high?)
• If there are more than one entry for a filename, no results are returned. I should get multiple results to choose from.
• If no results are returned for whatever reason, it doesn't tell me there is an error or no results. It just displays the explorer home page.

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

Like BTC has for theirs at: https://blockchain.info/charts/blocks-size

we should have one at
https://explorer.lbry.io/charts/blocks-size

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

lbry.tv users will have a single wallet, and the address page doesn't show amounts correctly when sending change back to itself. The received amount should be adjusted for this as well.

See https://explorer.lbry.com/address/bNAcah588ZCZAmyq879HjCjaPtvqHupjmt

You'd expect to see the sent amounts instead of a negative number. And received should not double count change received.

https://lbryexplorer.tech doesn't show this correctly either.

When viewing the status page: https://explorer.lbry.com/api/v1/status the hashrate is showing as N/A. This is affecting things like the wunderbot's hash command LBRYFoundation/lbry-wunderbot#239

chainquery ought to make the explorer easier to work with/use and simpler to maintain (if doesn't do that, that is also useful feedback for chainquery).

Need to add endpoints for total supply and circulating supply. Total supply should be much easier - it's all unspent outputs which I believe is available via lbrycrd.

Circulating supply is a bit trickier. A good starting point is probably to exclude the 3 addresses from: https://lbry.io/faq/credit-policy
But this will need to be updated when we move funds around for security purposes (once a year?). Not sure if any other funds/addresses need to be excluded, will check.