Synchronised BIPs wiki Wiki changes.

bip-0011.md

@@ -35,6 +35,8 @@ OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig:
 
 (OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack).
 
+The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accomodate 3-signature transactions, this will be increased to 500 bytes.
+
 ==Rationale==
 
 OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases.

bip-0012.md

@@ -82,3 +82,4 @@ https://bitcointalk.org/index.php?topic=46538
 
 M-of-N Multisignature Transactions BIP 11
 
+

bip-0013.md

@@ -8,9 +8,9 @@
 </pre>
 ==Abstract==
 
-This BIP describes a new type of bitcoin address to support arbitrarily complex transactions.  Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin.
+This BIP describes a new type of Bitcoin address to support arbitrarily complex transactions.  Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin.
 
-In essence, an address encoded under this proposal represents the encoded hash of a script, rather than the encoded hash of an ECDSA [[public key]].
+In essence, an address encoded under this proposal represents the encoded hash of a [[script]], rather than the encoded hash of an ECDSA public key.
 
 ==Motivation==
 
@@ -18,11 +18,11 @@ Enable "end-to-end" secure wallets and payments to fund escrow transactions or o
 
 ==Specification==
 
-The new bitcoin address type is constructed in the same manner as existing bitcoin addresses:
+The new bitcoin address type is constructed in the same manner as existing bitcoin addresses (see [[Base58Check encoding]]):
 
     base58-encode: [one-byte version][20-byte hash][4-byte checksum]
 
-Version byte is 1 for a main-network address, 112 for a testnet address.
+Version byte is 2 for a main-network address, 109 for a testnet address.
 The 20-byte hash is the hash of the script that will be used to redeem the coins.
 And the 4-byte checksum is the first four bytes of the SHA256 hash of the version and hash.