12

The characters excluded in Base58 are 0OIl. oiL are allowed, making these two valid addresses. It is impossible to send to an invalid address, as Bitcoin transaction scripts actually include raw 160-bit hashes (which by definition have a one-to-one correspondence with valid addresses), not addresses. Bitcoin clients will simply refuse to do anything if an ...


11

None. It's impossible to send bitcoins to an invalid address. Those addresses are valid, though they might not be owned by anyone. Look at pszBase58 more carefully: 'o', 'i', and 'L' are allowed. The first few posts in that forum thread are wrong. The network doesn't know anything about Bitcoin addresses. At the network level, you never send bitcoins to an ...


8

The rules are the same, but the available range is different. In the testnet the address prefix is 111 (https://en.bitcoin.it/wiki/List_of_address_prefixes). To deduce the address you write in base58 the prefix concatenated with a 160 bit (20 bytes) hash of the public address and a checksum of 4 bytes (https://en.bitcoin.it/wiki/...


8

Then both of the people could spend the same coins if they were sent to their Address, rather than public key. If they instead received the money to the public keys, they couldn't spend eachother's coins. All in all, the most important thing that would happen is that they would show RIPEMD-160 collision, which would most likely be the first one ever. A ...


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


5

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


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

To normalize leading zeros is documented in this link, namely this text at the bottom: In a standard base conversion, the 0x00 byte on the left would be irrelevant (like writing 052 instead of 52) but in the BTC network the left most zero chars are carried through the conversion. So for every 0x00 byte on the left end of the binary address, we will ...


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

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


1

Vanity Addresses only reduce the apparent randomness of a public key. The underlying private key is still just as random as always, as the private key does not have any special characteristics (it does not have a special pattern in front or anything like that). A given public key is as likely to be generated by a private key from range 0-10, as for 1000000-...


1

I'm using BigInteger in .NET so these tests are unique to this scenario but may be adapted to Java or other languages. The tests I've found helpful is when translating to or from hexadecimal at any intermediate step make sure the data is correct when: The first or last byte of the checksum is one or more 0's The first or last byte of the address is one or ...


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