fix(search): adds utils for hash test + fix search issue

[Alex-Werner]

Issue being fixed or implemented

Search being broken on address and transaction hash considered as block hash.

What was done

• Add HashValidators services (we can't required in Angular 1...), and validate first, then asks resources while we redirect.

Notes

[Alex-Werner]

Also fixes #36

[jsheng08]

This modification works for most of the cases.
Note: If the transaction starts with 0x0000. The regex will catch it as a block and you will not be able to search for the transaction.

[Alex-Werner]

Hey @jsheng08,
Thanks a lot for your review, indeed this makes it non-valid PR.
This is a bug as you noted, every 0.0015% of the tx hash will not be identified as a block instead.

There is two way I can solve this, either we reput the check as before, but only with the two conflicting elements (hashtx and blocktx).
But I wonder your opinions on this alternatives work :

In 2014, we expected 5 leading zeroes (0x00), so we could makes detection over (4) 0x00000000 as BlockHash.
On this premises that we lower the probability of having a tx matching this that is enough to provides the feature this way.
But the guy that got struck by lightning twice exists, in this case additionnaly, if expected block do not resolve as block, then try as transaction.
The case for blockhash to be <0x00000000 seems to not be existant due to computational power nowadays vs 2014 with limited hashing power (ref: https://bitinfocharts.com/comparison/dash-hashrate.html).
But we still cover the small edge cases.
Obviously, as if both blockhash and txhash do not resolve (which will happen more often than finding wrong tx), we would decide to say This Block is not existant instead of this Transaction.
Will look at doing this tonight.

Thanks again for the review, was really helpful !

[jsheng08]

Good Day @Alex-Werner ,

Take Block number 20,000 mined on Feb 2014 as an example, there are 10 leading zeros for the blockhash. And ever since then, the hash rate has been increasing.

We can implement something like #54 where if there are more than 10 leading zeros, it is a block. Otherwise, check for tx first and if it is not, then check that if it is a block. If it fails again, then we will assume that it is not found.

Hope that this helps you a little, Happy Halloween.

[nmarley]

if expected block do not resolve as block, then try as transaction

This makes sense to me, I agree more w/this approach. Still like the idea of being a "dumb client" and just passing to the API to resolve, but this should work too I guess, and probably less round-tripping.

[Alex-Werner]

The problem of passing it to backend is that for each input will ask for stupid query to the backend to some input (especially when searching anything that is not a valid input like random string).
I did wanted to deliberately reduce the cost here, knowing that right now each request got up to dashd. We do not have a local db for dashcore-node (on which case even if it would still be unnecessary call, i would be good with it).

I continue with the discuted agreed changes we had here (so basically up the leading zero for hash, add exception backfall for tx with leading zeroes).

[Alex-Werner]

Some updates here on some recent changes :

• We now use the network value set in dashcore-node.json and used by dashcore-node. We also set it in $rootScope.network to be used accross application (in same time we setup currency value).
• BlockHash.test() now can be passed a network parameters (default: 'testnet'). When done, validation differs, for a testnet, we validate using .startsWith('0x0000') - enough even for a micro aws - as for livenet it's .startsWith('0x0000000000') as we discussed.
• Search controller now test block hash using $rootScope.network as second parameters.
• Search controller will fallback on Transaction.get if the result of Block.get(q:hash) is not successful.

As per compatibility, everything defaults to 'testnet' so :

• if user entered invalid/unsupported network name ('devnet'), we treat it as testnet -> 0x000
• if user entered testnet but is on livenet -> 0x0000

P.S : mind a new npm run build to see the changes as public compiled are not pushed here.

Also founds out that insight-ui code expects method to fail on status being 4** (such as 404 no tx). But in reality it actually goes into the successCallback, where we have no such logic. I added a quickfix for our substring error, but this doesn't touch / fix really anything. Leading to a white page on some tx displayed (when tx do not exist). Creating an issue (#55)

[Alex-Werner]

Fixed test as much as I could, it seems there was an issue with xbvf as Trusty is not supported and xenial travis usage requires it to have as addons, which we have (see here : https://stackoverflow.com/a/55674747/2941361).

We seems to have another problem related with @dashevo/dp-services-ctl and it's image usage. Not sure I can do much about it right now.

[nmarley]

The dashevo/dp-services-ctl has circular dependencies w/other repos and I don't think it should affect this. Not sure if it should exist in that manner, but 🤷‍♂ .

[nmarley]

slightly tested ACK