You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: bip-0017.mediawiki
+1-1
Original file line number
Diff line number
Diff line change
@@ -86,7 +86,7 @@ Avoiding a block-chain split by malicious pay-to-script transactions requires ca
86
86
87
87
* A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners.
88
88
89
-
To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.
89
+
To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.
90
90
91
91
To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "p2sh/CHV" in the input of the coinbase transaction for blocks that they create.
Copy file name to clipboardExpand all lines: bip-0038.mediawiki
+6-6
Original file line number
Diff line number
Diff line change
@@ -64,7 +64,7 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are
64
64
* How the user sees it: 58 characters always starting with '6P'
65
65
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
66
66
* Count of payload bytes (beyond prefix): 37
67
-
** 1 byte (''flagbyte''):
67
+
** 1 byte (''flagbyte''):
68
68
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
69
69
*** the bit with value 0x20 when set indicates the key should be converted to a base58check encoded P2PKH bitcoin address using the DER compressed public key format. When not set, it should be a base58check encoded P2PKH bitcoin address using the DER uncompressed public key format.
70
70
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
@@ -75,10 +75,10 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are
75
75
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
76
76
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
77
77
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
78
-
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
78
+
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
79
79
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
80
80
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
81
-
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
81
+
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
82
82
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
83
83
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
84
84
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
Copy file name to clipboardExpand all lines: bip-0042.mediawiki
+1-1
Original file line number
Diff line number
Diff line change
@@ -42,7 +42,7 @@ Note that several other programming languages do not exhibit this behaviour, mak
42
42
43
43
===Floating-point approximation===
44
44
45
-
An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript.
45
+
An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript.
// Verify that the length of the signature matches the sum of the length
76
76
// of the elements.
77
77
if ((size_t)(lenR + lenS + 7) != sig.size()) return false;
78
-
78
+
79
79
// Check whether the R element is an integer.
80
80
if (sig[2] != 0x02) return false;
81
81
@@ -140,7 +140,7 @@ An implementation for the reference client is available at https://github.com/bi
140
140
141
141
==Acknowledgements==
142
142
143
-
This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well.
143
+
This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well.
Copy file name to clipboardExpand all lines: bip-0067.mediawiki
+23-23
Original file line number
Diff line number
Diff line change
@@ -19,39 +19,39 @@ This BIP describes a method to deterministically generate multi-signature pay-to
19
19
20
20
==Motivation==
21
21
22
-
Pay-to-script-hash (BIP-0011<ref>[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]</ref>) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts.
22
+
Pay-to-script-hash (BIP-0011<ref>[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]</ref>) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts.
23
23
24
24
Multi-signature pay-to-script-hash transactions are defined in BIP-0016<ref>[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP-0016]</ref>. The redeem script does 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.
25
25
26
26
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.
27
27
28
28
While most web wallets do not presently facilitate the setup of multisignature accounts with users of a different service, conventions which ensure cross-compatibility should make it easier to achieve this.
29
29
30
-
Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions.
30
+
Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions.
31
31
This standard will help in enabling a party other than the service provider to recover the wallet without any help from the service provider.
32
32
33
33
==Specification==
34
34
35
35
For a set of public keys, ensure that they have been received in compressed form:
Hash the redeem script according to BIP-0016 to get the P2SH address.
52
-
52
+
53
53
3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
54
-
54
+
55
55
==Compatibility==
56
56
* Uncompressed keys are incompatible with this specification. A compatible implementation should not automatically compress keys. Receiving an uncompressed key from a multisig participant should be interpreted as a sign that the user has an incompatible implementation.
57
57
* P2SH addresses do not reveal information about the script that is receiving the funds. For this reason it is not technically possible to enforce this BIP as a rule on the network. Also, it would cause a hard fork.
Copy file name to clipboardExpand all lines: bip-0068.mediawiki
+3-3
Original file line number
Diff line number
Diff line change
@@ -33,7 +33,7 @@ If bit (1 << 31) of the sequence number is set, then no consensus meaning is app
33
33
34
34
If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time.
35
35
36
-
The sequence number encoding is interpreted as follows:
36
+
The sequence number encoding is interpreted as follows:
37
37
38
38
Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks.
39
39
@@ -65,7 +65,7 @@ enum {
65
65
/* Interpret sequence numbers as relative lock-time constraints. */
66
66
LOCKTIME_VERIFY_SEQUENCE = (1 << 0),
67
67
};
68
-
68
+
69
69
/* Setting nSequence to this value for every input in a transaction
0 commit comments