diff --git a/home.md b/home.md index 1d191ca..fe437b8 100644 --- a/home.md +++ b/home.md @@ -25,7 +25,7 @@ [Proof of Work](/protocol/blockchain/proof-of-work) — [Difficulty Adjustment Algorithm](/protocol/blockchain/proof-of-work/difficulty-adjustment-algorithm) — [Mining](/protocol/blockchain/proof-of-work/mining) — [Stratum Protocol](/mining/stratum-protocol) — [Mining Pools](/mining/mining-pools) ### Addresses -Pay To Public Key (P2PK) — Pay To Public Key Hash (P2PKH) — Pay To Script Hash (P2SH) — [Base58Check encoding (legacy)](/protocol/blockchain/encoding/base58check) — [Cashaddr Encoding](/protocol/blockchain/encoding/cashaddr) +[Address Types](/protocol/blockchain/addresses) — [Base58Check Encoding (legacy)](/protocol/blockchain/encoding/base58check) — [Cashaddr Encoding](/protocol/blockchain/encoding/cashaddr) ### Cryptography [Bitcoin Keys (Public/Private)](/protocol/blockchain/cryptography/keys) — [Signatures (ECDSA/Schnorr)](/protocol/blockchain/cryptography/signatures) — [Multisignature (M-of-N multisig)](/protocol/blockchain/cryptography/multisignature) diff --git a/protocol/blockchain/addresses.md b/protocol/blockchain/addresses.md new file mode 100644 index 0000000..0873c3c --- /dev/null +++ b/protocol/blockchain/addresses.md @@ -0,0 +1,40 @@ +# Address Types + +Addresses are commonly used identifiers that act as a shorthand for who can spend a given output. +Since Bitcoin Cash [transactions](/protocol/blockchain/transaction) do not inherently have a concept of accounts with balances, it is not always easy (or even possible) to determine which unspent outputs are spendable by a given person. +However, the [standard scripts](/protocol/blockchain/transaction/locking-script#standard-scripts) were designed to provide a straightforward structure that can be used to identify transactions that spendable in similar ways. +In most cases, the address contains all of the information necessary to create a transaction output that is spendable by the owner of the address. +Due to this and their compactness, addresses are the most common way to specify to others how ("where") they can receive funds. + +Raw addresses are rarely used outside of scripts, though, as they lack context and redundancy. +Instead, addresses are typically encoded using the [Base58Check](/protocol/blockchain/encoding/base58check) or [CashAddr](/protocol/blockchain/encoding/cashaddr) formats to ensure they are received and interpreted correctly. +These encodings include checksums as well as information about the type of address being encoded. +CashAddr was created after Base58Check (also referred to as legacy encoding) to avoid conflicts with pre-existing BTC address. + +## Pay to Public Key Hash (P2PKH) Addresses + +[P2PKH](/protocol/blockchain/transaction/locking-script#pay-to-public-key-hash-p2pkh) addresses encode the hash of the public key that is locking the output (i.e. `RIPEMD-160(SHA-256(publicKey))`). +Mainnet P2PKH addresses always start with `1` in Base58Check encoding and `q` in CashAddr encoding: + + Base58Check: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa + CashAddr: bitcoincash:qp3wjpa3tjlj042z2wv7hahsldgwhwy0rq9sywjpyy + +## Pay to Script Hash (P2SH) Addresses + +[P2SH](/protocol/blockchain/transaction/locking-script#pay-to-script-hash-p2sh) addresses encode the redeem script hash (i.e. `RIPEMD-160(redeemScript)`). +Mainnet P2SH addresses always start with `3` in Base58Check encoding and `p` in CashAddr encoding. + + Base58Check: 3N5i3Vs9UMyjYbBCFNQqU3ybSuDepX7oT3 + CashAddr: bitcoincash:pr0662zpd7vr936d83f64u629v886aan7c77r3j5v5 + +## Multisig Addresses + +Multisig addresses are occasionally referenced despite there not being a specific process for creating them. +This is because the addresses being referred to are actually P2SH addresses for redeem scripts that perform [multisignature](/protocol/blockchain/cryptography/multisignature) validation. +As such, they look exactly like P2SH addresses and are indistinguishable from them until the script is known and inspected. +Moreover, outputs created using multsig addresses use the P2SH script format, not the [Multisig (P2MS)](/protocol/blockchain/transaction/locking-script#multisig-p2ms) script format. + +Alternatively, with the advent of [Schnorr signatures](/protocol/blockchain/cryptography/signatures#schnorr-signatures) in BCH, it is also possible perform n-of-n multisignature locking and unlocking using [aggregated keys and signatures](/protocol/blockchain/cryptography/multisignature#private-multisignature). +Only a single signature is produces, regardless of the number of parties involved, reducing the cost of multisignature validation and minimizing transaction size. +This also means it could fit in a P2PKH (or P2PK) script, and therefore have a typical address of that type. +This technique is newer, however, and not as widely implemented as the P2SH method. \ No newline at end of file diff --git a/protocol/blockchain/cryptography/multisignature.md b/protocol/blockchain/cryptography/multisignature.md index 0533a9d..3d8f098 100644 --- a/protocol/blockchain/cryptography/multisignature.md +++ b/protocol/blockchain/cryptography/multisignature.md @@ -4,7 +4,7 @@ Multisignature (often called "multisig") refers to requiring multiple keys to sp Multisignature scripts set a condition where N public keys are recorded in the script and at least M of those must provide signatures to unlock the funds. This is also known as *M-of-N multisignature scheme*, where N is the total number of keys and M is the threshold of signatures required for validation. The signatures used can either be ECDSA signatures or Schnorr signatures. -## Public multisignature: OP_CHECKMULTISIG(VERIFY) +## Public Multisignature: OP_CHECKMULTISIG(VERIFY) Multisig schemes can be built with the opcodes `OP_CHECKMULTISIG` and `OP_CHECKMULTISIGVERIFY`, two opcodes of the Bitcoin Cash [scripting language](/protocol/blockchain/script). `OP_CHECKMULTISIGVERIFY` has the same implementation as `OP_CHECKMULTISIG`, except OP_VERIFY is executed afterward. @@ -78,7 +78,9 @@ If they want to use Schnorr, they have to sign the transaction with this algorit The value of the `dummy` element is 5, whose binary representation is `0b101`. This ensures that Alice's signature (`sigA`) is checked against her public key (`pubkeyA`), that Carol's signature (`sigC`) is not checked against Bob's public key (`pubkeyB`) but against her public key (`pubkeyC`). -## Private multisignature - -Multisig schemes can also be implemented in P2PKH outputs, using Schnorr agregation property. +## Private Multisignature +N-of-N multisig schemes can also be implemented in P2PKH outputs, using the Schnorr aggregation property. +By combining the public keys of the cooperating parties, a combined public key can be created and used in a locking script. +When spending the output, the parties can jointly create a signature that will validate as a normal Schnorr signature for the combined public key in the locking script. +For more details, see [MuSig](https://eprint.iacr.org/2018/068). diff --git a/protocol/blockchain/transaction/locking-script.md b/protocol/blockchain/transaction/locking-script.md index b6ab44f..28ac806 100644 --- a/protocol/blockchain/transaction/locking-script.md +++ b/protocol/blockchain/transaction/locking-script.md @@ -31,7 +31,7 @@ That is, if it ever becomes possible to create a signature using a public key (n ### Pay to Public Key Hash (P2PKH) -Pay to Public Key Hash is a widely used standard locking script format, that works similarly to P2PK but instead of pushing the public key, it pushes a hash of the public key, commonly referred to as an address. +Pay to Public Key Hash is a widely used standard locking script format, that works similarly to P2PK but instead of pushing the public key, it pushes a hash of the public key, commonly referred to as an [address](/protocol/blockchain/addresses). This heavily reduces the risks associated with a plain P2PK script as the hashing algorithms used provide a considerable barrier to determining the public key a priori. To spend an output locked with this type of script, the unlocking script is expected to push a signature and then the public key corresponding to the private key that created the signature. If that public key hashes to the expected address, and the signature is valid, the output is allowed to be spent. @@ -84,7 +84,7 @@ One drawback of this is that it is not possible to determine whether certain ins This makes retirement of opcodes impossible. However, it's also possible for people to create transactions and not commit them to the blockchain, so the viability of opcode retirement is questionable anyway. -### Multisig +### Multisig (P2MS) Multiple-signature, or multisig, scripts provide a mechanism to have multiple private keys coordinate with spending funds. For example, three people could share funds and require that for some transactions any one of them could spend it while, for others, two of them would need to agree, and for others still, all three people would need to agree to spend the funds. @@ -92,6 +92,8 @@ Each party's public key is included in the locking script along with the require An unlocking script is therefore expected to provide the required number of signatures which are then checked against the list of public keys. If a sufficient number of valid signatures are provided, the output is allowed to be spent. +These are also referred to as "bare multisig" scripts to disambiguate them from P2SH multisig scripts (see [Multisignature](/protocol/blockchain/cryptography/multisignature)). + | Operation | Description | |--|--| | [OP_X](/protocol/blockchain/script/op-codes/op-x) | Push the number of parties required to provide signatures. |