Hot answers tagged

18

What you are requesting is described as computing the Wallet Import Format for that private key: http://en.bitcoin.it/wiki/Wallet_import_format Using your example: 1.) Take a private key (Below is the HEX representation of binary value) 7542FB6685F9FD8F37D56FAF62F0BB4563684A51539E4B26F0840DB361E0027C 2.) Add a 0x80 byte in front of it ...


10

Why base-58 instead of standard base-64 encoding? Don't want 0OIl characters that look the same in some fonts and could be used to create visually identical looking account numbers. A string with non-alphanumeric characters is not as easily accepted as an account number. E-mail usually won't line-break if there's no punctuation to break at. Double-clicking ...


5

Just like in regular bitcoin addresses (or anything base 58 encoded), the version bytes don't get encoded by themselves. As described in the Serialization format section, there is 78 byte payload that gets versioned and checksumed before then being encoded into base 58: 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: ...


4

I usually use the following analogy to oversimplify things: The secret key is how far you walk along a known curve starting from a known point and the public point is where on the curve you wind up when you finish. If you repeat the same walk, you will always wind up at the same place. The operation is irreversible because the curve is complex, you can only ...


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.


4

Yes. ECKey key = ...; String addr = key.toAddress(MainNetParams.get()).toString(); https://bitcoinj.github.io/javadoc/0.12/org/bitcoinj/core/ECKey.html#toAddress-org.bitcoinj.core.NetworkParameters-


4

If you don't want to compute the key manually, there's a useful command-line utility for this called bitcoin-tool: $ ./bitcoin-tool \ --input-file <(echo -n 'Hi guys!' | openssl dgst -sha256 -binary) \ --input-format raw \ --input-type private-key \ --network bitcoin \ --output-type private-key-wif \ --output-format base58check \ --public-...


4

When you use that site, you are encoding the hex as a hex string, not of the actual bytes that they should be. The base58 encoding for addresses operates on the bytes themselves which are represented in the hex string. However that website is just encoding the hex string (which, as bytes, is double the length and is entirely other data).


3

I've found this project: https://github.com/oskyk/cashaddress , checked the accounts generated by it using validateaddress of my wallet, seems working fine!


3

The last 4 bytes of the WIF format is a checksum. The details can be seen here: https://en.bitcoin.it/wiki/Wallet_import_format That's approximately 5 characters of Base58 that are essentially redundant. This is so that errors in the WIF encoded private key can be detected easily. I believe some wallets will simply ignore the checksum if it's not correct.


3

The bitcoin protocol doesn't really support the concept of a transaction sender. All you can come up with is an address owned by someone who previously controlled the transaction's outputs, which however might not actually be the sender (e.g. for e-wallets) and who may not actually intend to receive anything there in the first place. Take some time to see ...


3

Simple website to create burn address http://gobittest.appspot.com/ProofOfBurn If you want a script try this https://gist.github.com/CoinWhisperer/6d673f1f3d13da1611cd


3

I believe flickr uses a base 58 scheme for encoding picture IDs in URLs, though Bitcoin's Base58 isn't compatible with flickr's.


2

com.google.bitcoin.core.ECKey key = new com.google.bitcoin.core.ECKey(); // keypair byte[] pub = key.getPublicKey(); // byte array String prv; prv = key.getPrivateKeyEncoded(com.google.bitcoin.core.NetworkParameters.prodNet());


2

Yes there can be multiple leading '1' characters, and each '1' represents one leading zero byte. This leads to a shorter address because normally each base58 character represents slightly less than 6 bits of information, but a leading zero byte contains exactly 8 bits of information. For example the shortest address you can have is ...


2

This answer is probably too late for the OP, but it might clear things up for whoever ends up with the same question later. So here it goes: I'm assuming you (as I did until a moment ago) have the misconception that the private key is also a pair of (x, y) coordinates in the elliptic curve, just as the public key. Well simple answer, it is not. The private ...


2

The reason is historical. The 'version' byte was originally really just a version number. Satoshi probably intended to introduce more types of standard scripts to addresses. There were comments in the code about upgrading an address from one version to a new one even. In that vision, to not restrict the options for future versions, I chose to make the ...


2

A picture is worth a 1000 words. See Figure 6 from Chapter 4 of the Bitcoin Book. The last 4 bytes are used as a checksum for error checking. The version prefix is different for Bitcoin altcoin forks. See the 3rd column of this Table for versions used by various altcoins.


2

You're performing a SHA256 on an ASCII string, not on the actual number. That ASCII string is actually the hexadecimal representation of the actual number. This is a little code snippet that uses a hex2bin function to turn the hexadecimal representation (from your question) into an actual number before performing the sha256 on it.


2

Your output is correct given the input that you used. However, If you are expecting to get an output address of 39YteymR86cG7V3Kijg8Gm2ST1r4nTeM1b, it looks like your input is incorrect. It's missing the first byte and the last 4 bytes (encoded as hex): Your Input: --56379c7bcd6b41188854e74169f844e8676cf8b8-------- Proper Input: ...


2

They should use those: cashaddr.org cashaddr.bitcoincash.org cashaddress.github.io Or, you can use the CashAddrJS library to convert between them (Here are the browser JS). Unfortunately there's no RPC command to convert addresses. Sorry!


2

Can someone explain what it is and why it's called Base58Check encoding? Because of the name the function in the original Bitcoin codebase had. The "Base58" refers to the fact that it is a base 58 format (it uses 58 different characters to encode the data), and the "Check" refers to the fact that a checksum is added to the encoded data. Are addresses ...


2

Can someone explain what it is and why it's called Base58Check encoding? There are two parts to the name "Base58Check". The first part is "Base58". This is fairly self explanatory, the encoding uses Base 58. This means that there are 58 digits which are represented by 58 characters. One digit is a number between 0 and 57, just like how in the decimal system ...


2

I've used Base58 encoding/decoding many times. On the contrary, I hated using a BIGNUM library. So, I used Base-x's base conversion algorithm. (Make sure to respect the MIT license) It should be easy to translate it to any language. const char * const ALPHABET = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"; const char ALPHABET_MAP[128] = ...


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....


1

I think maybe this one?: 800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D Yep! and I don't know how to convert its bytes to a "big integer" (keep in mind that I'm trying to learn and therefore need to do all of the math myself instead of simply having an existing programming command or web tool do it for me). First, you need to ...


1

If the public key were correct (see Mark's answer), the code is not complete (lacks signature) and contains a hash of an ASCII hexdigest which is not correct. I'd like to contribute with this implementation of bitcoin address from public key. It covers the case of both uncompressed and compressed bitcoin addresses (just changing compress_pubkey boolean value)...


1

you need to use bytes.fromhex() function. here is a related example (python3) import hashlib import ecdsa import base58 def generate_private_and_public_keys(secret): #hash digest digest = hashlib.sha256(secret.encode()).hexdigest() #signing and verification keys signing_key = ecdsa.SigningKey.from_string(bytes.fromhex(digest), curve=ecdsa....


1

Here is how to use the bitcoin-explorer command line to generate an uncompressed WIF private key on a UNIX box: % echo 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D | bx base58check-encode -v 128 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ The following provides feedback for going the opposite direction: % echo ...


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