From 9b5c50ef7b94464382c7416b198d31c13b419018 Mon Sep 17 00:00:00 2001 From: BitWasp Date: Thu, 12 Feb 2015 21:13:30 +0000 Subject: [PATCH] Add dashes. --- bip-0090.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0090.mediawiki b/bip-0090.mediawiki index 36ec551e..11961f60 100644 --- a/bip-0090.mediawiki +++ b/bip-0090.mediawiki @@ -16,7 +16,7 @@ This BIP describes a method to deterministically generate multi-signature transa Most multi-signature transactions are addressed to P2SH (pay-to-script-hash) addresses, as defined in BIP-0016. -Multi-signature redeem scripts do not require a particular ordering or encoding for public keys. This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address. Adhering to a an ordering scheme and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address. +Multi-signature redeem scripts do not require a particular ordering or encoding for public keys. This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address. Adhering to an ordering and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address. By adopting a sorting and encoding standard, compliant wallets will always produce the same P2SH address for the same given set of keys and required signature count, making it easier to recognize transactions involving that multi-signature account. This is particularly attractive for multisignature hierarchical-deterministic wallets, as less state is required to setup multi-signature accounts: only the number of required signatures and master public keys of participants need to be shared, and all wallets will generate the same addresses.