diff options
| -rw-r--r-- | README.mediawiki | 7 | ||||
| -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 | 18 | ||||
| -rw-r--r-- | bip-0039.mediawiki | 3 | ||||
| -rw-r--r-- | bip-0078.mediawiki | 12 | ||||
| -rw-r--r-- | bip-0085.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0086.mediawiki | 128 | ||||
| -rw-r--r-- | bip-0088.mediawiki | 6 | ||||
| -rw-r--r-- | bip-0155.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0173.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0174.mediawiki | 10 | ||||
| -rw-r--r-- | bip-0341.mediawiki | 6 | ||||
| -rw-r--r-- | bip-0370.mediawiki | 2 |
15 files changed, 193 insertions, 31 deletions
diff --git a/README.mediawiki b/README.mediawiki index d8bcae6..eaafbef 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -434,6 +434,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Ethan Kosakovsky | Informational | Draft +|- +| [[bip-0086.mediawiki|86]] +| Applications +| Key Derivation for Single Key P2TR Outputs +| Andrew Chow +| Standard +| Draft |- style="background-color: #ffffcf" | [[bip-0087.mediawiki|87]] | Applications 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..88c2dbb 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 @@ -118,7 +119,7 @@ To shorten notation, we will write CKDpriv(CKDpriv(CKDpriv(m,3<sub>H</sub>),2),5 * N(m/a<sub>H</sub>/b/c) = N(m/a<sub>H</sub>/b)/c = N(m/a<sub>H</sub>)/b/c. However, N(m/a<sub>H</sub>) cannot be rewritten as N(m)/a<sub>H</sub>, as the latter is not possible. -Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public keys allows reconstruction of all descendant non-hardened public keys. +Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public key allows reconstruction of all descendant non-hardened public keys. ===Key identifiers=== @@ -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== diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 40288dd..4ac3c55 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -176,6 +176,9 @@ Rust: * https://github.com/maciejhirsz/tiny-bip39/ * https://github.com/koushiro/bip0039-rs +Smalltalk: +* https://github.com/eMaringolo/pharo-bip39mnemonic + Swift: * https://github.com/CikeQiu/CKMnemonic * https://github.com/yuzushioh/WalletKit diff --git a/bip-0078.mediawiki b/bip-0078.mediawiki index c795343..3c2fe2e 100644 --- a/bip-0078.mediawiki +++ b/bip-0078.mediawiki @@ -209,7 +209,7 @@ In such case, the receiver will need to increase the fee of the transaction afte * The sender's wallet software is using round fee rate. If the sender's fee rate is always round, then a blockchain analyst can easily spot the transactions of the sender involving payjoin by checking if, when removing a single input to the suspected payjoin transaction, the resulting fee rate is round. -To prevent this, the sender can agree to pay more more fee so the receiver make sure that the payjoin transaction fee is also round. +To prevent this, the sender can agree to pay more fee so the receiver make sure that the payjoin transaction fee is also round. * The sender's transaction is time sensitive. @@ -249,7 +249,7 @@ The receiver needs to do some check on the original PSBT before proceeding: ===Sender's payjoin proposal checklist=== The sender should check the payjoin proposal before signing it to prevent a malicious receiver from stealing money. - + * Verify that the absolute fee of the payjoin proposal is equals or higher than the original PSBT. * If the receiver's BIP21 signalled <code>pjos=0</code>, disable payment output substitution. * Verify that the transaction version, and the nLockTime are unchanged. @@ -272,7 +272,7 @@ The sender should check the payjoin proposal before signing it to prevent a mali ** If the output is the [[#fee-output|fee output]]: *** The amount that was substracted from the output's value is less than or equal to <code>maxadditionalfeecontribution</code>. Let's call this amount <code>actual contribution</code>. *** Make sure the actual contribution is only paying fee: The <code>actual contribution</code> is less than or equals to the difference of absolute fee between the payjoin proposal and the original PSBT. -*** Make sure the actual contribution is only paying for fee incurred by additional inputs: <code>actual contribution</code> is less than or equals to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(original_psbt_inputs) - count(payjoin_proposal_inputs))</code>. (see [[#fee-output|Fee output]] section) +*** Make sure the actual contribution is only paying for fee incurred by additional inputs: <code>actual contribution</code> is less than or equals to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs))</code>. (see [[#fee-output|Fee output]] section) ** If the output is the payment output and payment output substitution is allowed. *** Do not make any check ** Else @@ -325,7 +325,7 @@ Because the receiver needs to bump the fee to keep the same fee rate as the orig The validation (policy and consensus) of the original transaction is optional: a receiver without a full node can decide to create the payjoin transaction and automatically broadcast the original transaction after a timeout of 1 minute, and only verify that it has been propagated in the network. -However, non-interactive receivers (like a payment processor) need to verify the transaction to prevent UTXO probing attacks. +However, non-interactive receivers (like a payment processor) need to verify the transaction to prevent UTXO probing attacks. This is not a concern for interactive receivers like Wasabi Wallet, because those receivers can just limit the number of original PSBT proposals of a specific address to one. With such wallets, the attacker has no way to generate new deposit addresses to probe the UTXOs. @@ -498,7 +498,7 @@ public async Task<PSBT> RequestPayjoin( if (proposedPSBTInput.NonWitnessUtxo != null || proposedPSBTInput.WitnessUtxo != null) throw new PayjoinSenderException("The receiver added non_witness_utxo or witness_utxo to one of our inputs"); sequences.Add(proposedTxIn.Sequence); - + // Fill up the info from the original PSBT input so we can sign and get fees. proposedPSBTInput.NonWitnessUtxo = input.SignedPSBTInput.NonWitnessUtxo; proposedPSBTInput.WitnessUtxo = input.SignedPSBTInput.WitnessUtxo; @@ -660,7 +660,7 @@ A successful exchange with: * [[https://github.com/BlueWallet/BlueWallet|BlueWallet]] is in the process of implementing the protocol. * [[https://github.com/btcpayserver/btcpayserver|BTCPay Server]] has implemented sender and receiver side of this protocol. * [[https://github.com/zkSNACKs/WalletWasabi/|Wasabi Wallet]] has merged sender's support. -* [[https://github.com/JoinMarket-Org/joinmarket-clientserver|Join Market]] is in the process of implementing the protocol. +* [[https://github.com/JoinMarket-Org/joinmarket-clientserver|Join Market]] has implemented sender and receiver side of this protocol. * [[https://github.com/bitcoinjs/payjoin-client|JavaScript sender implementation]]. ==Backward compatibility== diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index b0131c3..6e7dd0e 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -104,6 +104,8 @@ OUTPUT * Ian Coleman's Mnemonic Code Converter: [https://github.com/iancoleman/bip39] and [https://iancoleman.io/bip39/] +* AirGap Vault: [https://github.com/airgap-it/airgap-vault/commit/d64332fc2f332be622a1229acb27f621e23774d6] + btc_hd_wallet: [https://github.com/scgbckbone/btc-hd-wallet] ==Applications== diff --git a/bip-0086.mediawiki b/bip-0086.mediawiki new file mode 100644 index 0000000..f724884 --- /dev/null +++ b/bip-0086.mediawiki @@ -0,0 +1,128 @@ +<pre> + BIP: 86 + Layer: Applications + Title: Key Derivation for Single Key P2TR Outputs + Author: Andrew Chow <andrew@achow101.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0086 + Status: Draft + Type: Standards Track + Created: 2021-06-22 + License: BSD-2-Clause +</pre> + +==Abstract== + +This document suggests a derivation scheme for HD wallets whose keys are involved in single key +P2TR ([[bip-0341.mediawiki|BIP 341]]) outputs as the Taproot internal key. + +===Copyright=== + +This BIP is licensed under the 2-clause BSD license. + +==Motivation== + +With the usage of single key P2TR transactions, it is useful to have a common derivation scheme so +that HD wallets that only have a backup of the HD seed can be likely to recover single key Taproot +outputs. Although there are now solutions which obviate the need for fixed derivation paths for +specific script types, many software wallets and hardware signers still use seed backups which +lack derivation path and script information. Thus we largely use the same approach used in BIPs +[[bip-0049.mediawiki|49]] and [[bip-0084.mediawiki|84]] for ease of implementation. + +==Specifications== + +This BIP defines the two needed steps to derive multiple deterministic addresses based on a +[[bip-0032.mediawiki|BIP 32]] master private key. + +===Public key derivation=== + +To derive a public key from the root account, this BIP uses the same account-structure as +defined in BIPs [[bip-0044.mediawiki|44]], [[bip-0049.mediawiki|49]], and [[bip-0084.mediawiki|84]], +but with a different purpose value for the script type. + +<pre> +m / purpose' / coin_type' / account' / change / address_index +</pre> + +For the <tt>purpose</tt>-path level it uses <tt>86'</tt>. +The rest of the levels are used as defined in BIPs 44, 49, and 84. + +A key derived with this derivation path pattern will be referred to as <tt>derived_key</tt> further +in this document. + +===Address derivation=== + + +[[bip-0341.mediawiki#cite_ref-22-0|BIP 341]] states: "If the spending conditions do not require a +script path, the output key should commit to an unspendable script path instead of having no +script path. This can be achieved by computing the output key point as +''Q = P + int(hash<sub>TapTweak</sub>(bytes(P)))G''." Thus: + +<pre> +internal_key: lift_x(derived_key) +32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G +</pre> + +In a transaction, the scripts and witnesses are as defined in +[[bip-0341.mediawiki#specification|BIP 341]]: + +<pre> +witness: <signature> +scriptSig: (empty) +scriptPubKey: 1 <32_byte_output_key> + (0x5120{32_byte_output_key}) +</pre> + +==Backwards Compatibility== + +This BIP is not backwards compatible by design. +An incompatible wallet will not discover these accounts at all and the user will notice that +something is wrong. + +However this BIP uses the same method used in BIPs 44, 49, and 84, so it should not be difficult +to implement. + +==Test vectors== + +<pre> +mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about +rootpriv = xprv9s21ZrQH143K3GJpoapnV8SFfukcVBSfeCficPSGfubmSFDxo1kuHnLisriDvSnRRuL2Qrg5ggqHKNVpxR86QEC8w35uxmGoggxtQTPvfUu +rootpub = xpub661MyMwAqRbcFkPHucMnrGNzDwb6teAX1RbKQmqtEF8kK3Z7LZ59qafCjB9eCRLiTVG3uxBxgKvRgbubRhqSKXnGGb1aoaqLrpMBDrVxga8 + +// Account 0, root = m/86'/0'/0' +xprv = xprv9xgqHN7yz9MwCkxsBPN5qetuNdQSUttZNKw1dcYTV4mkaAFiBVGQziHs3NRSWMkCzvgjEe3n9xV8oYywvM8at9yRqyaZVz6TYYhX98VjsUk +xpub = xpub6BgBgsespWvERF3LHQu6CnqdvfEvtMcQjYrcRzx53QJjSxarj2afYWcLteoGVky7D3UKDP9QyrLprQ3VCECoY49yfdDEHGCtMMj92pReUsQ + +// Account 0, first receiving address = m/86'/0'/0'/0/0 +xprv = xprvA449goEeU9okwCzzZaxiy475EQGQzBkc65su82nXEvcwzfSskb2hAt2WymrjyRL6kpbVTGL3cKtp9herYXSjjQ1j4stsXXiRF7kXkCacK3T +xpub = xpub6H3W6JmYJXN49h5TfcVjLC3onS6uPeUTTJoVvRC8oG9vsTn2J8LwigLzq5tHbrwAzH9DGo6ThGUdWsqce8dGfwHVBxSbixjDADGGdzF7t2B +internal_key = cc8a4bc64d897bddc5fbc2f670f7a8ba0b386779106cf1223c6fc5d7cd6fc115 +output_key = a60869f0dbcf1dc659c9cecbaf8050135ea9e8cdc487053f1dc6880949dc684c +scriptPubKey = 5120a60869f0dbcf1dc659c9cecbaf8050135ea9e8cdc487053f1dc6880949dc684c +address = bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr + +// Account 0, second receiving address = m/86'/0'/0'/0/1 +xprv = xprvA449goEeU9okyiF1LmKiDaTgeXvmh87DVyRd35VPbsSop8n8uALpbtrUhUXByPFKK7C2yuqrB1FrhiDkEMC4RGmA5KTwsE1aB5jRu9zHsuQ +xpub = xpub6H3W6JmYJXN4CCKUSnriaiQRCZmG6aq4sCMDqTu1ACyngw7HShf59hAxYjXgKDuuHThVEUzdHrc3aXCr9kfvQvZPit5dnD3K9xVRBzjK3rX +internal_key = 83dfe85a3151d2517290da461fe2815591ef69f2b18a2ce63f01697a8b313145 +output_key = a82f29944d65b86ae6b5e5cc75e294ead6c59391a1edc5e016e3498c67fc7bbb +scriptPubKey = 5120a82f29944d65b86ae6b5e5cc75e294ead6c59391a1edc5e016e3498c67fc7bbb +address = bc1p4qhjn9zdvkux4e44uhx8tc55attvtyu358kutcqkudyccelu0was9fqzwh + +// Account 0, first change address = m/86'/0'/0'/1/0 +xprv = xprvA3Ln3Gt3aphvUgzgEDT8vE2cYqb4PjFfpmbiFKphxLg1FjXQpkAk5M1ZKDY15bmCAHA35jTiawbFuwGtbDZogKF1WfjwxML4gK7WfYW5JRP +xpub = xpub6GL8SnQwRCGDhB59LEz9HMyM6sRYoByXBzXK3iEKWgCz8XrZNHUzd9L3AUBELW5NzA7dEFvMas1F84TuPH3xqdUA5tumaGWFgihJzWytXe3 +internal_key = 399f1b2f4393f29a18c937859c5dd8a77350103157eb880f02e8c08214277cef +output_key = 882d74e5d0572d5a816cef0041a96b6c1de832f6f9676d9605c44d5e9a97d3dc +scriptPubKey = 5120882d74e5d0572d5a816cef0041a96b6c1de832f6f9676d9605c44d5e9a97d3dc +address = bc1p3qkhfews2uk44qtvauqyr2ttdsw7svhkl9nkm9s9c3x4ax5h60wqwruhk7 +</pre> + +==Reference== + +* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] +* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] +* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] +* [[bip-0049.mediawiki|BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts]] +* [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based accounts]] +* [[bip-0341.mediawiki|BIP341 - Taproot: SegWit version 1 spending rules]] diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki index 1f77c8e..936f2ca 100644 --- a/bip-0088.mediawiki +++ b/bip-0088.mediawiki @@ -223,7 +223,11 @@ Its representation after parsing can be (using Python syntax, ignoring full/part Its representation after parsing can be: [[(0, 2), (33, 33), (123, 123)], [(0, 2147483647)]] -<code>*h/0</code> specifies a partial template that matches any hardened index followed by any non-hardened index +<code>*h/0</code> specifies a partial template that matches any hardened index followed by non-hardened index 0 Its representation after parsing can be: [[(2147483648, 4294967295)], [(0, 0)]] + +==Acknowledgements== + +Special thanks to Peter D. Gray, Dr. Maxim Orlovsky, Robert Spigler and others for their feedback on the specification, and to Janine (github:@Enegnei) for the help in preparing the draft. diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki index 19f92f2..3e7b0d8 100644 --- a/bip-0155.mediawiki +++ b/bip-0155.mediawiki @@ -131,7 +131,7 @@ See the appendices for the address encodings to be used for the various networks ==Signaling support and compatibility== -Introduce a new message type <code>sendaddrv2</code>. Sending such a message indicates that a node can understand and prefers to receive <code>addrv2</code> messages instead of <code>addr</code> messages. I.e. "Send me addrv2". +Introduce a new message type <code>sendaddrv2</code>. Sending such a message indicates that a node can understand and prefers to receive <code>addrv2</code> messages instead of <code>addr</code> messages. I.e. "Send me addrv2". Sending or not sending this message does not imply any preference with respect to receiving unrequested address messages. The <code>sendaddrv2</code> message MUST only be sent in response to the <code>version</code> message from a peer and prior to sending the <code>verack</code> message. diff --git a/bip-0173.mediawiki b/bip-0173.mediawiki index c3ee060..1fdd8be 100644 --- a/bip-0173.mediawiki +++ b/bip-0173.mediawiki @@ -208,7 +208,7 @@ be of the same length as the mainnet counterpart (to simplify implementations' assumptions about lengths), but still be visually distinct.</ref> for testnet. * The data-part values: -** 1 byte: the witness version +** 1 character (representing 5 bits of data): the witness version ** A conversion of the 2-to-40-byte witness program (as defined by [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) to base32: *** Start with the bits of the witness program, most significant bit per byte first. *** Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed. diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 9434ce6..f3de964 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -65,7 +65,7 @@ be used as a separator and allow for easier unserializer implementation.</ref>. Where: ;<tt><keytype></tt> -: A compact size unsigned integer representing the type. This compact size unsigned integer must be minimally encoded, i.e. if the value can be represented using one byte, it must be represented as one byte. This must be unique within a specific <tt><map></tt>. +: A compact size unsigned integer representing the type. This compact size unsigned integer must be minimally encoded, i.e. if the value can be represented using one byte, it must be represented as one byte. There can be multiple entries with the same <tt><keytype></tt> within a specific <tt><map></tt>, but the <tt><key></tt> must be unique. ;<tt><keylen></tt> : The compact size unsigned integer containing the combined length of <tt><keytype></tt> and <tt><keydata></tt> ;<tt><valuelen></tt> @@ -501,7 +501,7 @@ determine which outputs are change outputs and verify that the change is returni | [[bip-psb2.mediawiki|psbt2]] |- | Output Script -| <tt>PSBT_OUT_SCRIPT = 0x03</tt> +| <tt>PSBT_OUT_SCRIPT = 0x04</tt> | None | No key data | <tt><script></tt> @@ -544,7 +544,7 @@ values are valid, then it does not matter which is chosen as either way the tran ===Proprietary Use Type=== -For all global, per-input, and per-output maps, the types <tt>0xFC</tt> is reserved for proprietary use. +For all global, per-input, and per-output maps, the type <tt>0xFC</tt> is reserved for proprietary use. The proprietary use type requires keys that follow the type with a compact size unsigned integer representing the length of the string identifer, followed by the string identifier, then a subtype, and finally any key data. The identifier can be any variable length string that software can use to identify whether the particular data in the proprietary type can be used by it. @@ -554,7 +554,7 @@ The subtype is defined by the proprietary type user and can mean whatever they w The subtype must also be a compact size unsigned integer in the same form as the normal types. The key data and value data are defined by the proprietary type user. -The proprietary use types is for private use by individuals and organizations who wish to use PSBT in their processes. +The proprietary use type is for private use by individuals and organizations who wish to use PSBT in their processes. It is useful when there are additional data that they need attached to a PSBT but such data are not useful or available for the general public. The proprietary use type is not to be used by any public specification and there is no expectation that any publicly available software be able to understand any specific meanings of it and the subtypes. This type must be used for internal processes only. @@ -727,7 +727,7 @@ If an updater is updating a PSBT and needs to add a field that is only available ===Procedure For New Fields=== New fields should first be proposed on the bitcoin-dev mailing list. -If a field requires significatn description as to its usage, it should be accompanied by a separate BIP. +If a field requires significant description as to its usage, it should be accompanied by a separate BIP. The field must be added to the field listing tables in the Specification section. ===Procedure For New Versions=== diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index 586bb39..5e47bfc 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -173,7 +173,7 @@ First, we define <code>taproot_tweak_pubkey</code> for 32-byte [[bip-0340.mediaw The function returns a bit indicating the tweaked public key's Y coordinate as well as the public key byte array. The parity bit will be required for spending the output with a script path. In order to allow spending with the key path, we define <code>taproot_tweak_seckey</code> to compute the secret key for a tweaked public key. -For any byte string <code>h</code> it holds that <code>taproot_tweak_pubkey(pubkey_gen(seckey), h)[0] == pubkey_gen(taproot_tweak_seckey(seckey, h))</code>. +For any byte string <code>h</code> it holds that <code>taproot_tweak_pubkey(pubkey_gen(seckey), h)[1] == pubkey_gen(taproot_tweak_seckey(seckey, h))</code>. <source lang="python"> def taproot_tweak_pubkey(pubkey, h): @@ -219,7 +219,7 @@ def taproot_output_script(internal_pubkey, script_tree): h = bytes() else: _, h = taproot_tree_helper(script_tree) - output_pubkey, _ = taproot_tweak_pubkey(internal_pubkey, h) + _, output_pubkey = taproot_tweak_pubkey(internal_pubkey, h) return bytes([0x51, 0x20]) + output_pubkey </source> @@ -336,7 +336,7 @@ Non-upgraded nodes, however, will consider all SegWit version 1 witness programs They are strongly encouraged to upgrade in order to fully validate the new programs. Non-upgraded wallets can receive and send bitcoin from non-upgraded and upgraded wallets using SegWit version 0 programs, traditional pay-to-pubkey-hash, etc. -Depending on the implementation non-upgraded wallets may be able to send to Segwit version 1 programs if they support sending to [[bip-0173.mediawiki|BIP173]] Bech32 addresses. +Depending on the implementation non-upgraded wallets may be able to send to Segwit version 1 programs if they support sending to [[bip-0350.mediawiki|BIP350]] Bech32m addresses. == Acknowledgements == diff --git a/bip-0370.mediawiki b/bip-0370.mediawiki index 8dd557a..d906a40 100644 --- a/bip-0370.mediawiki +++ b/bip-0370.mediawiki @@ -197,7 +197,7 @@ The new per-output types for PSBT Version 2 are defined as follows: | 2 |- | Output Script -| <tt>PSBT_OUT_SCRIPT = 0x03</tt> +| <tt>PSBT_OUT_SCRIPT = 0x04</tt> | None | No key data | <tt><script></tt> |