|
|
|
@ -500,7 +500,7 @@ a potentially large amount of data, scrambles it (hashes it), and outputs a
|
|
|
|
|
fixed amount of data. A cryptographic hash function will always produce
|
|
|
|
|
the same output when given the same input, and a secure function will
|
|
|
|
|
also make it impractical for somebody to choose a different input that
|
|
|
|
|
produces a previously-seen output. That makes the output a _commitment_
|
|
|
|
|
produces a previously-seen output. That makes the ((("commitments", id="commitment")))output a _commitment_
|
|
|
|
|
to the input. It's a promise that, in practice, only input _x_ will
|
|
|
|
|
produce output _X_.
|
|
|
|
|
|
|
|
|
@ -603,7 +603,7 @@ Bitcoin wallet to Alice's wallet. There are commonly used encodings for
|
|
|
|
|
byte values, such as hexadecimal, but any mistake made in copying a
|
|
|
|
|
commitment would result in the bitcoins being sent to an unspendable
|
|
|
|
|
output, causing them to be lost forever. In the next section, we'll
|
|
|
|
|
look at compact encoding and reliable ((("public key cryptography", "hash functions and", startref="pub-key-hash")))((("hash functions", "Bitcoin payments and", startref="hash-payment")))((("payments", "with hash functions", secondary-sortas="hash functions", startref="payment-hash")))((("P2PKH (pay to public key hash)", startref="p2pkh")))checksums.
|
|
|
|
|
look at compact encoding and reliable ((("public key cryptography", "hash functions and", startref="pub-key-hash")))((("hash functions", "Bitcoin payments and", startref="hash-payment")))((("payments", "with hash functions", secondary-sortas="hash functions", startref="payment-hash")))((("P2PKH (pay to public key hash)", startref="p2pkh")))((("commitments", startref="commitment")))checksums.
|
|
|
|
|
|
|
|
|
|
[[base58]]
|
|
|
|
|
=== Base58Check Encoding
|
|
|
|
|