6

Addresses are kept in Base58Check format. Here's how you decode it. Decode the base58 encoding (similar to Base64). You should have 25 bytes. Check that the 1st byte is 0x00 (the version byte of Bitcoin) Check that the last 4 bytes are a correct checksum of the rest. This is done (in Python) by: sha256(sha256(data[0:21]))[:4] == data[-4:] (Or, "take the ...


6

Because they are not compressed private keys. They are private keys with a marker that indicates that their corresponding public should be compressed. That extra marker takes an extra byte.


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


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

I'm not sure about ruby, but here's what's happening in practice. Take any xpub: xpub6DBfkACRRWo6B9Fo31Ko6P7M92Yb3rdbuXb81Ls7aDCaZsMr1tyvZWHAHz1exRZuTBspafkPTynwoWL5o3i4WiJX4P3SyGQxNpxQLaUnB2c Decoded to hex: ...


2

Yes. Every byte sequence corresponds to one Base58 string. Every byte sequence also corresponds to one Base58Check string, which contains a 4-byte redundancy, a checksum. And this 4-byte-code's only purpose is the detection of transmission errors (typos). Newer Bech32 addresses have a different kind of checksum allowing error correction, up to a certain ...


1

If you are using C# with NBitcoin var address = new Script("OP_DUP OP_HASH160 ... OP_EQUALVERIFY OP_CHECKSIG").GetDestinationAddress(Network.Main); It has the nice effect to work with P2SH addresses too.


1

Iterate from the beginning until you reach a non-zero byte. Base58 encode the non-zero byte and the following, and add 1s before the base58 string you made for each initial one zero byte (0x00) you counted. Zero bytes after the first non-zero byte don't need special treatment. For example, [0, 13, 36], is encoded as 1211 since the value is 1*58^2 and 1 in ...


1

Each hexadecimal character has four bits of information. Two hex characters contains eight bits of information, so they form a byte. For each byte in front of the address, a 1 should be put. Since two characters form a byte: int i=0; while(concat.charAt(i) == '0' && concat.charAt(i + 1) == '0'){ i += 2; output.append(code_string.charAt(0)); ...


1

I think you have a fundamental misunderstanding of Base58 encoding. Base58checked is not fixed length; its length depends on the number of leading zero bytes in the input. There should only be one leading "1" that signifies "main net" address type. A second leading "1" would indicate a whole leading zero byte (0x00) in the pubkey hash itself, which is not ...


1

Nothing is preventing any sort of data from using Base58Check encoding, but I'm not sure why you would want to. There's already a multitude of 'altcoins' using a variety of address prefixes though, so you might run into issues should one of them become a real-world success. In reality, I'd just avoid having users typing a UUID-type string at all, then you ...


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