diff options
| -rw-r--r-- | bip-0002.mediawiki | 19 | ||||
| -rw-r--r-- | bip-0009.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0021.mediawiki | 3 | ||||
| -rw-r--r-- | bip-0032.mediawiki | 16 |
4 files changed, 30 insertions, 12 deletions
diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki index 35d38c2..c6eb950 100644 --- a/bip-0002.mediawiki +++ b/bip-0002.mediawiki @@ -41,14 +41,14 @@ It also helps to make sure the idea is applicable to the entire community and no Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Bitcoin development mailing list]. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be submitted to the [https://github.com/bitcoin/bips BIPs git repository] as a pull request. -This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers). +This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until an editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers). BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here. It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones. -When the BIP draft is complete, the BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository. -The BIP editor will not unreasonably reject a BIP. +When the BIP draft is complete, a BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository. +The BIP editors will not unreasonably reject a BIP. Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. @@ -61,16 +61,19 @@ The BIP author may update the draft as necessary in the git repository. Updates It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP. -If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :). +If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editors. If the original author doesn't respond to email in a timely manner, the BIP editors will make a unilateral decision (it's not like such decisions can't be reversed :). ===BIP Editors=== -The current BIP editor is Luke Dashjr who can be contacted at [[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]]. +The current BIP editors are: + +* Luke Dashjr ([[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]]) +* Kalle Alm ([[mailto:karljohan-alm@garage.co.jp|karljohan-alm@garage.co.jp]]) ===BIP Editor Responsibilities & Workflow=== -The BIP editor subscribes to the Bitcoin development mailing list. -Off-list BIP-related correspondence should be sent (or CC'd) to luke_bipeditor@dashjr.org. +The BIP editors subscribe to the Bitcoin development mailing list. +Off-list BIP-related correspondence should be sent (or CC'd) to the BIP editors. For each new BIP that comes in an editor does the following: @@ -186,7 +189,7 @@ The typical paths of the status of BIPs are as follows: <img src="bip-0002/process.png"></img> Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. -The BIP editor may also change the status to Deferred when no progress is being made on the BIP. +A BIP editor may also change the status to Deferred when no progress is being made on the BIP. A BIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status. diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index c9fcd6f..f7fbad1 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -197,7 +197,7 @@ Miners MAY clear or set bits in the block version WITHOUT any special "mutable" Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character. Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs [[bip-0016.mediawiki|16]], [[bip-0065.mediawiki|65]], [[bip-0066.mediawiki|66]], [[bip-0068.mediawiki|68]], [[bip-0112.mediawiki|112]], and [[bip-0113.mediawiki|113]]. If a client does not understand a rule without the prefix, it may use it unmodified for mining. -On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction). +On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be [[bip-0034.mediawiki|BIP 34]] (because it modifies coinbase construction) and [[bip-0141.mediawiki|141]] (since it modifies the txid hashing and adds a commitment to the generation transaction). A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified. ==Support for future changes== @@ -205,7 +205,7 @@ A client that does not understand a rule prefixed by '!' must not attempt to pro The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account. '''Modified thresholds''' -The 1916 threshold (based on in BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore. +The 1916 threshold (based on BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore. '''Conflicting soft forks''' At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes. diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki index cfab856..0fba9bc 100644 --- a/bip-0021.mediawiki +++ b/bip-0021.mediawiki @@ -58,10 +58,9 @@ The scheme component ("bitcoin:") is case-insensitive, and implementations must *label: Label for that address (e.g. name of receiver) *address: bitcoin address *message: message that describes the transaction to the user ([[#Examples|see examples below]]) -*size: amount of base bitcoin units ([[#Transfer amount/size|see below]]) *(others): optional, for future extensions -==== Transfer amount/size ==== +==== Transfer amount ==== If an amount is provided, it MUST be specified in decimal BTC. All amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions. diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index f2f1e48..b8152e7 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -4,6 +4,7 @@ RECENT CHANGES: * (25 May 2013) Added test vectors * (15 Jan 2014) Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions. * (24 Feb 2017) Added test vectors for hardened derivation with leading zeros +* (4 Nov 2020) Added new test vectors for hardened derivation with leading zeros <pre> BIP: 32 @@ -272,6 +273,21 @@ Seed (hex): 4b381541583be4423346c643850da4b320e46a87ae3d2a4e6da11eba819cd4acba45 ** ext pub: xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y ** ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L +===Test vector 4=== + +These vectors test for the retention of leading zeros. See [https://github.com/btcsuite/btcutil/issues/172 btcsuite/btcutil#172] for more information. + +Seed (hex): 3ddd5602285899a946114506157c7997e5444528f3003f6134712147db19b678 +* Chain m +** ext pub: xpub661MyMwAqRbcGczjuMoRm6dXaLDEhW1u34gKenbeYqAix21mdUKJyuyu5F1rzYGVxyL6tmgBUAEPrEz92mBXjByMRiJdba9wpnN37RLLAXa +** ext prv: xprv9s21ZrQH143K48vGoLGRPxgo2JNkJ3J3fqkirQC2zVdk5Dgd5w14S7fRDyHH4dWNHUgkvsvNDCkvAwcSHNAQwhwgNMgZhLtQC63zxwhQmRv +* Chain m/0<sub>H</sub> +** ext pub: xpub69AUMk3qDBi3uW1sXgjCmVjJ2G6WQoYSnNHyzkmdCHEhSZ4tBok37xfFEqHd2AddP56Tqp4o56AePAgCjYdvpW2PU2jbUPFKsav5ut6Ch1m +** ext prv: xprv9vB7xEWwNp9kh1wQRfCCQMnZUEG21LpbR9NPCNN1dwhiZkjjeGRnaALmPXCX7SgjFTiCTT6bXes17boXtjq3xLpcDjzEuGLQBM5ohqkao9G +* Chain m/0<sub>H</sub>/1<sub>H</sub> +** ext pub: xpub6BJA1jSqiukeaesWfxe6sNK9CCGaujFFSJLomWHprUL9DePQ4JDkM5d88n49sMGJxrhpjazuXYWdMf17C9T5XnxkopaeS7jGk1GyyVziaMt +** ext prv: xprv9xJocDuwtYCMNAo3Zw76WENQeAS6WGXQ55RCy7tDJ8oALr4FWkuVoHJeHVAcAqiZLE7Je3vZJHxspZdFHfnBEjHqU5hG1Jaj32dVoS6XLT1 + ==Acknowledgements== |