afaik to get btc from "unspent addresses" (sorry for that really bad term) you need to break RIPEMD160 too?
or did i misunderstand sth?
Topic: Can someone explain why Bitcoin addresses are generated in the way that they are (Read 1587 times)
February 12, 2015, 04:59:23 AM
February 12, 2015, 04:52:55 AM
Yeah, I think I was thinking of that or something like that. But let me try to clarify, and see if this makes sense. If SHA-256 gets a minor break, nothing much will be affected. If SHA-256 gets a major break, as in catastrophic, then we have a lot of things to worry about and bitcoin would be the least of those.
Such much easier to steal from fiat banks than from attempting to brute force bitcoin private keys.
Such much easier to steal from fiat banks than from attempting to brute force bitcoin private keys.
February 12, 2015, 04:23:34 AM
Yeah, it started that way, and it will probably be best to continue it that way. If SHA-256 is ever broken, it is extremely unlikely that SHA-256(SHA-256(x)) would get broken.
Corrected it for you.
Bitcoin relies on the second preimage resistance of the hashing function. If you can find a second input that produces the same output of a single hashing function [ SHA256(x) == SHA256(y) ] then the output of the second round of hashing will also be identical [ If SHA256(x) == SHA256(y) then SHA256(SHA256(x) == SHA256(SHA256(y)) ].
February 12, 2015, 04:05:23 AM
Yeah, it started that way, and it will probably be best to continue it that way. If SHA-256 is ever broken, it is extremely unlikely that SHA-256(SHA-256(x)) would get broken.
February 12, 2015, 12:38:20 AM
Satoshi seemed overly fond of double hashing algorithms SHA-256(SHA-256(x)) and RIPEMD-160(SHA-256()). To my knowledge he never provided an explanation. A common usage of double hashing is to prevent length extension attacks but this is a very specific kind of attack which is applicable to Bitcoin. Honestly it really serves no purpose, a simple RIPEMD-160 of the PubKey (or Script) would have worked equally well. We probably will never know for sure.
There are a few other design choices which are best chalked up to "they are that way because Satoshi made it that way".
There are a few other design choices which are best chalked up to "they are that way because Satoshi made it that way".
February 12, 2015, 12:32:26 AM
Quote from: Stuffe link=topic=941841.msg10318514#msg10318514
I understand why you would RIPEMD hash it, to make it shorter
[/quote
I understand why you would RIPEMD hash it, to make it shorter
[/quote
Didn't you in a way answer yourself just now? Why would you make it shorter then hash it SHA256 and make it longer again?
February 10, 2015, 07:20:04 AM
I'm simply speculating, but it could be to keep addresses secure (until their first outbound txn) even if RIPEMD or ECDSA is broken. Your comment about the checksum is exactly on point.
January 31, 2015, 07:32:06 AM
So according to the link below, Bitcoin addresses are ECDSA public keys that have gone through a bunch of hash functions.
I understand why you would RIPEMD hash it, to make it shorter and I also understand why you would base 58 encode it to make it even shorter.
Lastly, I also understand why they hash it one more time to create a checksum that ensures people don't accidentally send to bogus addresses.
But what are the other steps for? Why for example SHA-256 hash before you RIPEMD hash?
List of steps are found here.
https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses
I understand why you would RIPEMD hash it, to make it shorter and I also understand why you would base 58 encode it to make it even shorter.
Lastly, I also understand why they hash it one more time to create a checksum that ensures people don't accidentally send to bogus addresses.
But what are the other steps for? Why for example SHA-256 hash before you RIPEMD hash?
List of steps are found here.
https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses
Jump to: