23

It's just to get shorter addresses. Regular public keys are 65 bytes long, which is much too long to be convenient. Compressed public keys are 33 bytes and could potentially be used instead of hashes, though these are a little longer than 20-byte hashes. It also seems likely that Satoshi didn't know about compressed public keys or wasn't comfortable with ...


4

No, 58^34 is greater than 2^160: http://www.wolframalpha.com/input/?i=2*160+%3E+58*34 Note, that the address also contains a checksum and a network id not carrying additional information. That's why the numbers are not equal.


3

There are a multitude of reasons. As @ThePiachu mentioned, there is a theoretical 2^60 bit attack that is possible on SHA-1, meaning that the algorithm is weaker than designed. RIPEMD-160 was designed in the open academic community, in contrast to the NSA designed SHA-1 and SHA-2 algorithms. It is worth noting that Satoshi could've used SHA2-256 twice ...


2

As the protocol is upgraded with soft-forks changing script interpreter behaviour, the script-machine is extended with additional runs. Each new upgrade brings a new script run with new rules, whilst previous script runs continue to be evaluated according to older rules. Arguments need to be supplied to determine whether the newer script runs are to be ...


2

The P2WPKH actually uses the HASH160 hashing algorithm, which is just RIPEMD160(SHA256(pubkey)). The reason for using SHA256 is mentioned in BIP141: The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation ...


2

RIPEMD160 was designed in the open academic community and not like SHA2 by a NSA competition... one may see this as security advantage. 160bit hashes do also have less space requirements (then sha256) on the blockchain as well as in indexes, etc.


2

1AcJanbHGrBFwS3KJMDW8kEZMtHiJhatzE is a P2PKH (pay to pubkey hash) address. 3BJKWL5ipkVe2bjkRSt6ZNbVWQaRrEFjMs is a P2SH (pay to script hash) address. Their only difference is in the version byte that identifies the type of address. However, in order to spend a P2PKH output, one needs to reveal the public key with the address's hash160. In order to spend a ...


2

If your PRNGs are good, you don't lose any security by using the same address any number of times. Some websites claim that addresses should not be reused because that will make your bitcoins vulnerable to quantum computers and/or some newly discovered weaknesses in ECDSA. However, both of these scenarios are unrealistic at the moment, and I think that if ...


1

It could be due to a theoretical 2^60 bit attack that is possible on SHA-1, meaning that the algorithm is weaker than designed. RIPEMD does not appear to have such weaknesses.


1

You can insert two OP_HASH160 after the OP_DUP and then push the hash of your pubKeyHash. Nobody can tell the recipient address this way. Example: OP_DUP OP_HASH160 OP_HASH160 double_double_hash OP_EQUALVERIFY OP_CHECKSIG Where double_double_hash = RIPEMD160(SHA256(RIPEMD160(SHA256(pubKey))))


1

The malleability problem is not with the hashing function, but with what is being hashed (or not). The hashed data is malleable, not the hash directly.


1

Sorry to hear you were robbed. An attacker cannot reverse engineer a private key to obtain the original mnemonic phrase. What essentially happens is just another multitude of hashes with an algorithm (SHA256). Different approaches to this are taken by different deterministic wallet generators. As SHA256 is considered secure. So is your mnemonic phrase


1

Ok, here is the plain code for conversion from legacy to segwit: String addressToConvert = "1BGJEft81aaudqaCCcNnhsRQBA3Y96KYtx"; byte[] decoded = org.bitcoinj.core.Utils.parseAsHexOrBase58(addressToConvert); // We should throw off header byte that is 0 for Bitcoin (Main) byte[] pureBytes = new byte[20]; System.arraycopy(decoded, 1, ...


1

Address is in Base58 format. So, if you want to fet hex representation, you should firstly convert base58-address string to byte array and then convert it to hex string. bitcoinJ library has utilities for that, you can find all of the conversions there.


1

I have not the Java solution, but I can indicate the error. The conversion to hex is apparently missing. When I do the hash on the text file itself, I also get the wrong result: $ printf 1L88S26C5oyjL1gkXsBeYwHHjvGvCcidr9 > adr.txt $ openssl dgst -sha256 -binary <adr.txt >tmp_sha256.hex $ openssl dgst -ripemd160 <tmp_sha256.hex (stdin)= ...


1

In Go, you can do this very easily: package main import ( "fmt" "github.com/btcsuite/btcutil/base58" ) var addresses = []string{ "1Nh7uHdvY6fNwtQtM1G5EZAFPLC33B59rB", "1Le1ttNd2GQ79212Epyciw39JDy2E6DYWf", "1LpRieyPAZfFyUSMGiZhwAarQoJw1Y8pEx", } func main() { for _, address := range addresses { ripemd160, _, err := base58....


Only top voted, non community-wiki answers of a minimum length are eligible