Pattern bitcoin hash160 problem

[directoryio]

why  1FeefsqjLUeoanRrFxRFVUaPdTKUD4Vvhz  =    a0b098dd7f36e3da2d692e97ecf6ca07dadf4501
and   1FeefigBjmAAMepTiT2uziK2YnSXKkreD    =     02c5406b2e2a1c5a1b6b3fff03937185d23ea339

? hash160 not same normaly

[1714046428]

1714046428

[pebwindkraft]

can you maybe outline a bit, what you expect to see, or what makes you so suspicious that you identified a hash160 problem?

[bob123]

why  1FeefsqjLUeoanRrFxRFVUaPdTKUD4Vvhz  =    a0b098dd7f36e3da2d692e97ecf6ca07dadf4501
and   1FeefigBjmAAMepTiT2uziK2YnSXKkreD    =     02c5406b2e2a1c5a1b6b3fff03937185d23ea339

? hash160 not same normaly

I guess you think that if the first part of the address starts with a specific string the hash is also starting with a specific string?
If so.. then your false. Change 1 bit and your hash is completely different. You have 2 different addresses and both have a completely different hash.
Everything is fine. You should read yourself into hash functions: https://en.wikipedia.org/wiki/Hash_function
This effect of small changes of the input leading to a completely different hash is desirable. Its called the avalanche effect (https://en.wikipedia.org/wiki/Avalanche_effect).

[ranochigo]

It is absolutely normal.

To generate a hash160, the corresponding public key is hashed using SHA256 before hashing it again with RIPEMD160. To generate the address, the following sequence is followed: (Version Byte)(Hash160)(Address checksum). Next, the string is encoded using Base58[1]. The hash160 is a component of the address before encoding and the address is not derived solely from the hash160.

Hence, the structure address is not dependent on the hash160 at all, as you've demonstrated.

[1] https://en.wikipedia.org/wiki/Base58

[haltingprobability]

why  1FeefsqjLUeoanRrFxRFVUaPdTKUD4Vvhz  =    a0b098dd7f36e3da2d692e97ecf6ca07dadf4501
and   1FeefigBjmAAMepTiT2uziK2YnSXKkreD    =     02c5406b2e2a1c5a1b6b3fff03937185d23ea339

? hash160 not same normaly

The title doesn't reflect the question you're trying to ask.

What you're trying to ask is why the base58 decode of the two addresses you've given (on the right) doesn't match on some prefix since the base58 strings (on the left) appear to match for a prefix of four characters. The encoded address will probably be completely different after the first mismatch in the byte-encoding, from the left. Consider the following examples:

(a) Encode: 000102030405060708090a0b0c0d0e0f1011121314151617 --> 12D2adLM3UKy4Z4giRbReR6gjWrtsxoG

Now, let's change the last character of the encoded bytes from '7' to '6':

(b) Encode: 000102030405060708090a0b0c0d0e0f1011121314151616 --> 12D2adLM3UKy4Z4giRbReR6gjWrtsxoF

Notice that the two addresses are almost identical except that first address ends in 'G' and the second address ends in 'F'.

Finally, the strings you've given don't actually match at the left end:

Code:

1FeefsqjLUeoanRrFxRFVUaPdTKUD4Vvhz
 1FeefigBjmAAMepTiT2uziK2YnSXKkreD

Notice that the first address is one character longer than the other. They should be right-aligned for comparison purposes, not left-aligned.

[arubi]

Just wanted to add that it's also easy to keep most of the encoded address the same while changing the hash completely, for example :

FFE70FB0B47E80EBDC1CC4C3C59581110A10D52B
0469804540E7B2C646007EFA8C3BF4FBE146E931

Will result in :

1QL67LXU5LS8uoKCXDAy4bbgWY7ue2nHTA
1QL67LXU5LS8uoKCXDAy4bbgWY7uJFBhq

Of course it's hard to do this trick if I have to right-align the addresses

[haltingprobability]

Just wanted to add that it's also easy to keep most of the encoded address the same while changing the hash completely, for example :

FFE70FB0B47E80EBDC1CC4C3C59581110A10D52B
0469804540E7B2C646007EFA8C3BF4FBE146E931

Will result in :

1QL67LXU5LS8uoKCXDAy4bbgWY7ue2nHTA
1QL67LXU5LS8uoKCXDAy4bbgWY7uJFBhq

Of course it's hard to do this trick if I have to right-align the addresses

Good point. Every single character of an address should be checked before use, especially for any non-trivial transaction amount. At just 35 or so characters, that's not too much to ask.

I worked on an idea about 10 years ago to generate a kind of "visual hash" that would basically change drastically with a small change in input. The idea was to basically hash an object of interest (in this case, you would hash the base58 address itself) and then use the bits of the hash as a kind of program to generate a fractal pattern similar to an L-system. This would give rise to a very visually unique flower/snowflake pattern. Something like this but more colorful. Maybe I'll buckle down, learn Python and give it another go.

Prior work.

[arubi]

Right, like random-art or an ssh fingerprint.  But still it would only be useful for address re-use which is bad practice in itself.  (I could not think of another use)

[pebwindkraft]

and can the headine please be changed to something like "I don't undersand why base58decoding returns different values"?
And also get these annoying fire symbols removed ...
Maybe moderators can change this.

[haltingprobability]

Right, like random-art or an ssh fingerprint.  But still it would only be useful for address re-use which is bad practice in itself.  (I could not think of another use)

Not necessarily. Any address, pubkey, transaction ID, block-header, Merkle root, etc. could be rendered this way. It could help ensure that you're not making any mistakes, at a glance. "Yes, I'm really working with the address I mean to be working with", which could be useful for ensuring you don't spend the wrong output and also for ensuring that you're sending coins to the intended address (there may be a time-lag between the time you receive an address and the time you send coins to that address, or you may be working with a large number of addresses and want to be sure you don't get the wires crossed).

[arubi]

I realize the use case, but since addresses are single use, what would you be looking for when seeing a new fingerprint?  I agree about the usefulness in the "receive new address now, send coins to it later" case, but it's limited to a person's memory, and it's still possible to misremember some minute features of the fingerprint.
After long use of the same fingerprint you might begin to distinguish it better from others that are similar to it, but that's no good since it means you're just re-using addresses, and in case where some malware intentionally replaces addresses in your clipboard with some different address that might normally change the fingerprint, the same malware could replace the fingerprint too to show what would be the "honest address's" fingerprint.

Maybe it's useful for a hardware wallet setup?  Currently hardware wallets just flash the address on screen and usually there isn't enough room for the complete address, so it the user has to read some scrolling ticker made of random characters and "spot the difference".  A hardware wallet showing the true fingerprint on the screen and the user confirming it's the same one they wanted to use could be a cool feature.

[Vicrypt]

I looks perfectly normal.

[haltingprobability]

Maybe it's useful for a hardware wallet setup?  Currently hardware wallets just flash the address on screen and usually there isn't enough room for the complete address, so it the user has to read some scrolling ticker made of random characters and "spot the difference".  A hardware wallet showing the true fingerprint on the screen and the user confirming it's the same one they wanted to use could be a cool feature.

Sure, that's one use-case. There are many others. Once LN is up and running, Bitcoin payments can be manually sent over email and this makes the old-school "pubkey fingerprint" verification of a transactor's identity useful - if I trust you, I only need to know I'm talking to you. A visual hash is a way to represent an abstract identity (your pubkey fingerprint) so that I know I'm transacting with you and not somebody else. You could argue that real-world identities are superior but sometimes I want to transact with people without necessarily breaking anonymity. In short, I can trust you (by reputation or imputation) without knowing any identifying information beyond your pubkey fingerprint. Visual fingerprinting is way more reliable for use with my working memory than strings of ASCII characters because the visual features in an intricate fractal pattern are instantly distinguishable, requiring no memorization. Strings of characters are more absolute but require memorization.

ATM, I'm playing with the idea of something like this, http://mandalacreator.com/ but driven by something like an L-system (or a Markov algorithm) that takes input from a hash function.