Author

Topic: Block Explorers bugs ?! (Read 124 times)

legendary
Activity: 3472
Merit: 10611
February 05, 2021, 05:25:28 AM
#6
If it's "how many transactions involved coins being spent from or sent to a script that can only be spent by signing a transaction with privkeyX (and only privkeyX)"... then the logic holds. Again, as I said, it was huge oversimplification.
Then the search has to be based on the public key at least not an address. An address as I said is contractually a fixed script and nothing else.
BTW most users won't even realize it if you send them some coins using their public key and a different address type.

It's like if you google "cute puppies" but google shows you "bitcoin price" instead!
No... I think it would be more like if you searched "cute puppies"... and you got "cute puppies and kittens" Tongue
Cheesy
HCP
legendary
Activity: 2086
Merit: 4316
February 05, 2021, 05:15:37 AM
#5
I guess it depends on what you're actually trying to deduce... If it is how many transactions involve "OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG", then yes...

If it's "how many transactions involved coins being spent from or sent to a script that can only be spent by signing a transaction with privkeyX (and only privkeyX)"... then the logic holds. Again, as I said, it was huge oversimplification.



It's like if you google "cute puppies" but google shows you "bitcoin price" instead!
No... I think it would be more like if you searched "cute puppies"... and you got "cute puppies and kittens" Tongue
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
February 05, 2021, 03:29:10 AM
#4
If we say "1MbCDrD8fkqXr4M2HXYuyzLfYGEN4evUer" we don't mean "OP_0 " just as we don't mean OP_CHECKSIG.
So when this address is searched on a block explorer we are looking for any pubscript that exactly matches OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG. If anything else is returned then it is a bug in the explorer.

It's like if you google "cute puppies" but google shows you "bitcoin price" instead!

This could be solved by block explorers listing transactions that are custom scripts and ones for P2PKH/P2WPKH addresses separately. For auditing purposes, which is the subject of the article, they can list a total with the unspent amount from all of these.

Specifically, it can list balances received from each different script that can be made from P2SH-P2WSH (which is multisig IIRC) and P2SH[-P2WPKH] scripts separately from the regular public key hash scripts. And the correct PK hash script to use can be determined from the address prefix.
legendary
Activity: 3472
Merit: 10611
February 05, 2021, 01:34:02 AM
#3
Lastly, Block Explorers 5&6 are seeing the transactions for both the address and the public key... but only where the coins were sent to just that address or that public key (ie. not the "multisig" transactions.), so they arguably give the "most correct" answer.
That is actually the most wrong answer.
Even though addresses aren't part of the protocol but we have a global contract where we agree that a certain string with a certain encoding corresponds to one and only one script. If we say "1MbCDrD8fkqXr4M2HXYuyzLfYGEN4evUer" we don't mean "OP_0 " just as we don't mean OP_CHECKSIG.
So when this address is searched on a block explorer we are looking for any pubscript that exactly matches OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG. If anything else is returned then it is a bug in the explorer.

It's like if you google "cute puppies" but google shows you "bitcoin price" instead!
HCP
legendary
Activity: 2086
Merit: 4316
February 04, 2021, 06:26:03 PM
#2
Can someone tell me how these errors occur?
It's simply because of the way the block explorers are interpreting the transaction data... or improperly interpreting the data, as the case may be. Tongue

Block Explorers 1&2 are only looking for the address (ie. the hash of the public key)... so they only see 2 transactions for that address, 1 in, 1 out and attribute the address to have a balance of zero.

Block Explorers 3&4 are looking for any transaction that has the public key... unfortunately, the public key (0243c17584f2a00d7c22429e1444e2a94cae0a657b9a58ee6a87c33ef7bca97245) was used in a "spending script that required multiple sigs spend" (it's a precursor to the more common "multisig" that we have today)... so these explorers are seeing all these "extra" transactions where the public key was used as part of this type of multisig... but the address does not have exclusive control over those coins, so they shouldn't be showing as being part of the balance of that address.

Lastly, Block Explorers 5&6 are seeing the transactions for both the address and the public key... but only where the coins were sent to just that address or that public key (ie. not the "multisig" transactions.), so they arguably give the "most correct" answer.


In short, some old transactions that are now effectively "non-standard" today, confuse block explorers made to parse what are considered to be "standard" transactions. (NOTE: This is a huge oversimplification.)
legendary
Activity: 1582
Merit: 1284
February 04, 2021, 09:39:42 AM
#1
I read some topics and found a comment saying that Block explorers can contain errors in reading addresses.
This article talks about it https://catallaxy.rcgt.com/what-happens-when-block-explorers-disagree-a-pitfall-of-blockchain-auditing/. Can someone tell me how these errors occur?
The answer is in the article, but I did not understand it.

If you don't want to click on the link then why does this address )1MbCDrD8fkqXr4M2HXYuyzLfYGEN4evUer( give different results on multiple explorers?


Jump to: