diff --git a/.github/workflows/github-action-checks.yml b/.github/workflows/github-action-checks.yml new file mode 100644 index 00000000..8a7d2ac8 --- /dev/null +++ b/.github/workflows/github-action-checks.yml @@ -0,0 +1,22 @@ +name: GitHub Actions Check +run-name: ${{ github.actor }} Checks 🚀 +on: [push, pull_request] +jobs: + Link-Format-Checks: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + - run: scripts/link-format-chk.sh + Build-Table-Checks: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + - run: scripts/buildtable.pl >/tmp/table.mediawiki || exit 1 + Diff-Checks: + name: "Diff Checks (fails until number assignment)" + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + with: + fetch-depth: 2 + - run: scripts/diffcheck.sh diff --git a/.gitignore b/.gitignore new file mode 100644 index 00000000..d939d2a5 --- /dev/null +++ b/.gitignore @@ -0,0 +1,6 @@ +bip-0174/coinjoin-workflow.aux +bip-0174/coinjoin-workflow.log +bip-0174/coinjoin-workflow.pdf +bip-0174/multisig-workflow.aux +bip-0174/multisig-workflow.log +bip-0174/multisig-workflow.pdf diff --git a/.travis.yml b/.travis.yml deleted file mode 100644 index 70d339ae..00000000 --- a/.travis.yml +++ /dev/null @@ -1,7 +0,0 @@ -os: linux -language: generic -script: - - scripts/link-format-chk.sh - - scripts/buildtable.pl >/tmp/table.mediawiki || exit 1 - - diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/after.diff || true - - if git checkout HEAD^ && scripts/buildtable.pl >/tmp/table.mediawiki 2>/dev/null; then diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/before.diff || true; newdiff=$(diff -s /tmp/before.diff /tmp/after.diff -u | grep '^+'); if [ -n "$newdiff" ]; then echo "$newdiff"; exit 1; fi; else echo 'Cannot build previous commit table for comparison'; fi diff --git a/README.mediawiki b/README.mediawiki index f84fcf0d..1ad8aaf8 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1,4 +1,4 @@ -People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (do not assign a number - read BIP 2 for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here. +People wishing to submit BIPs, first should propose their idea or document to the [https://groups.google.com/g/bitcoindev bitcoindev@googlegroups.com] mailing list (do not assign a number - read BIP 2 for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here. We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred. @@ -235,15 +235,15 @@ Those proposing changes should consider that ultimately consent may rest with th | Applications | Purpose Field for Deterministic Wallets | Marek Palatinus, Pavol Rusnak -| Informational +| Standard | Final -|- style="background-color: #ffffcf" +|- style="background-color: #cfffcf" | [[bip-0044.mediawiki|44]] | Applications | Multi-Account Hierarchy for Deterministic Wallets | Marek Palatinus, Pavol Rusnak | Standard -| Proposed +| Final |- style="background-color: #ffffcf" | [[bip-0045.mediawiki|45]] | Applications @@ -258,13 +258,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Chris Belcher, Thebora Kompanioni | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0047.mediawiki|47]] | Applications | Reusable Payment Codes for Hierarchical Deterministic Wallets | Justus Ranvier | Informational -| Draft +| Final |- style="background-color: #ffffcf" | [[bip-0048.mediawiki|48]] | Applications @@ -277,7 +277,7 @@ Those proposing changes should consider that ultimately consent may rest with th | Applications | Derivation scheme for P2WPKH-nested-in-P2SH based accounts | Daniel Weigl -| Informational +| Standard | Final |- style="background-color: #cfffcf" | [[bip-0050.mediawiki|50]] @@ -441,13 +441,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Eric Lombrozo | Standard | Rejected -|- +|- style="background-color: #cfffcf" | [[bip-0084.mediawiki|84]] | Applications | Derivation scheme for P2WPKH based accounts | Pavol Rusnak -| Informational -| Draft +| Standard +| Final |- | [[bip-0085.mediawiki|85]] | Applications @@ -459,7 +459,7 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0086.mediawiki|86]] | Applications | Key Derivation for Single Key P2TR Outputs -| Andrew Chow +| Ava Chow | Standard | Draft |- style="background-color: #ffffcf" @@ -491,6 +491,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Final |- +| [[bip-0093.mediawiki|93]] +| Applications +| codex32: Checksummed SSSS-aware BIP32 seeds +| Leon Olsson Curr, Pearlwort Sneed, Andrew Poelstra +| Informational +| Draft +|- | [[bip-0098.mediawiki|98]] | Consensus (soft fork) | Fast Merkle Trees @@ -627,7 +634,7 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0119.mediawiki|119]] | Consensus (soft fork) | CHECKTEMPLATEVERIFY -| Jeremy Rubin +| Jeremy Rubin, James O'Beirne | Standard | Draft |- style="background-color: #ffcfcf" @@ -714,13 +721,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Andy Chase | Process | Withdrawn -|- +|- style="background-color: #cfffcf" | [[bip-0133.mediawiki|133]] | Peer Services | feefilter message | Alex Morcos | Standard -| Draft +| Final |- style="background-color: #ffcfcf" | [[bip-0134.mediawiki|134]] | Consensus (hard fork) @@ -832,7 +839,7 @@ Those proposing changes should consider that ultimately consent may rest with th | Peer-to-Peer Communication Encryption | Jonas Schnelli | Standard -| Withdrawn +| Replaced |- style="background-color: #cfffcf" | [[bip-0152.mediawiki|152]] | Peer Services @@ -900,7 +907,7 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0174.mediawiki|174]] | Applications | Partially Signed Bitcoin Transaction Format -| Andrew Chow +| Ava Chow | Standard | Final |- style="background-color: #ffcfcf" @@ -928,7 +935,7 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0179.mediawiki|179]] | | Name for payment recipient identifiers -| Emil Engler, MarcoFalke, Luke Dashjr +| Emil Engler, Luke Dashjr | Informational | Draft |- style="background-color: #ffcfcf" @@ -987,6 +994,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Karl-Johan Alm | Standard | Draft +|- +| [[bip-0324.mediawiki|324]] +| Peer Services +| Version 2 P2P Encrypted Transport Protocol +| Dhruv Mehta, Tim Ruffing, Jonas Schnelli, Pieter Wuille +| Standard +| Draft |- style="background-color: #ffffcf" | [[bip-0325.mediawiki|325]] | Applications @@ -997,11 +1011,25 @@ Those proposing changes should consider that ultimately consent may rest with th |- | [[bip-0326.mediawiki|326]] | Applications -| Anti-fee-sniping protection in taproot transactions +| Anti-fee-sniping in taproot transactions | Chris Belcher | Informational | Draft |- +| [[bip-0327.mediawiki|327]] +| +| MuSig2 for BIP340-compatible Multi-Signatures +| Jonas Nick, Tim Ruffing, Elliott Jin +| Informational +| Draft +|- +| [[bip-0329.mediawiki|329]] +| Applications +| Wallet Labels Export Format +| Craig Raw +| Informational +| Draft +|- | [[bip-0330.mediawiki|330]] | Peer Services | Transaction announcements reconciliation @@ -1009,6 +1037,20 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0331.mediawiki|331]] +| Peer Services +| Ancestor Package Relay +| Gloria Zhao +| Standard +| Draft +|- +| [[bip-0337.mediawiki|337]] +| API/RPC +| Compressed Transactions +| Tom Briar +| Standard +| Draft +|- | [[bip-0338.mediawiki|338]] | Peer Services | Disable transaction relay message @@ -1022,102 +1064,165 @@ Those proposing changes should consider that ultimately consent may rest with th | Suhas Daftuar | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0340.mediawiki|340]] | | Schnorr Signatures for secp256k1 | Pieter Wuille, Jonas Nick, Tim Ruffing | Standard -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0341.mediawiki|341]] | Consensus (soft fork) | Taproot: SegWit version 1 spending rules | Pieter Wuille, Jonas Nick, Anthony Towns | Standard -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0342.mediawiki|342]] | Consensus (soft fork) | Validation of Taproot Scripts | Pieter Wuille, Jonas Nick, Anthony Towns | Standard -| Draft -|- style="background-color: #ffffcf" +| Final +|- style="background-color: #cfffcf" | [[bip-0343.mediawiki|343]] | Consensus (soft fork) | Mandatory activation of taproot deployment | Shinobius, Michael Folkson | Standard -| Proposed +| Final |- +| [[bip-0345.mediawiki|345]] +| Consensus (soft fork) +| OP_VAULT +| James O'Beirne, Greg Sanders, Anthony Towns +| Standard +| Draft +|- +| [[bip-0347.mediawiki|347]] +| Consensus (soft fork) +| OP_CAT in Tapscript +| Ethan Heilman, Armin Sabouri +| Standard +| Draft +|- style="background-color: #cfffcf" | [[bip-0350.mediawiki|350]] | Applications | Bech32m format for v1+ witness addresses | Pieter Wuille | Standard +| Final +|- +| [[bip-0351.mediawiki|351]] +| Applications +| Private Payments +| Alfred Hodler, Clark Moody +| Informational | Draft +|- style="background-color: #ffffcf" +| [[bip-0352.mediawiki|352]] +| Applications +| Silent Payments +| josibake, Ruben Somsen +| Standard +| Proposed |- | [[bip-0370.mediawiki|370]] | Applications | PSBT Version 2 -| Andrew Chow +| Ava Chow | Standard | Draft |- | [[bip-0371.mediawiki|371]] | Applications | Taproot Fields for PSBT -| Andrew Chow +| Ava Chow +| Standard +| Draft +|- +| [[bip-0372.mediawiki|372]] +| Applications +| Pay-to-contract tweak fields for PSBT +| Maxim Orlovsky | Standard | Draft |- | [[bip-0380.mediawiki|380]] | Applications | Output Script Descriptors General Operation -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow | Informational | Draft |- | [[bip-0381.mediawiki|381]] | Applications | Non-Segwit Output Script Descriptors -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow | Informational | Draft |- | [[bip-0382.mediawiki|382]] | Applications | Segwit Output Script Descriptors -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow | Informational | Draft |- | [[bip-0383.mediawiki|383]] | Applications | Multisig Output Script Descriptors -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow | Informational | Draft |- | [[bip-0384.mediawiki|384]] | Applications | combo() Output Script Descriptors -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow | Informational | Draft |- | [[bip-0385.mediawiki|385]] | Applications | raw() and addr() Output Script Descriptors -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow | Informational | Draft |- | [[bip-0386.mediawiki|386]] | Applications | tr() Output Script Descriptors -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow +| Informational +| Draft +|- +| [[bip-0387.mediawiki|387]] +| Applications +| Tapscript Multisig Output Script Descriptors +| Pieter Wuille, Ava Chow +| Informational +| Draft +|- style="background-color: #ffffcf" +| [[bip-0388.mediawiki|388]] +| Applications +| Wallet Policies for Descriptor Wallets +| Salvatore Ingala +| Standard +| Proposed +|- +| [[bip-0389.mediawiki|389]] +| Applications +| Multipath Descriptor Key Expressions +| Ava Chow +| Informational +| Draft +|- +| [[bip-0431.mediawiki|431]] +| Applications +| Topology Restrictions for Pinning +| Gloria Zhao | Informational | Draft |} diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki index c6eb950f..4bdc23bd 100644 --- a/bip-0002.mediawiki +++ b/bip-0002.mediawiki @@ -32,13 +32,13 @@ The BIP process begins with a new idea for Bitcoin. Each potential BIP must have Small enhancements or patches to a particular piece of software often don't require standardisation between multiple projects; these don't need a BIP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker. Additionally, many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression. -After investigating past work, the best way to proceed is by posting about the new idea to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Bitcoin development mailing list]. +After investigating past work, the best way to proceed is by posting about the new idea to the [https://groups.google.com/g/bitcoindev Bitcoin development mailing list]. Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. -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]. +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://groups.google.com/g/bitcoindev 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 an editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers). @@ -67,8 +67,12 @@ If you are interested in assuming ownership of a BIP, send a message asking to t The current BIP editors are: +* Bryan Bishop ([[mailto:kanzure@gmail.com|kanzure@gmail.com]]) +* Jon Atack ([[mailto:jon@atack.com|jon@atack.com]]) * Luke Dashjr ([[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]]) -* Kalle Alm ([[mailto:karljohan-alm@garage.co.jp|karljohan-alm@garage.co.jp]]) +* Mark "Murch" Erhardt ([[mailto:murch@murch.one|murch@murch.one]]) +* Olaoluwa Osuntokun ([[mailto:laolu32@gmail.com|laolu32@gmail.com]]) +* Ruben Somsen ([[mailto:rsomsen@gmail.com|rsomsen@gmail.com]]) ===BIP Editor Responsibilities & Workflow=== @@ -98,11 +102,13 @@ The BIP editor will: The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and update BIP headers as appropriate. +BIP editors may also, at their option, unilaterally make and merge strictly-editorial changes to BIPs, such as correcting misspellings, fixing broken links, etc. + ==BIP format and structure== ===Specification=== -BIPs should be written in mediawiki format. +BIPs should be written in mediawiki or markdown format. Each BIP should have the following parts: @@ -409,7 +415,6 @@ Why is Public Domain no longer acceptable for new BIPs? * Non-image auxiliary files are permitted in the bip-XXXX subdirectory. * Email addresses are now required for authors. * The Post-History header may be provided as a link instead of a simple date. -* Markdown format is no longer permitted for BIPs. * The Resolution header has been dropped, as it is not applicable to a decentralised system where no authority exists to make final decisions. ==See Also== diff --git a/bip-0009/states.gv b/bip-0009/states.gv new file mode 100644 index 00000000..9dc95c56 --- /dev/null +++ b/bip-0009/states.gv @@ -0,0 +1,22 @@ +/* There are many ways to compile this, but one of them is: + * + * $ dot -Tpng states.gv -o states.png + */ +digraph { + /* States. */ + DEFINED; FAILED; STARTED; LOCKED_IN; ACTIVE; + + /* Relationships between states, labeled where applicable. */ + DEFINED -> DEFINED; + DEFINED -> FAILED [label = "timeout ≤ MTP"]; + DEFINED -> STARTED [label = "starttime ≤ MTP < timeout"]; + FAILED -> FAILED; + STARTED -> STARTED; + STARTED -> FAILED [label = "timeout ≤ MTP"]; + STARTED -> LOCKED_IN [label = "(MTP < timeout) AND (threshold reached)"]; + LOCKED_IN -> ACTIVE [label = "Always"]; + ACTIVE -> ACTIVE; + + /* Visualization hack to unclutter output. */ + nodesep = 1.2; +} diff --git a/bip-0009/states.png b/bip-0009/states.png index 09312a1c..2048ed87 100644 Binary files a/bip-0009/states.png and b/bip-0009/states.png differ diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki index 42071f3a..289e3b04 100644 --- a/bip-0010.mediawiki +++ b/bip-0010.mediawiki @@ -93,10 +93,10 @@ The following is an example TxDP from Armory, produced while running on the test In this transaction, there are two inputs, one of 150 BTC and the other of 12 BTC. This transaction combines 162 BTC to create two outputs, one of 160 BTC, one 1.9995 BTC, and a tx fee of 0.0005. In this TxDP, both inputs have been signed, and thus could broadcast immediately. -The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpretted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program to parse the core elements of the TxDP. +The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpreted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program to parse the core elements of the TxDP. A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it is not the recommended method for combining TxDPs. == Reference Implementation == -This proposal was implemented and tested in the older versions of ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction). Implementation can be found in https://github.com/etotheipi/BitcoinArmory/blob/v0.91-beta/armoryengine/Transaction.py under the class PyTxDistProposal. However, as of verion 0.92 released in July 2014, Armory no longer uses this proposal for offline wallet transaction signing and has moved on to a new format. +This proposal was implemented and tested in the older versions of ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction). Implementation can be found in https://github.com/etotheipi/BitcoinArmory/blob/v0.91-beta/armoryengine/Transaction.py under the class PyTxDistProposal. However, as of version 0.92 released in July 2014, Armory no longer uses this proposal for offline wallet transaction signing and has moved on to a new format. diff --git a/bip-0011.mediawiki b/bip-0011.mediawiki index 8375f553..7e9e1f68 100644 --- a/bip-0011.mediawiki +++ b/bip-0011.mediawiki @@ -54,7 +54,7 @@ A weaker argument is OP_CHECKMULTISIG should not be used because it pops one too OP_CHECKMULTISIG is already supported by old clients and miners as a non-standard transaction type. -https://github.com/gavinandresen/bitcoin-git/tree/op_eval +https://github.com/gavinandresen/bitcoin-git/tree/77f21f1583deb89bf3fffe80fe9b181fedb1dd60 == Post History == diff --git a/bip-0012.mediawiki b/bip-0012.mediawiki index 9cb3795c..bd3d88c9 100644 --- a/bip-0012.mediawiki +++ b/bip-0012.mediawiki @@ -43,11 +43,11 @@ OP_EVAL allows the receiver of bitcoins to specify how they can be spent when th If ''serialized script'' is a large or complicated multi-signature script, then the burden of paying for it (in increased transaction fees due to more signature operations or transaction size) is shifted from the sender to the receiver. -The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilties. +The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilities. That same argument can be applied to the existing Bitcoin 'scripting' system; scriptPubKeys are transmit as data across the network and are then interpreted by every bitcoin implementation. OP_EVAL just moves the data that will be interpreted. It is debatable whether or not the entire idea of putting a little interpreted expression evaluation language at the core of Bitcoin was brilliant or stupid, but the existence of OP_EVAL does not make the expression language less secure. -There is a 1-confirmation attack on old clients that interepret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is: +There is a 1-confirmation attack on old clients that interpret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is: # Attacker creates an OP_EVAL transaction that is valid as seen by old clients, but invalid for new clients. # Attacker also creates a standard transaction that spends the OP_EVAL transaction, and pays the victim. @@ -75,7 +75,7 @@ Example of a transaction that must fail for both old and new miners/clients: ==Reference Implementation== -https://github.com/gavinandresen/bitcoin-git/tree/op_eval +https://github.com/gavinandresen/bitcoin-git/tree/77f21f1583deb89bf3fffe80fe9b181fedb1dd60 ==See Also== diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki index abd575ce..fded4203 100644 --- a/bip-0014.mediawiki +++ b/bip-0014.mediawiki @@ -28,7 +28,7 @@ Version bumping can also introduce incompatibilities and fracture the network. I By using a protocol version, we set all implementations on the network to a common standard. Everybody is able to agree within their confines what is protocol and what is implementation-dependent. A user agent string is offered as a 'vanity-plate' for clients to distinguish themselves in the network. -Separation of the network protocol from the implemention, and forming development of said protocol by means of a mutual consensus among participants, has the democratic disadvantage when agreement is hard to reach on contentious issues. To mitigate this issue, strong communication channels and fast release schedules are needed, and are outside the scope of this document (concerning a process-BIP type). +Separation of the network protocol from the implementation, and forming development of said protocol by means of a mutual consensus among participants, has the democratic disadvantage when agreement is hard to reach on contentious issues. To mitigate this issue, strong communication channels and fast release schedules are needed, and are outside the scope of this document (concerning a process-BIP type). User agents provide extra tracking information that is useful for keeping tabs on network data such as client implementations used or common architectures/operating-systems. In the rare case they may even provide an emergency method of shunning faulty clients that threaten network health- although this is strongly unrecommended and extremely bad form. The user agent does not provide a method for clients to work around and behave differently to different implementations, as this will lead to protocol fracturing. diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki index a6e4426a..1e9a9bc4 100644 --- a/bip-0015.mediawiki +++ b/bip-0015.mediawiki @@ -208,7 +208,7 @@ NameResolutionService::~NameResolutionService() void NameResolutionService::ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain) { - // split address at @ furthrest to the right + // split address at @ furthest to the right size_t nPosAtsym = strHandle.rfind('@'); strNickname = strHandle.substr(0, nPosAtsym); strDomain = strHandle.substr(nPosAtsym + 1, strHandle.size()); @@ -348,7 +348,7 @@ By using DNS lookups, the MITM problem with IP transactions could be mitigated b === Namecoin ID === -This proposal uses the Namecoin blockchain to associate an alias with a bitcoin address. Bitcoin queries a namecoin node. This retreives the structured data containing the bitcoin address(es) associated with this alias. +This proposal uses the Namecoin blockchain to associate an alias with a bitcoin address. Bitcoin queries a namecoin node. This retrieves the structured data containing the bitcoin address(es) associated with this alias. Using a decentralised domain name system like Namecoin, means no external server or entity needs to be trusted unlike the other proposals listed here. This indicates a system with the advantage of having a high availability and ease of entry (no restrictions for users to create aliases). @@ -401,4 +401,4 @@ Any text can be put into the brackets, allowing merchants to adapt it to all the New features can be added later to support uncovered cases. -See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more informations. +See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more information. diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki index 0fba9bcf..9fa48232 100644 --- a/bip-0021.mediawiki +++ b/bip-0021.mediawiki @@ -37,7 +37,7 @@ Elements of the query component may contain characters outside the valid range. === ABNF grammar === -(See also [[#Simpler syntax|a simpler representation of syntax]]) +(See also [[#simpler-syntax|a simpler representation of syntax]]) bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ] bitcoinaddress = *base58 @@ -120,11 +120,6 @@ Some future version that has variables which are (currently) not understood but Characters must be URI encoded properly. -== Reference Implementations == -=== Bitcoin clients === -* Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858. +== Reference Implementation == -=== Libraries === -* Javascript - https://github.com/bitcoinjs/bip21 -* Java - https://github.com/SandroMachado/BitcoinPaymentURI -* Swift - https://github.com/SandroMachado/BitcoinPaymentURISwift +Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858. diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index b441658e..0e6df240 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -25,7 +25,7 @@ This document describes hierarchical deterministic wallets (or "HD Wallets"): wa The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients. Although the wallets described here have many features, not all are required by supporting clients. -The specification consists of two parts. In a first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree. +The specification consists of two parts. In the first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree. ==Copyright== @@ -37,7 +37,7 @@ The Bitcoin reference client uses randomly generated keys. In order to avoid the Deterministic wallets do not require such frequent backups, and elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys. This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds). -However, deterministic wallets typically consist of a single "chain" of keypairs. The fact that there is only one chain means that sharing a wallet happens on an all-or-nothing basis. However, in some cases one only wants some (public) keys to be shared and recoverable. In the example of a webshop, the webserver does not need access to all public keys of the merchant's wallet; only to those addresses which are used to receive customer's payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root. +However, deterministic wallets typically consist of a single "chain" of keypairs. The fact that there is only one chain means that sharing a wallet happens on an all-or-nothing basis. However, in some cases one only wants some (public) keys to be shared and recoverable. In the example of a webshop, the webserver does not need access to all public keys of the merchant's wallet; only to those addresses which are used to receive customers' payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root. ==Specification: Key derivation== @@ -104,7 +104,7 @@ The function N((k, c)) → (K, c) computes the extended public key correspond To compute the public child key of a parent private key: * N(CKDpriv((kpar, cpar), i)) (works always). * CKDpub(N(kpar, cpar), i) (works only for non-hardened child keys). -The fact that they are equivalent is what makes non-hardened keys useful (one can derive child public keys of a given parent key without knowing any private key), and also what distinguishes them from hardened keys. The reason for not always using non-hardened keys (which are more useful) is security; see further for more information. +The fact that they are equivalent is what makes non-hardened keys useful (one can derive child public keys of a given parent key without knowing any private key), and also what distinguishes them from hardened keys. The reason for not always using non-hardened keys (which are more useful) is security; see further below for more information. ====Public parent key → private child key==== @@ -184,7 +184,7 @@ When a business has several independent offices, they can all use wallets derive ====Recurrent business-to-business transactions: N(m/iH/0)==== In case two business partners often transfer money, one can use the extended public key for the external chain of a specific account (M/i h/0) as a sort of "super address", allowing frequent transactions that cannot (easily) be associated, but without needing to request a new address for each payment. -Such a mechanism could also be used by mining pool operators as variable payout address. +Such a mechanism could also be used by mining pool operators as a variable payout address. ====Unsecure money receiver: N(m/iH/0)==== @@ -212,7 +212,7 @@ Private and public keys must be kept safe as usual. Leaking a private key means Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys. One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. -It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts. +It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private keys never risks compromising the master or other accounts. ==Test Vectors== diff --git a/bip-0035.mediawiki b/bip-0035.mediawiki index 64edaf5d..eccd3815 100644 --- a/bip-0035.mediawiki +++ b/bip-0035.mediawiki @@ -16,7 +16,7 @@ Make a network node's transaction memory pool accessible via a new "mempool" mes ==Motivation== -Several use cases make it desireable to expose a network node's transaction memory pool: +Several use cases make it desirable to expose a network node's transaction memory pool: # SPV clients, wishing to obtain zero-confirmation transactions sent or received. # Miners, to avoid missing lucrative fees, downloading existing network transactions after a restart. # Remote network diagnostics. diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index 511b55ad..ab1a1583 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -36,10 +36,10 @@ Password and passphrase-protected private keys enable new practical use cases fo This proposal is hereby placed in the public domain. ==Rationale== -:'''''User story:''' As a Bitcoin user who uses paper wallets, I would like the ability to add encryption, so that my Bitcoin paper storage can be two factor: something I have plus something I know.'' -:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).'' -:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.'' -:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate. +:'' '''User story:''' As a Bitcoin user who uses paper wallets, I would like the ability to add encryption, so that my Bitcoin paper storage can be two factor: something I have plus something I know.'' +:'' '''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).'' +:'' '''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.'' +:'' '''User story:''' (EC-multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.'' ==Specification== This proposal makes use of the following functions and definitions: @@ -47,12 +47,12 @@ This proposal makes use of the following functions and definitions: *'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output. *'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash. *'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter. -*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve. -*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer. -*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem. +*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the secp256k1 elliptic curve. +*'''G, N''': Constants defined as part of the secp256k1 elliptic curve. G is an elliptic curve point, and N is a large positive integer. +*'''Base58Check''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem. ===Prefix=== -It is proposed that the resulting Base58Check-encoded string start with a '6'. The number '6' is intended to represent, from the perspective of the user, "a private key that needs something else to be usable" - an umbrella definition that could be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key. +It is proposed that the resulting Base58Check-encoded string start with a '6'. The number '6' is intended to represent, from the perspective of the user, "a private key that needs something else to be usable" - an umbrella definition that could be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in Wallet Import Format which denotes an unencrypted private key. It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed. @@ -170,7 +170,7 @@ To recalculate the address: # Derive ''passfactor'' using scrypt with ''ownerentropy'' and the user's passphrase and use it to recompute ''passpoint'' # Derive decryption key for ''pointb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownerentropy'' # Decrypt ''encryptedpointb'' to yield ''pointb'' -# ECMultiply ''pointb'' by ''passfactor''. Use the resulting EC point as a public key and hash it into ''address'' using either compressed or uncompressed public key methodology as specifid in ''flagbyte''. +# ECMultiply ''pointb'' by ''passfactor''. Use the resulting EC point as a public key and hash it into ''address'' using either compressed or uncompressed public key methodology as specified in ''flagbyte''. =====Decryption===== # Collect encrypted private key and passphrase from user. @@ -184,7 +184,7 @@ To recalculate the address: # Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect. ==Backwards compatibility== -Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities. +Backwards compatibility is minimally applicable since this is a new standard that at most extends Wallet Import Format. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and Wallet Import Format); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities. ==Suggestions for implementers of proposal with alt-chains== If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain. @@ -209,14 +209,10 @@ The preliminary values of 16384, 8, and 8 are hoped to offer the following prope ==Reference implementation== Added to alpha version of Casascius Bitcoin Address Utility for Windows available at: -* via https: https://casascius.com/btcaddress-alpha.zip -* at github: https://github.com/casascius/Bitcoin-Address-Utility +* https://github.com/casascius/Bitcoin-Address-Utility Click "Tools" then "PPEC Keygen" (provisional name) -==Other implementations== -* Javascript - https://github.com/bitcoinjs/bip38 - ==Test vectors== ===No compression, no EC multiply=== diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 7b98a39d..51fe33d8 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -39,7 +39,7 @@ security is improved but the sentence length increases. We refer to the initial entropy length as ENT. The allowed size of ENT is 128-256 bits. First, an initial entropy of ENT bits is generated. A checksum is generated by -taking the first 
ENT / 32
bits of its SHA256 hash. This checksum is +taking the first ENT / 32 bits of its SHA256 hash. This checksum is appended to the end of the initial entropy. Next, these concatenated bits are split into groups of 11 bits, each encoding a number from 0-2047, serving as an index into a wordlist. Finally, we convert these numbers into words and @@ -138,62 +138,3 @@ Also see https://github.com/bip32JP/bip32JP.github.io/blob/master/test_JP_BIP39. Reference implementation including wordlists is available from http://github.com/trezor/python-mnemonic - -==Other Implementations== - -Go: -* https://github.com/tyler-smith/go-bip39 - -Python: -* https://github.com/meherett/python-hdwallet - -Elixir: -* https://github.com/aerosol/mnemo - -Objective-C: -* https://github.com/nybex/NYMnemonic - -Haskell: -* https://github.com/haskoin/haskoin - -.NET (Standard): -* https://www.nuget.org/packages/dotnetstandard-bip39/ - -.NET C# (PCL): -* https://github.com/Thashiznets/BIP39.NET - -.NET C# (PCL): -* https://github.com/NicolasDorier/NBitcoin - -JavaScript: -* https://github.com/bitpay/bitcore/tree/master/packages/bitcore-mnemonic -* https://github.com/bitcoinjs/bip39 (used by [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/hd-wallet.js#L121-L146|blockchain.info]]) - -Java: -* https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/crypto/MnemonicCode.java - -Ruby: -* https://github.com/sreekanthgs/bip_mnemonic - -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 -* https://github.com/pengpengliu/BIP39 -* https://github.com/matter-labs/web3swift/blob/develop/Sources/web3swift/KeystoreManager/BIP39.swift -* https://github.com/zcash-hackworks/MnemonicSwift - -C++: -* https://github.com/libbitcoin/libbitcoin-system/blob/master/include/bitcoin/system/wallet/mnemonic.hpp - -C (with Python/Java/Javascript bindings): -* https://github.com/ElementsProject/libwally-core - -Python: -* https://github.com/scgbckbone/btc-hd-wallet diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index f2c173c5..5acf87d1 100644 --- a/bip-0039/bip-0039-wordlists.md +++ b/bip-0039/bip-0039-wordlists.md @@ -53,7 +53,7 @@ Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch 7. No words in the plural (except invariable words like "univers", or same spelling than singular like "heureux"). 8. No female adjectives (except words with same spelling for male and female adjectives like "magique"). 9. No words with several senses AND different spelling in speaking like "verre-vert", unless a word has a meaning much more popular than another like "perle" and "pairle". -10. No very similar words with 1 letter of difference. +10. No very similar words with only 1 letter of difference. 11. No essentially reflexive verbs (unless a verb is also a noun like "souvenir"). 12. No words with "ô;â;ç;ê;œ;æ;î;ï;û;ù;à;ë;ÿ". 13. No words ending by "é;ée;è;et;ai;ait". @@ -93,12 +93,12 @@ Words chosen using the following rules: 1. Words are 4-8 letters long. 2. Words can be uniquely determined typing the first 4 letters. -3. Only words containing all letters without diacritical marks. (It was the hardest task, because in one third of all Czech letters has diacritical marks.) +3. Only words containing all letters without diacritical marks. (It was the hardest task, because one third of all Czech letters has diacritical marks.) 4. Only nouns, verbs and adverbs, no other word types. All words are in basic form. 5. No personal names or geographical names. 6. No very similar words with 1 letter of difference. -7. Words are sorting according English alphabet (Czech sorting has difference in "ch"). -8. No words already used in other language mnemonic sets (english, italian, french, spanish). Letters with diacritical marks from these sets are counted as analogous letters without diacritical marks. +7. Words are sorted according to English alphabet (Czech sorting has difference in "ch"). +8. No words already used in other language mnemonic sets (english, italian, french, spanish). Letters with diacritical marks from these sets are counted as analogous letters without diacritical marks. ### Portuguese @@ -109,9 +109,9 @@ Credits: @alegotardo @bitmover-studio @brenorb @kuthullu @ninjastic @sabotag3x @ 3. No complex verb forms. 4. No plural words, unless there's no singular form. 5. No words with double spelling. -6. No words with the exact sound of another word with different spelling. +6. No words with the exact sound as another word with different spelling. 7. No offensive words. 8. No words already used in other language mnemonic sets. 9. The words which have not the same spelling in Brazil and in Portugal are excluded. -10. No words that remind negative/sad/bad things. -11. No very similar words with 1 letter of difference. +10. No words that remind one of negative/sad/bad things. +11. No very similar words with only 1 letter of difference. diff --git a/bip-0042.mediawiki b/bip-0042.mediawiki index 223076f5..2c5de6df 100644 --- a/bip-0042.mediawiki +++ b/bip-0042.mediawiki @@ -15,7 +15,7 @@ Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillenium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years. -This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion Bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default. +This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default. To combat this, this document proposes a controversial change: making Bitcoin's monetary supply finite. diff --git a/bip-0043.mediawiki b/bip-0043.mediawiki index 32e02b1e..f07c94aa 100644 --- a/bip-0043.mediawiki +++ b/bip-0043.mediawiki @@ -7,7 +7,7 @@ Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0043 Status: Final - Type: Informational + Type: Standards Track Created: 2014-04-24 diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index 4ddd56b2..5db540c7 100644 --- a/bip-0044.mediawiki +++ b/bip-0044.mediawiki @@ -6,7 +6,7 @@ Pavol Rusnak Comments-Summary: Mixed review (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0044 - Status: Proposed + Status: Final Type: Standards Track Created: 2014-04-24 diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index af801f96..c44bea9d 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -1,7 +1,7 @@ RECENT CHANGES: +* (15 Feb 2021) Finalize specification +* (28 Sep 2017) Adjust text to match test vectors * (19 Apr 2016) Define version 2 payment codes -* (17 Apr 2016) Clarify usage of outpoints in notification transactions -* (18 Dec 2015) Update explanations to resolve FAQs 
   BIP: 47
@@ -10,11 +10,17 @@ RECENT CHANGES:
   Author: Justus Ranvier 
   Comments-Summary: Unanimously Discourage for implementation
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0047
-  Status: Draft
+  Status: Final
   Type: Informational
   Created: 2015-04-24
+==Status== + +This BIP can be considered final in terms of enabling compatibility with wallets that implement version 1 and version 2 reusable payment codes, however future developments of the reusable payment codes specification will not be distributed via the BIP process. + +The Open Bitcoin Privacy Project RFC repo should be consulted for specifications related to version 3 or higher payment codes: https://github.com/OpenBitcoinPrivacyProject/rfc + ==Abstract== This BIP defines a technique for creating a payment code which can be publicly advertised and associated with a real-life identity without creating the loss of security or privacy inherent to P2PKH address reuse. @@ -150,7 +156,7 @@ It is assumed that Alice can easily obtain Bob's payment code via a suitable met Prior to the first time Alice initiates a transaction to Bob, Alice MUST inform Bob of her payment code via the following procedure: -Note: this procedure is used if Bob uses a version 1 payment code (regardless of the the version of Alice's payment code). If Bob's payment code is not version 1, see the appropriate section in this specification. +Note: this procedure is used if Bob uses a version 1 payment code (regardless of the version of Alice's payment code). If Bob's payment code is not version 1, see the appropriate section in this specification. # Alice constructs a transaction which sends a small quantity of bitcoins to Bob's notification address (notification transaction) ## The inputs selected for this transaction MUST NOT be easily associated with Alice's notification address @@ -158,7 +164,7 @@ Note: this procedure is used if Bob uses a version 1 payment code (regardless of ## Alice selects the private key corresponding to the designated pubkey: 
a
## Alice selects the public key associated with Bob's notification address: 
B, where B = bG
## Alice calculates a secret point: 
S = aB
-## Alice calculates a 64 byte blinding factor: 
s = HMAC-SHA512(x, o)
+## Alice calculates a 64 byte blinding factor: 
s = HMAC-SHA512(o, x)
### "x" is the x value of the secret point ### "o" is the outpoint being spent by the designated input # Alice serializes her payment code in binary form. @@ -229,7 +235,7 @@ The following actions are recommended to reduce this risk: # Bob is watching for incoming payments on B' ever since he received the notification transaction from Alice. -## Bob calculates n shared secrets with Alice, using the 0th public key derived Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window. +## Bob calculates n shared secrets with Alice, using the 0th public key derived from Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window. ## Bob calculates the ephemeral deposit addresses using the same procedure as Alice: 
B' = B + sG
## Bob calculate the private key for each ephemeral address as: 
b' = b + s
@@ -269,7 +275,7 @@ Normal operation of a payment code-enabled wallet can be performed by an SPV cli Recovering a wallet from a seed, however, does require access to a fully-indexed blockchain. -The required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queriable blockchain explorer. +The required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queryable blockchain explorer. When querying a public blockchain explorer, wallets SHOULD connect to the explorer through Tor (or equivalent) and SHOULD avoid grouping queries in a manner that associates ephemeral addresses with each other. @@ -344,12 +350,12 @@ Version 2 payment codes behave identifically to version 1 payment codes, except ====Definitions==== -* Notification change output: the change output from a notification transaction which which resides in the sender's wallet, but can be automatically located by the intended recipient +* Notification change output: the change output from a notification transaction which resides in the sender's wallet, but can be automatically located by the intended recipient * Payment code identifier: a 33 byte representation of a payment code constructed by prepending 0x02 to the SHA256 hash of the binary serialization of the payment code ====Notification Transaction==== -Note: this procedure is used if Bob uses a version 2 payment code (regardless of the the version of Alice's payment code). If Bob's payment code is not version 2, see the appropriate section in this specification. +Note: this procedure is used if Bob uses a version 2 payment code (regardless of the version of Alice's payment code). If Bob's payment code is not version 2, see the appropriate section in this specification. # Construct a notification transaction as per the version 1 instructions, except do not create the output to Bob's notification address # Create a notification change address as follows: diff --git a/bip-0049.mediawiki b/bip-0049.mediawiki index 7d8d2c74..3e37a016 100644 --- a/bip-0049.mediawiki +++ b/bip-0049.mediawiki @@ -6,7 +6,7 @@ Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0049 Status: Final - Type: Informational + Type: Standards Track Created: 2016-05-19 License: PD @@ -92,10 +92,10 @@ This BIP is not backwards compatible by design as described under [[#considerati // Account 0, first receiving private key = m/49'/1'/0'/0/0 account0recvPrivateKey = cULrpoZGXiuC19Uhvykx7NugygA3k86b3hmdCeyvHYQZSxojGyXJ account0recvPrivateKeyHex = 0xc9bdb49cfbaedca21c4b1f3a7803c34636b1d7dc55a717132443fc3f4c5867e8 - account0recvPublickKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f + account0recvPublicKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f // Address derivation - keyhash = HASH160(account0recvPublickKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3 + keyhash = HASH160(account0recvPublicKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3 scriptSig = <0 > = 0x001438971f73930f6c141d977ac4fd4a727c854935b3 addressBytes = HASH160(scriptSig) = 0x336caa13e08b96080a32b5d818d59b4ab3b36742 diff --git a/bip-0060.mediawiki b/bip-0060.mediawiki index 8e9f289f..626a0397 100644 --- a/bip-0060.mediawiki +++ b/bip-0060.mediawiki @@ -23,14 +23,14 @@ The implementation is problematic because the RelayTransactions flag is an optio One property of Bitcoin messages is their fixed number of fields. This keeps the format simple and easily understood. Adding optional fields to messages will cause deserialisation issues when other fields come after the optional one. -As an example, the length of version messages might be checked to ensure the byte stream is consistent. With optional fields, this checking is no longer possible. This is desirable to check for consistency inside internal deserialization code, and proper formatting of version messages originating from other nodes. In the future with diversification of the Bitcoin network, it will become desirable to enforce this kind of strict adherance to standard messages with field length compliance with every protocol version. +As an example, the length of version messages might be checked to ensure the byte stream is consistent. With optional fields, this checking is no longer possible. This is desirable to check for consistency inside internal deserialization code, and proper formatting of version messages originating from other nodes. In the future with diversification of the Bitcoin network, it will become desirable to enforce this kind of strict adherence to standard messages with field length compliance with every protocol version. Another property of fixed-length field messages is the ability to pass stream operators around for deserialization. This property is also lost, as now the deserialisation code must know the remaining length of bytes to parse. The parser now requires an additional piece of information (remaining size of the stream) for parsing instead of being a dumb reader. ==Specification== === version === -When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version. +When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version. Payload: diff --git a/bip-0061.mediawiki b/bip-0061.mediawiki index b08739dd..384c0ff7 100644 --- a/bip-0061.mediawiki +++ b/bip-0061.mediawiki @@ -57,7 +57,7 @@ Every reject message begins with the following fields. Some messages append extr |} The human-readable string is intended only for debugging purposes; in particular, different implementations may -use different strings. The string should not be shown to users or used for anthing besides diagnosing +use different strings. The string should not be shown to users or used for anything besides diagnosing interoperability problems. The following reject code categories are used; in the descriptions below, "server" is the peer generating diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index 793039d2..a31cc3d0 100644 --- a/bip-0067.mediawiki +++ b/bip-0067.mediawiki @@ -53,10 +53,10 @@ Hash the redeem script according to BIP-0016 to get the P2SH address. 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba ==Compatibility== -* Uncompressed keys are incompatible with this specificiation. 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. -* P2SH addressses 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. +* 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. +* 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. * Implementations that do not conform with this BIP will have compatibility issues with strictly-compliant wallets. -* Implementations which do adopt this standard will be cross-compatible when choosing multisig addressses. +* Implementations which do adopt this standard will be cross-compatible when choosing multisig addresses. * If a group of users were not entirely compliant, there is the possibility that a participant will derive an address that the others will not recognize as part of the common multisig account. ==Test vectors== diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 28349ee3..fce60234 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -314,7 +314,7 @@ http://datatracker.ietf.org/wg/jose/ Wikipedia's page on Invoices: http://en.wikipedia.org/wiki/Invoice especially the list of Electronic Invoice standards -sipa's payment protocol proposal: https://gist.github.com/1237788 +sipa's payment protocol proposal: https://gist.github.com/sipa/1237788 ThomasV's "Signed Aliases" proposal : http://ecdsa.org/bitcoin_URIs.html diff --git a/bip-0078.mediawiki b/bip-0078.mediawiki index 1893f0e7..35287256 100644 --- a/bip-0078.mediawiki +++ b/bip-0078.mediawiki @@ -143,7 +143,7 @@ If the receiver does not support the version of the sender, they should send an } -* additionalfeeoutputindex=, if the sender is willing to pay for increased fee, this indicate output can have its value substracted to pay for it. +* additionalfeeoutputindex=, if the sender is willing to pay for increased fee, this indicate output can have its value subtracted to pay for it. If the additionalfeeoutputindex is out of bounds or pointing to the payment output meant for the receiver, the receiver should ignore the parameter. See [[#fee-output|fee output]] for more information. @@ -198,7 +198,7 @@ It is advised to hard code the description of the well known error codes into th ===Fee output=== In some situation, the sender might want to pay some additional fee in the payjoin proposal. -If such is the case, the sender must use both [[#optional-params|optional parameters]] additionalfeeoutputindex= and maxadditionalfeecontribution= to indicate which output and how much the receiver can substract fee. +If such is the case, the sender must use both [[#optional-params|optional parameters]] additionalfeeoutputindex= and maxadditionalfeecontribution= to indicate which output and how much the receiver can subtract fee. There is several cases where a fee output is useful: @@ -273,7 +273,7 @@ The sender should check the payjoin proposal before signing it to prevent a mali * For each outputs in the proposal: ** Verify that no keypaths is in the PSBT output ** 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 maxadditionalfeecontribution. Let's call this amount actual contribution. +*** The amount that was subtracted from the output's value is less than or equal to maxadditionalfeecontribution. Let's call this amount actual contribution. *** Make sure the actual contribution is only paying fee: The actual contribution 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: actual contribution is less than or equals to originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs)). (see [[#fee-output|Fee output]] section) ** If the output is the payment output and payment output substitution is allowed. @@ -344,7 +344,7 @@ On top of this the receiver can poison analysis by randomly faking a round amoun ===Payment output substitution=== -Unless disallowed by sender explicitely via `disableoutputsubstitution=true` or by the BIP21 url via query parameter the `pjos=0`, the receiver is free to decrease the amount, remove, or change the scriptPubKey output paying to himself. +Unless disallowed by sender explicitly via `disableoutputsubstitution=true` or by the BIP21 url via query parameter the `pjos=0`, the receiver is free to decrease the amount, remove, or change the scriptPubKey output paying to himself. Note that if payment output substitution is disallowed, the reveiver can still increase the amount of the output. (See [[#reference-impl|the reference implementation]]) For example, if the sender's scriptPubKey type is P2WPKH while the receiver's payment output in the original PSBT is P2SH, then the receiver can substitute the payment output to be P2WPKH to match the sender's scriptPubKey type. @@ -413,7 +413,7 @@ Here is pseudo code of a sender implementation. The signedPSBT represents a PSBT which has been fully signed, but not yet finalized. We then prepare originalPSBT from the signedPSBT via the CreateOriginalPSBT function and get back the proposal. -While we verify the proposal, we also import into it informations about our own inputs and outputs from the signedPSBT. +While we verify the proposal, we also import into it information about our own inputs and outputs from the signedPSBT. At the end of this RequestPayjoin, the proposal is verified and ready to be signed. We logged the different PSBT involved, and show the result in our [[#test-vectors|test vectors]]. @@ -557,7 +557,7 @@ public async Task RequestPayjoin( if (output.OriginalTxOut == feeOutput) { var actualContribution = feeOutput.Value - proposedPSBTOutput.Value; - // The amount that was substracted from the output's value is less than or equal to maxadditionalfeecontribution + // The amount that was subtracted from the output's value is less than or equal to maxadditionalfeecontribution if (actualContribution > optionalParameters.MaxAdditionalFeeContribution) throw new PayjoinSenderException("The actual contribution is more than maxadditionalfeecontribution"); // Make sure the actual contribution is only paying fee @@ -642,7 +642,7 @@ A successful exchange with: {| class="wikitable" !InputScriptType -!Orginal PSBT Fee rate +!Original PSBT Fee rate !maxadditionalfeecontribution !additionalfeeoutputindex |- diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki index 0cade199..f367c71a 100644 --- a/bip-0080.mediawiki +++ b/bip-0080.mediawiki @@ -35,7 +35,7 @@ Each level has a special meaning, described in the chapters below. ===Purpose=== -Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "80" with the most signifigant bit set to indicate hardened derivation (0x80000050). It indicates that the subtree of this node is used according to this specification. +Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "80" with the most significant bit set to indicate hardened derivation (0x80000050). It indicates that the subtree of this node is used according to this specification. Hardened derivation is used at this level. diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki index 96ac8d1b..923917c5 100644 --- a/bip-0081.mediawiki +++ b/bip-0081.mediawiki @@ -35,7 +35,7 @@ Each level has a special meaning, described in the chapters below. ===Purpose=== -Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "81" with the most signifigant bit set to indicate hardened derivation (0x80000051). It indicates that the subtree of this node is used according to this specification. +Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "81" with the most significant bit set to indicate hardened derivation (0x80000051). It indicates that the subtree of this node is used according to this specification. Hardened derivation is used at this level. diff --git a/bip-0083.mediawiki b/bip-0083.mediawiki index d7bbe8ea..c6690015 100644 --- a/bip-0083.mediawiki +++ b/bip-0083.mediawiki @@ -53,7 +53,7 @@ p //' n instead of p / 0' / n Rather than specifying upfront which path is to be used for a specific purpose (i.e. external invoicing vs. internal change), different applications can specify arbitrary parent nodes and derivation paths. This allows for nesting of sublevels to arbitrary depth with application-specified semantics. Rather than trying to specify use cases upfront, we leave the design completely open-ended. Different applications can exchange these mappings for interoperability. Eventually, if certain mappings become popular, application user interfaces can provide convenient shortcuts or use them as defaults. -Note that BIP32 suggests reserving child 0 for the derivation of signing keys rather than sublevels. It is not really necessary to reserve signing key parents, however, as each key's parent's path can be explicitly stated. But unless we reserve a child for sublevel derivation, we lose the ability to nest deeper levels into the hierarchy. While we could reserve any arbitrary index for nesting sublevels, reserving child 0 seems simplest to implement, leaving all indices > 0 for contiguously indexed signing keys. We could also use MAX_INDEX (231 - 1) for this purpose. However, we believe doing so introduces more ideosyncracies into the semantics and will present a problem if we ever decide to extend the scheme to use indices larger than 31 bits. +Note that BIP32 suggests reserving child 0 for the derivation of signing keys rather than sublevels. It is not really necessary to reserve signing key parents, however, as each key's parent's path can be explicitly stated. But unless we reserve a child for sublevel derivation, we lose the ability to nest deeper levels into the hierarchy. While we could reserve any arbitrary index for nesting sublevels, reserving child 0 seems simplest to implement, leaving all indices > 0 for contiguously indexed signing keys. We could also use MAX_INDEX (231 - 1) for this purpose. However, we believe doing so introduces more idiosyncrasies into the semantics and will present a problem if we ever decide to extend the scheme to use indices larger than 31 bits. ==Use Cases== diff --git a/bip-0084.mediawiki b/bip-0084.mediawiki index dc5a05d9..e1e458c8 100644 --- a/bip-0084.mediawiki +++ b/bip-0084.mediawiki @@ -5,8 +5,8 @@ Author: Pavol Rusnak Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0084 - Status: Draft - Type: Informational + Status: Final + Type: Standards Track Created: 2017-12-28 License: CC0-1.0 diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 6e7dd0e9..633210c6 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -96,18 +96,6 @@ OUTPUT * Python library implementation: [https://github.com/ethankosakovsky/bip85] * JavaScript library implementation: [https://github.com/hoganri/bip85-js] -===Other Implementations=== - -* JavaScript library implementation: [https://github.com/hoganri/bip85-js] - -* Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39] - -* 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== The Application number defines how entropy will be used post processing. Some basic examples follow: @@ -244,7 +232,7 @@ INPUT: OUTPUT * DERIVED ENTROPY=ead0b33988a616cf6a497f1c169d9e92562604e38305ccd3fc96f2252c177682 -* DERIVED WIF=xprv9s21ZrQH143K2srSbCSg4m4kLvPMzcWydgmKEnMmoZUurYuBuYG46c6P71UGXMzmriLzCCBvKQWBUv3vPB3m1SATMhp3uEjXHJ42jFg7myX +* DERIVED XPRV=xprv9s21ZrQH143K2srSbCSg4m4kLvPMzcWydgmKEnMmoZUurYuBuYG46c6P71UGXMzmriLzCCBvKQWBUv3vPB3m1SATMhp3uEjXHJ42jFg7myX ===HEX=== Application number: 128169' @@ -262,6 +250,82 @@ INPUT: OUTPUT * DERIVED ENTROPY=492db4698cf3b73a5a24998aa3e9d7fa96275d85724a91e71aa2d645442f878555d078fd1f1f67e368976f04137b1f7a0d19232136ca50c44614af72b5582a5c +===PWD BASE64=== +Application number: 707764' + +The derivation path format is: m/83696968'/707764'/{pwd_len}'/{index}' + +`20 <= pwd_len <= 86` + +[https://datatracker.ietf.org/doc/html/rfc4648 Base64] encode the all 64 bytes of entropy. +Remove any spaces or new lines inserted by Base64 encoding process. Slice base64 result string +on index 0 to `pwd_len`. This slice is the password. As `pwd_len` is limited to 86, passwords will not contain padding. + +Entropy calculation:
+R = 64 (base64 - do not count padding)
+L = pwd_len
+Entropy = log2(R ** L)
+ +{| class="wikitable" style="margin:auto" +! pwd_length !! (cca) entropy +|- +| 20 || 120.0 +|- +| 24 || 144.0 +|- +| 32 || 192.0 +|- +| 64 || 384.0 +|- +| 86 || 516.0 +|} + +INPUT: +* MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb +* PATH: m/83696968'/707764'/21'/0' + +OUTPUT +* DERIVED ENTROPY=d7ad61d4a76575c5bad773feeb40299490b224e8e5df6c8ad8fe3d0a6eed7b85ead9fef7bcca8160f0ee48dc6e92b311fc71f2146623cc6952c03ce82c7b63fe +* DERIVED PWD=dKLoepugzdVJvdL56ogNV + +===PWD BASE85=== +Application number: 707785' + +The derivation path format is: m/83696968'/707785'/{pwd_len}'/{index}' + +`10 <= pwd_len <= 80` + +Base85 encode the all 64 bytes of entropy. +Remove any spaces or new lines inserted by Base64 encoding process. Slice base85 result string +on index 0 to `pwd_len`. This slice is the password. `pwd_len` is limited to 80 characters. + +Entropy calculation:
+R = 85
+L = pwd_len
+Entropy = log2(R ** L)
+ +{| class="wikitable" style="margin:auto" +! pwd_length !! (cca) entropy +|- +| 10 || 64.0 +|- +| 15 || 96.0 +|- +| 20 || 128.0 +|- +| 30 || 192.0 +|- +| 80 || 512.0 +|} + +INPUT: +* MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb +* PATH: m/83696968'/707785'/12'/0' + +OUTPUT +* DERIVED ENTROPY=f7cfe56f63dca2490f65fcbf9ee63dcd85d18f751b6b5e1c1b8733af6459c904a75e82b4a22efff9b9e69de2144b293aa8714319a054b6cb55826a8e51425209 +* DERIVED PWD=_s`{TW89)i4` + ===RSA=== Application number: 828365' @@ -288,7 +352,7 @@ The resulting RSA key can be used to create a GPG key where the creation date MU Note on GPG key capabilities on smartcard/hardware devices: -GPG capable smart-cards SHOULD be be loaded as follows: The encryption slot SHOULD be loaded with the ENCRYPTION capable key; the authentication slot SHOULD be loaded with the AUTHENTICATION capable key. The signature capable slot SHOULD be loaded with the SIGNATURE capable key. +GPG capable smart-cards SHOULD be loaded as follows: The encryption slot SHOULD be loaded with the ENCRYPTION capable key; the authentication slot SHOULD be loaded with the AUTHENTICATION capable key. The signature capable slot SHOULD be loaded with the SIGNATURE capable key. However, depending on available slots on the smart-card, and preferred policy, the CERTIFY capable key MAY be flagged with CERTIFY and SIGNATURE capabilities and loaded into the SIGNATURE capable slot (for example where the smart-card has only three slots and the CERTIFY capability is required on the same card). In this case, the SIGNATURE capable sub-key would be disregarded because the CERTIFY capable key serves a dual purpose. @@ -300,7 +364,7 @@ This specification relies on BIP32 but is agnostic to how the BIP32 root key is ==Discussion== -The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromized. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur. +The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromised. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur. ==Acknowledgements== diff --git a/bip-0086.mediawiki b/bip-0086.mediawiki index f724884e..529f0946 100644 --- a/bip-0086.mediawiki +++ b/bip-0086.mediawiki @@ -2,7 +2,7 @@ BIP: 86 Layer: Applications Title: Key Derivation for Single Key P2TR Outputs - Author: Andrew Chow + Author: Ava Chow Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0086 Status: Draft diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki index d270027e..920bd3cb 100644 --- a/bip-0087.mediawiki +++ b/bip-0087.mediawiki @@ -40,7 +40,7 @@ A modern standardization is needed for multisig derivation paths. There are som m / purpose' / cosigner_index / change / address_index -BIP45 unecessarily demands a single script type (here, P2SH). In addition, BIP45 sets cosigner_index in order to sort the purpose' public keys of each cosigner. This too is redundant, as descriptors can set the order of the public keys with multi or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with sortedmulti. Sorting public keys between cosigners in order to create the full derivation path, prior to sending the key record to the coordinator to create the descriptor, merely adds additional unnecessary communication rounds. +BIP45 unnecessarily demands a single script type (here, P2SH). In addition, BIP45 sets cosigner_index in order to sort the purpose' public keys of each cosigner. This too is redundant, as descriptors can set the order of the public keys with multi or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with sortedmulti. Sorting public keys between cosigners in order to create the full derivation path, prior to sending the key record to the coordinator to create the descriptor, merely adds additional unnecessary communication rounds. The second multisignature "standard" in use is m/48', which specifies: @@ -48,7 +48,7 @@ The second multisignature "standard" in use is m/48', which specifies: m / purpose' / coin_type' / account' / script_type' / change / address_index -Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type' into the derivation path (where P2SH-P2WSH=1, P2WSH=2, Future_Script=3, etc). As described previously, this is unnecessary, as the descriptor sets the script. While it attempts to reduce maintainence work by getting rid of new BIPs-per-script, it still requires maintaining an updated, redundant, script_type list. +Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type' into the derivation path (where P2SH-P2WSH=1, P2WSH=2, Future_Script=3, etc). As described previously, this is unnecessary, as the descriptor sets the script. While it attempts to reduce maintenance work by getting rid of new BIPs-per-script, it still requires maintaining an updated, redundant, script_type list. The structure proposed later in this paper solves these issues and is quite comprehensive. It allows for the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party, multisignature, hierarchical deterministic wallet regardless of the script type '''Why propose this structure only for multisignature wallets?''' Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually). Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84). With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring. Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only.. diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki index 936f2ca9..db21835e 100644 --- a/bip-0088.mediawiki +++ b/bip-0088.mediawiki @@ -41,7 +41,7 @@ addresses differently than the one they used before. The problem is common enough to warrant the creation of a dedicated website ([https://walletsrecovery.org/ walletsrecovery.org]) that tracks paths used by different wallets. -At the time of writing, this website has used their own format to succintly describe multiple +At the time of writing, this website has used their own format to succinctly describe multiple derivation paths. As far as author knows, it was the only publicitly used format to describe path templates before introduction of this BIP. The format was not specified anywhere beside the main page of the website. It used | to denote alternative derivation indexes @@ -52,7 +52,7 @@ an ad-hoc format only intended for illustration. In contrast to this ad-hoc form described in this BIP is intended for unambigouos parsing by software, and to be easily read by humans at the same time. Humans can visually detect the 'templated' parts of the path more easily than the use of | in the template could allow. Wider range of paths can be defined in a single template more -succintly and unambiguously. +succinctly and unambiguously. ===Intended use and advantages=== @@ -71,7 +71,7 @@ into using well-known paths, or convince other vendors to support their custom p scales poorly. A flexible approach proposed in this document is to define a standard notation for "BIP32 path templates" -that succintly describes the constraints to impose on the derivation path. +that succinctly describes the constraints to impose on the derivation path. Wide support for these path templates will increase interoperability and flexibility of solutions, and will allow vendors and individual developers to easily define their own custom restrictions. @@ -89,7 +89,7 @@ installation of malicious or incorrect profiles, though. ==Specification== -The format for the template was choosen to make it easy to read, convenient and visually unambigous. +The format for the template was chosen to make it easy to read, convenient and visually unambiguous. Template starts with optional prefix m/, and then one or more sections delimited by the slash character (/). @@ -127,13 +127,13 @@ Constraints: # To avoid ambiguity, an index range that matches a single value MUST be specified as Unit range. # To avoid ambiguity, an index range 0-2147483647 is not allowed, and MUST be specified as Wildcard index template instead # For Non-unit range, range_end MUST be larger than range_start. -# If there is more than one index range within the Ranged index template, range_start of the second and any subsequent range MUST be larger than the range_end of the preceeding range. +# If there is more than one index range within the Ranged index template, range_start of the second and any subsequent range MUST be larger than the range_end of the preceding range. # To avoid ambiguity, all representations of integer values larger than 0 MUST NOT start with character 0 (no leading zeroes allowed). # If hardened marker appears within any section in the path template, all preceding sections MUST also specify hardened matching. # To avoid ambiguity, if a hardened marker appears within any section in the path template, all preceding sections MUST also use the same hardened marker (either h or '). # To avoid ambiguity, trailing slashes (for example, 1/2/) and duplicate slashes (for example, 0//1) MUST NOT appear in the template. -It may be desireable to have fully unambiguous encoding, where for each valid path template string, there is no other valid template string that matches the exact same set of paths. This would enable someone to compare templates for equality through a simple string equality check, without any parsing. +It may be desirable to have fully unambiguous encoding, where for each valid path template string, there is no other valid template string that matches the exact same set of paths. This would enable someone to compare templates for equality through a simple string equality check, without any parsing. To achieve this, two extra rules are needed: diff --git a/bip-0093.mediawiki b/bip-0093.mediawiki new file mode 100644 index 00000000..22a7ba32 --- /dev/null +++ b/bip-0093.mediawiki @@ -0,0 +1,599 @@ +
+  BIP: 93
+  Layer: Applications
+  Title: codex32: Checksummed SSSS-aware BIP32 seeds
+  Author: Leon Olsson Curr and Pearlwort Sneed 
+          Andrew Poelstra 
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0093
+  Status: Draft
+  Type: Informational
+  Created: 2023-02-13
+  License: BSD-3-Clause
+  Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021469.html
+
+ +==Introduction== + +===Abstract=== + +This document describes a standard for backing up and restoring the master seed of a +[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032] hierarchical deterministic wallet, using Shamir's secret sharing. +It includes an encoding format, a BCH error-correcting checksum, and algorithms for share generation and secret recovery. +Secret data can be split into up to 31 shares. +A minimum threshold of shares, which can be between 1 and 9, is needed to recover the secret, whereas without sufficient shares, no information about the secret is recoverable. + +===Copyright=== + +This document is licensed under the 3-clause BSD license. + +===Motivation=== + +BIP-0032 master seed data is the source entropy used to derive all private keys in an HD wallet. +Safely storing this secret data is the hardest and most important part of self-custody. +However, there is a tension between security, which demands limiting the number of backups, and resilience, which demands widely replicated backups. +Encrypting the seed does not change this fundamental tradeoff, since it leaves essentially the same problem of how to back up the encryption key(s). + +To allow users freedom to make this tradeoff, we use Shamir's secret sharing, which guarantees that any number of shares less than the threshold leaks no information about the secret. +This approach allows increasing safety by widely distributing the generated shares, while also providing security against the compromise of one or more shares (as long as fewer than the threshold have been compromised). + +[https://github.com/satoshilabs/slips/blob/master/slip-0039.md SLIP-0039] has essentially the same motivations as this standard. +However, unlike SLIP-0039, + +* this standard aims to be simple enough for hand computation +* we use the bech32 alphabet rather than a word list, resulting in fixed-length compact encodings +* we do not support multi-level secret sharing (splitting of shares), although it is technically possible and may be added in a future BIP +* because of the need to support hand computation, we '''do not''' support passphrases or key hardening + +Users who demand a higher level of security for particular secrets, or have a general distrust in digital electronic devices, have the option of using hand computation to backup and restore secret data in an interoperable manner. +In particular, all computations can be done with simple lookup tables. +'''It is therefore possible to compute and verify checksums, and to split and recover seeds, entirely using pen and paper.''' +For long-lived rarely-used seeds, the ability to hand-verify checksums has a significant benefit even for users who do not care to do any other part of this process by hand. +It means that they can verify the integrity (against non-malicious tampering) of their shares regularly, say, on an annual basis, without needing to continually expose secret data to new hardware. + +The ability to compute properties by hand comes from our choice of a small field and our use of linear error correcting codes. +It does not come with any reduction in security, as long as users use high-quality randomness. +Note that hand computation is optional, the particular details of hand computation are outside the scope of this standard, and implementers do not need to be concerned with this possibility. + +[https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] serves the same purpose as this standard: encoding master seeds for storage by users. +However, BIP-0039 has no error-correcting ability, cannot sensibly be extended to support secret sharing, has no support for versioning or other metadata, and has many technical design decisions that make implementation and interoperability difficult (for example, the use of SHA-512 to derive seeds, or the use of 11-bit words). + +==Specification== + +===codex32=== + +A codex32 string is similar to a bech32 string defined in [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP-0173]. +It reuses the base-32 character set from BIP-0173, and consists of: + +* A human-readable part, which is the string "ms" (or "MS"). +* A separator, which is always "1". +* A data part which is in turn subdivided into: +** A threshold parameter, which MUST be a single digit between "2" and "9", or the digit "0". +*** If the threshold parameter is "0" then the share index, defined below, MUST have a value of "s" (or "S"). +** An identifier consisting of 4 bech32 characters. +** A share index, which is any bech32 character. Note that a share index value of "s" (or "S") is special and denotes the unshared secret (see section "Unshared Secret"). +** A payload which is a sequence of up to 74 bech32 characters. (However, see '''Long codex32 Strings''' below for an exception to this limit.) +** A checksum which consists of 13 bech32 characters as described below. + +As with bech32 strings, a codex32 string MUST be entirely uppercase or entirely lowercase. +For presentation, lowercase is usually preferable, but uppercase SHOULD be used for handwritten codex32 strings. +If a codex32 string is encoded in a QR code, it SHOULD use the uppercase form, as this is encoded more compactly. + +===Checksum=== + +The last thirteen characters of the data part form a checksum and contain no information. +Valid strings MUST pass the criteria for validity specified by the Python 3 code snippet below. +The function ms32_verify_checksum must return true when its argument is the data part as a list of integers representing the characters converted using the bech32 character table from BIP-0173. + +To construct a valid checksum given the data-part characters (excluding the checksum), the ms32_create_checksum function can be used. + + +MS32_CONST = 0x10ce0795c2fd1e62a + +def ms32_polymod(values): + GEN = [ + 0x19dc500ce73fde210, + 0x1bfae00def77fe529, + 0x1fbd920fffe7bee52, + 0x1739640bdeee3fdad, + 0x07729a039cfc75f5a, + ] + residue = 0x23181b3 + for v in values: + b = (residue >> 60) + residue = (residue & 0x0fffffffffffffff) << 5 ^ v + for i in range(5): + residue ^= GEN[i] if ((b >> i) & 1) else 0 + return residue + +def ms32_verify_checksum(data): + if len(data) >= 96: # See Long codex32 Strings + return ms32_verify_long_checksum(data) + if len(data) <= 93: + return ms32_polymod(data) == MS32_CONST + return False + +def ms32_create_checksum(data): + if len(data) > 80: # See Long codex32 Strings + return ms32_create_long_checksum(data) + values = data + polymod = ms32_polymod(values + [0] * 13) ^ MS32_CONST + return [(polymod >> 5 * (12 - i)) & 31 for i in range(13)] + + +===Error Correction=== + +A codex32 string without a valid checksum MUST NOT be used. +The checksum is designed to be an error correcting code that can correct up to 4 character substitutions, up to 8 unreadable characters (called erasures), or up to 13 consecutive erasures. +Implementations SHOULD provide the user with a corrected valid codex32 string if possible. +However, implementations SHOULD NOT automatically proceed with a corrected codex32 string without user confirmation of the corrected string, either by prompting the user, or returning a corrected string in an error message and allowing the user to repeat their action. +We do not specify how an implementation should implement error correction. However, we recommend that: + +* Implementations make suggestions to substitute non-bech32 characters with bech32 characters in some situations, such as replacing "B" with "8", "O" with "0", "I" with "l", etc. +* Implementations interpret "?" as an erasure. +* Implementations optionally interpret other non-bech32 characters, or characters with incorrect case, as erasures. +* If a string with 8 or fewer erasures can have those erasures filled in to make a valid codex32 string, then the implementation suggests such a string as a correction. +* If a string consisting of valid bech32 characters in the proper case can be made valid by substituting 4 or fewer characters, then the implementation suggests such a string as a correction. + +===Unshared Secret=== + +When the share index of a valid codex32 string (converted to lowercase) is the letter "s", we call the string a codex32 secret. +The payload in a codex32 secret is a direct encoding of a BIP-0032 HD master seed. + +The master seed is decoded by converting the payload to bytes: + +* Translate the characters to 5 bits values using the bech32 character table from BIP-0173, most significant bit first. +* Re-arrange those bits into groups of 8 bits. Any incomplete group at the end MUST be 4 bits or less, and is discarded. + +Note that unlike the decoding process in BIP-0173, we do NOT require that the incomplete group be all zeros. + +For an unshared secret, the threshold parameter (the first character of the data part) is ignored (beyond the fact it must be a digit for the codex32 string to be valid). +We recommend using the digit "0" for the threshold parameter in this case. +The 4 character identifier also has no effect beyond aiding users in distinguishing between multiple different master seeds in cases where they have more than one. + +===Recovering Master Seed=== + +When the share index of a valid codex32 string (converted to lowercase) is not the letter "s", we call the string an codex32 share. +The first character of the data part indicates the threshold of the share, and it is required to be a non-"0" digit. + +In order to recover a master seed, one needs a set of valid codex32 shares such that: + +* All shares have the same threshold value, the same identifier, and the same length. +* All of the share index values are distinct. +* The number of codex32 shares is exactly equal to the (common) threshold value. + +If all the above conditions are satisfied, the ms32_recover function will return a codex32 secret when its argument is the list of codex32 shares with each share represented as a list of integers representing the characters converted using the bech32 character table from BIP-0173. + + +bech32_inv = [ + 0, 1, 20, 24, 10, 8, 12, 29, 5, 11, 4, 9, 6, 28, 26, 31, + 22, 18, 17, 23, 2, 25, 16, 19, 3, 21, 14, 30, 13, 7, 27, 15, +] + +def bech32_mul(a, b): + res = 0 + for i in range(5): + res ^= a if ((b >> i) & 1) else 0 + a *= 2 + a ^= 41 if (32 <= a) else 0 + return res + +def bech32_lagrange(l, x): + n = 1 + c = [] + for i in l: + n = bech32_mul(n, i ^ x) + m = 1 + for j in l: + m = bech32_mul(m, (x if i == j else i) ^ j) + c.append(m) + return [bech32_mul(n, bech32_inv[i]) for i in c] + +def ms32_interpolate(l, x): + w = bech32_lagrange([s[5] for s in l], x) + res = [] + for i in range(len(l[0])): + n = 0 + for j in range(len(l)): + n ^= bech32_mul(w[j], l[j][i]) + res.append(n) + return res + +def ms32_recover(l): + return ms32_interpolate(l, 16) + + +===Generating Shares=== + +If we already have ''t'' valid codex32 strings such that: + +* All strings have the same threshold value ''t'', the same identifier, and the same length +* All of the share index values are distinct + +Then we can derive additional shares with the ms32_interpolate function by passing it a list of exactly ''t'' of these codex32 strings, together with a fresh share index distinct from all of the existing share indexes. +The newly derived share will have the provided share index. + +Once a user has generated ''n'' codex32 shares, they may discard the codex32 secret (if it exists). +The ''n'' shares form a ''t'' of ''n'' Shamir's secret sharing scheme of a codex32 secret. + +There are two ways to create an initial set of ''t'' valid codex32 strings, depending on whether the user already has an existing master seed to split. + +====For a fresh master seed==== + +In the case that the user wishes to generate a fresh master seed, the user generates random initial shares, as follows: + +# Choose a bitsize, between 128 and 512, which must be a multiple of 8. +# Choose a threshold value ''t'' between 2 and 9, inclusive +# Choose a 4 bech32 character identifier +#* We do not define how to choose the identifier, beyond noting that it SHOULD be distinct for every master seed the user may need to disambiguate. +# ''t'' many times, generate a random share by: +## Take the next available letter from the bech32 alphabet, in alphabetical order, as a, c, d, ..., to be the share index +## Set the first nine characters to be the prefix ms1, the threshold value ''t'', the 4-character identifier, and then the share index +## Choose the next ceil(''bitlength / 5'') characters uniformly at random +## Generate a valid checksum in accordance with the Checksum section, and append this to the resulting shares + +The result will be ''t'' distinct shares, all with the same initial 8 characters, and a distinct share index as the 9th character. + +With this set of ''t'' codex32 shares, new shares can be derived as discussed above. This process generates a fresh master seed, whose value can be retrieved by running the recovery process on any ''t'' of these shares. + +====For an existing master seed==== + +Before generating shares for an existing master seed, it first must be converted into a codex32 secret, as described above. +The conversion process consists of: + +# Choose a threshold value ''t'' between 2 and 9, inclusive +# Choose a 4 bech32 character identifier +#* We do not define how to choose the identifier, beyond noting that it SHOULD be distinct for every master seed the user may need to disambiguate. +# Set the share index to s +# Set the payload to a bech32 encoding of the master seed, padded with arbitrary bits +# Generating a valid checksum in accordance with the Checksum section + +Along with the codex32 secret, the user must generate ''t''-1 other codex32 shares, each with the same threshold value, the same identifier, and a distinct share index. +These shares should be generated as described in the "fresh master seed" section. + +The codex32 secret and the ''t''-1 codex32 shares form a set of ''t'' valid codex32 strings from which additional shares can be derived as described above. + +===Long codex32 Strings=== + +The 13 character checksum design only supports up to 80 data characters. +Excluding the threshold, identifier and index characters, this limits the payload to 74 characters or 46 bytes. +While this is enough to support the 32-byte advised size of BIP-0032 master seeds, BIP-0032 allows seeds to be up to 64 bytes in size. +We define a long codex32 string format to support these longer seeds by defining an alternative checksum. + + +MS32_LONG_CONST = 0x43381e570bf4798ab26 + +def ms32_long_polymod(values): + GEN = [ + 0x3d59d273535ea62d897, + 0x7a9becb6361c6c51507, + 0x543f9b7e6c38d8a2a0e, + 0x0c577eaeccf1990d13c, + 0x1887f74f8dc71b10651, + ] + residue = 0x23181b3 + for v in values: + b = (residue >> 70) + residue = (residue & 0x3fffffffffffffffff) << 5 ^ v + for i in range(5): + residue ^= GEN[i] if ((b >> i) & 1) else 0 + return residue + +def ms32_verify_long_checksum(data): + return ms32_long_polymod(data) == MS32_LONG_CONST + +def ms32_create_long_checksum(data): + values = data + polymod = ms32_long_polymod(values + [0] * 15) ^ MS32_LONG_CONST + return [(polymod >> 5 * (14 - i)) & 31 for i in range(15)] + + +A long codex32 string follows the same specification as a regular codex32 string with the following changes. + +* The payload is a sequence of between 75 and 103 bech32 characters. +* The checksum consists of 15 bech32 characters as defined above. + +A codex32 string with a data part of 94 or 95 characters is never legal as a regular codex32 string is limited to 93 data characters and a long codex32 string is at least 96 characters. + +Generation of long shares and recovery of the master seed from long shares proceeds in exactly the same way as for regular shares with the ms32_interpolate function. + +The long checksum is designed to be an error correcting code that can correct up to 4 character substitutions, up to 8 unreadable characters (called erasures), or up to 15 consecutive erasures. +As with regular checksums we do not specify how an implementation should implement error correction, and all our recommendations for error correction of regular codex32 strings also apply to long codex32 strings. + +==Rationale== + +This scheme is based on the observation that the Lagrange interpolation of valid codewords in a BCH code will always be a valid codeword. +This means that derived shares will always have valid checksum, and a sufficient threshold of shares with valid checksums will derive a secret with a valid checksum. + +The header system is also compatible with Lagrange interpolation, meaning all derived shares will have the same identifier and will have the appropriate share index. +This fact allows the header data to be covered by the checksum. + +The checksum size and identifier size have been chosen so that the encoding of 128-bit seeds and shares fit within 48 characters. +This is a standard size for many common seed storage formats, which has been popularized by the 12 four-letter word format of the BIP-0039 mnemonic. + +The 13 character checksum is adequate to correct 4 errors in up to 93 characters (80 characters of data and 13 characters of the checksum). +We can correct up to 8 erasures (errors with known locations), and up to 13 consecutive errors (burst errors). +Beyond that, our code is guaranteed to detect up to 8 errors. +More generally, any number of random errors will be detected with overwhelming (1 - 2^65) probability. However, the checksum does not protect against maliciously constructed errors. +These parameters are slightly better than those of the checksum used in SLIP-0039. + +For 256-bit seeds and shares our strings are 74 characters, which fits into the 96 character format of the 24 four-letter word format of the BIP-0039 mnemonic, with plenty of room to spare. + +A longer checksum is needed to support up to 512-bit seeds, the longest seed length specified in BIP-0032, as the 13 character checksum isn't adequate for more than 80 data characters. +While we could use the 15 character checksum for both cases, we prefer to keep the strings as short as possible for the more common cases of 128-bit and 256-bit master seeds. +We only guarantee to correct 4 characters no matter how long the string is. +Longer strings mean more chances for transcription errors, so shorter strings are better. + +The longest data part using the regular 13 character checksum is 93 characters and corresponds to a 400-bit secret. +At this length, the prefix MS1 is not covered by the checksum. +This is acceptable because the checksum scheme itself requires you to know that the MS1 prefix is being used in the first place. +If the prefix is damaged and a user is guessing that the data might be using this scheme, then the user can enter the available data explicitly using the suspected MS1 prefix. + +===Not BIP-0039 Entropy=== + +Instead of encoding a BIP-0032 master seed, an alternative would be to encode BIP-0039 entropy. +However this alternative approach is fraught with difficulties. + +On approach would be to encode the BIP-0039 entropy along with the BIP-0039 checksum data. +This data can directly be recovered from the BIP-0039 mnemonic, and the process can be reversed if one knows the target language. +However, for a 128-bit seed, there is a 4 bit checksum yielding 132 bits of data that needs to be encoded. +This exceeds the 130-bits of room that we have for storing 128 bit seeds. +We would have to compromise on the 48 character size, or the size of the headers, or the size of the checksum in order to add room for an additional character of data. + +This approach would also eliminate our short cut generation of a fresh master secret from generating random shares. +One would be required to first generate BIP-0039 entropy, and then add a BIP-0039 checksum, before adding a Codex32 checksum and then generate other shares. +In particular, this process could no longer be performed by hand since it is effectively impossible to hand compute a BIP-0039 checksum. + +An alternative approach is to discard the BIP-0039 checksum, since it is inadequate for error correction anyways, and rely on the Codex32 checksum. +However, this approach ends up eliminating the benefits of BIP-0039 compatibility. +While it is now possible to hand generate fresh shares, it is impossible to recover compatible BIP-0039 words by hand because, again, the BIP-0039 checksum is not hand computable. +The only way of generating the compatible BIP-0039 mnemonic is to use wallet software. +But if the wallet software is need to support this approach to decoding entropy, we may as well bypass all of the overhead of BIP-0039 and directly encode the entropy of a BIP-0032 master seed, which is what we do in our Codex32 proposal. + +Beyond the problems above, BIP-0039 does not define a single transformation from entropy to BIP-0032 master seed. +Instead every different language has it own word list (or word lists) and each choice of word list yields a different transformation from entropy to master seed. +We would need to encode the choice of word list in our share's meta-data, which takes up even more room, and is difficult to specify due to the ever-evolving choice of word lists. + +Alternatively we could standardize on the choice of the English word list, something that is nearly a de facto standard, and simply be incompatible with BIP-0039 wallets of other languages. +Such a choice also risks users of BIP-0039 recovering their entropy from their language, encoding it in Codex32 and then failing to recover their wallet because the English word lists has replaced their language's word list. + +The main advantage of this alternative approach would be that wallets could give users an option switch between backing up their entropy as a BIP-0039 mnemonic and in Codex32 format, but again, only if their language choice happens to be the English word list. +In practice, we do not expect users in switch back and forth between backup formats, and instead just generate a fresh master seed using Codex32. + +Seeing little value with BIP-0039 compatibility (English-only), all the difficulties with BIP-0039 language choice, not to mention the PBKDF2 overhead of using BIP-0039, we think it is best to abandon BIP-0039 and encode BIP-0032 master seeds directly. +Our approach is semi-convertible with BIP-0039's 512-bit master seeds (in all languages, see Backwards Compatibility) and fully interconvertible with SLIP-39 encoded master seeds or any other encoding of BIP-0032 master seeds. + +==Backwards Compatibility== + +codex32 is an alternative to BIP-0039 and SLIP-0039. +It is technically possible to derive the BIP32 master seed from seed words encoded in one of these schemes, and then to encode this seed in codex32. +For BIP-0039 this process is irreversible, since it involves hashing the original words. +Furthermore, the resulting seed will be 512 bits long, which may be too large to be safely and conveniently handled. + +SLIP-0039 seed words can be reversibly converted to master seeds, so it is possible to interconvert between SLIP-0039 and codex32. +However, SLIP-0039 '''shares''' cannot be converted to codex32 shares because the two schemes use a different underlying field. + +The authors of this BIP do not recommend interconversion. +Instead, users who wish to switch to codex32 should generate a fresh seed and sweep their coins. + +==Reference Implementation== + +Our [https://github.com/BlockstreamResearch/codex32 reference implementation repository] contains implementations in Rust and PostScript. +The inline code in this BIP text can be used as a Python reference. + +==Test Vectors== + +===Test vector 1=== + +This example shows the codex32 format, when used without splitting the secret into any shares. +The payload contains 26 bech32 characters, which corresponds to 130 bits. We truncate the last two bits in order to obtain a 128-bit master seed. + +codex32 secret (bech32): ms10testsxxxxxxxxxxxxxxxxxxxxxxxxxx4nzvca9cmczlw + +Master secret (hex): 318c6318c6318c6318c6318c6318c631 + +* human-readable part: ms +* separator: 1 +* k value: 0 (no secret splitting) +* identifier: test +* share index: s (the secret) +* payload: xxxxxxxxxxxxxxxxxxxxxxxxxx +* checksum: 4nzvca9cmczlw +* master node xprv: xprv9s21ZrQH143K3taPNekMd9oV5K6szJ8ND7vVh6fxicRUMDcChr3bFFzuxY8qP3xFFBL6DWc2uEYCfBFZ2nFWbAqKPhtCLRjgv78EZJDEfpL + +===Test vector 2=== + +This example shows generating a new master seed using "random" codex32 shares, as well as deriving an additional codex32 share, using ''k''=2 and an identifier of NAME. +Although codex32 strings are canonically all lowercase, it's also valid to use all uppercase. + +Share with index A: MS12NAMEA320ZYXWVUTSRQPNMLKJHGFEDCAXRPP870HKKQRM + +Share with index C: MS12NAMECACDEFGHJKLMNPQRSTUVWXYZ023FTR2GDZMPY6PN + +* Derived share with index D: MS12NAMEDLL4F8JLH4E5VDVULDLFXU2JHDNLSM97XVENRXEG +* Secret share with index S: MS12NAMES6XQGUZTTXKEQNJSJZV4JV3NZ5K3KWGSPHUH6EVW +* Master secret (hex): d1808e096b35b209ca12132b264662a5 +* master node xprv: xprv9s21ZrQH143K2NkobdHxXeyFDqE44nJYvzLFtsriatJNWMNKznGoGgW5UMTL4fyWtajnMYb5gEc2CgaKhmsKeskoi9eTimpRv2N11THhPTU + +Note that per BIP-0173, the lowercase form is used when determining a character's value for checksum purposes. +In particular, given an all uppercase codex32 string, we still use lowercase ms as the human-readable part during checksum construction. + +===Test vector 3=== + +This example shows splitting an existing 128-bit master seed into "random" codex32 shares, using ''k''=3 and an identifier of cash. +We appended two zero bits in order to obtain 26 bech32 characters (130 bits of data) from the 128-bit master seed. + +Master secret (hex): ffeeddccbbaa99887766554433221100 + +Secret share with index s: ms13cashsllhdmn9m42vcsamx24zrxgs3qqjzqud4m0d6nln + +Share with index a: ms13casha320zyxwvutsrqpnmlkjhgfedca2a8d0zehn8a0t + +Share with index c: ms13cashcacdefghjklmnpqrstuvwxyz023949xq35my48dr + +* Derived share with index d: ms13cashd0wsedstcdcts64cd7wvy4m90lm28w4ffupqs7rm +* Derived share with index e: ms13casheekgpemxzshcrmqhaydlp6yhms3ws7320xyxsar9 +* Derived share with index f: ms13cashf8jh6sdrkpyrsp5ut94pj8ktehhw2hfvyrj48704 +* master node xprv: xprv9s21ZrQH143K266qUcrDyYJrSG7KA3A7sE5UHndYRkFzsPQ6xwUhEGK1rNuyyA57Vkc1Ma6a8boVqcKqGNximmAe9L65WsYNcNitKRPnABd + +Any three of the five shares among acdef can be used to recover the secret. + +Note that the choice to append two zero bits was arbitrary, and any of the following four secret shares would have been valid choices. +However, each choice would have resulted in a different set of derived shares. + +* ms13cashsllhdmn9m42vcsamx24zrxgs3qqjzqud4m0d6nln +* ms13cashsllhdmn9m42vcsamx24zrxgs3qpte35dvzkjpt0r +* ms13cashsllhdmn9m42vcsamx24zrxgs3qzfatvdwq5692k6 +* ms13cashsllhdmn9m42vcsamx24zrxgs3qrsx6ydhed97jx2 + +===Test vector 4=== + +This example shows converting a 256-bit secret into a codex32 secret, without splitting the secret into any shares. +We appended four zero bits in order to obtain 52 bech32 characters (260 bits of data) from the 256-bit secret. + +256-bit secret (hex): ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100 + +* codex32 secret: ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqqtum9pgv99ycma +* master node xprv: xprv9s21ZrQH143K3s41UCWxXTsU4TRrhkpD1t21QJETan3hjo8DP5LFdFcB5eaFtV8x6Y9aZotQyP8KByUjgLTbXCUjfu2iosTbMv98g8EQoqr + +Note that the choice to append four zero bits was arbitrary, and any of the following sixteen codex32 secrets would have been valid: + +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqqtum9pgv99ycma +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqpj82dp34u6lqtd +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqzsrs4pnh7jmpj5 +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqrfcpap2w8dqezy +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqy5tdvphn6znrf0 +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq9dsuypw2ragmel +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqx05xupvgp4v6qx +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq8k0h5p43c2hzsk +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqgum7hplmjtr8ks +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqf9q0lpxzt5clxq +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq28y48pyqfuu7le +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqt7ly0paesr8x0f +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqvrvg7pqydv5uyz +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqd6hekpea5n0y5j +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqwcnrwpmlkmt9dt +* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq0pgjxpzx0ysaam + +===Test vector 5=== + +This example shows generating a new 512-bit master seed using "random" codex32 characters and appending a checksum. +The payload contains 103 bech32 characters, which corresponds to 515 bits. The last three bits are discarded when converting to a 512-bit master seed. + +This is an example of a '''Long codex32 String'''. + +* Secret share with index S: MS100C8VSM32ZXFGUHPCHTLUPZRY9X8GF2TVDW0S3JN54KHCE6MUA7LQPZYGSFJD6AN074RXVCEMLH8WU3TK925ACDEFGHJKLMNPQRSTUVWXY06FHPV80UNDVARHRAK +* Master secret (hex): dc5423251cb87175ff8110c8531d0952d8d73e1194e95b5f19d6f9df7c01111104c9baecdfea8cccc677fb9ddc8aec5553b86e528bcadfdcc201c17c638c47e9 +* master node xprv: xprv9s21ZrQH143K4UYT4rP3TZVKKbmRVmfRqTx9mG2xCy2JYipZbkLV8rwvBXsUbEv9KQiUD7oED1Wyi9evZzUn2rqK9skRgPkNaAzyw3YrpJN + +===Invalid test vectors=== + +These examples have incorrect checksums. + +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxve740yyge2ghq +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxve740yyge2ghp +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxlk3yepcstwr +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxx6pgnv7jnpcsp +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxx0cpvr7n4geq +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxm5252y7d3lr +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxrd9sukzl05ej +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxc55srw5jrm0 +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxgc7rwhtudwc +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxx4gy22afwghvs +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxe8yfm0 +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxvm597d +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxme084q0vpht7pe0 +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxme084q0vpht7pew +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxqyadsp3nywm8a +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzvg7ar4hgaejk +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxcznau0advgxqe +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxch3jrc6j5040j +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx52gxl6ppv40mcv +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx7g4g2nhhle8fk +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx63m45uj8ss4x8 +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxy4r708q7kg65x + +These examples use the wrong checksum for their given data sizes. + +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxurfvwmdcmymdufv +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxcsyppjkd8lz4hx3 +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxu6hwvl5p0l9xf3c +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxwqey9rfs6smenxa +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv70wkzrjr4ntqet +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3hmlrmpa4zl0v +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrfggf88znkaup +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxpt7l4aycv9qzj +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxus27z9xtyxyw3 +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxcwm4re8fs78vn + +These examples have improper lengths. +They are either too short, too long, or would decode to byte sequence with an incomplete group greater than 4 bits. + +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxw0a4c70rfefn4 +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxk4pavy5n46nea +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxx9lrwar5zwng4w +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxr335l5tv88js3 +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxvu7q9nz8p7dj68v +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxpq6k542scdxndq3 +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkmfw6jm270mz6ej +* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxzhddxw99w7xws +* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxxx42cux6um92rz +* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxxxxarja5kqukdhy9 +* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxky0ua3ha84qk8 +* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9eheesxadh2n2n9 +* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9llwmgesfulcj2z +* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx02ev7caq6n9fgkf + +This example uses a "0" threshold with a non-"s" index + +* ms10fauxxxxxxxxxxxxxxxxxxxxxxxxxxxx0z26tfn0ulw3p + +This example has a threshold that is not a digit. + +* ms1fauxxxxxxxxxxxxxxxxxxxxxxxxxxxxxda3kr3s0s2swg + +These examples do not begin with the required "ms" or "MS" prefix and/or are missing the "1" separator. + +* 0fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2 +* 10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2 +* ms0fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2 +* m10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2 +* s10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2 +* 0fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxhkd4f70m8lgws +* 10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxhkd4f70m8lgws +* m10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxx8t28z74x8hs4l +* s10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxh9d0fhnvfyx3x + +These examples all incorrectly mix upper and lower case characters. + +* Ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2 +* mS10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2 +* MS10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2 +* ms10FAUXsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2 +* ms10fauxSxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2 +* ms10fauxsXXXXXXXXXXXXXXXXXXXXXXXXXXuqxkk05lyf3x2 +* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxUQXKK05LYF3X2 + +==Appendix== + +===Mathematical Companion=== + +Below we use the bech32 character set to denote values in GF[32]. +In bech32, the letter Q denotes zero and the letter P denotes one. +The digits 0 and 2 through 9 do ''not'' denote their numeric values. +They are simply elements of GF[32]. + +The generating polynomial for our BCH code is as follows. + +We extend GF[32] to GF[1024] by adjoining a primitive cube root of unity, ζ, satisfying ζ^2 = ζ + P. + +We select β := G ζ which has order 93, and construct the product (x - β^i) for i in {17, 20, 46, 49, 52, 77, 78, 79, 80, 81, 82, 83, 84}. +The resulting polynomial is our generating polynomial for our 13 character checksum: + + x^13 + E x^12 + M x^11 + 3 x^10 + G x^9 + Q x^8 + E x^7 + E x^6 + E x^5 + L x^4 + M x^3 + C x^2 + S x + S + +For our long checksum, we select γ := E + X ζ, which has order 1023, and construct the product (x - γ^i) for i in {32, 64, 96, 895, 927, 959, 991, 1019, 1020, 1021, 1022, 1023, 1024, 1025, 1026}. +The resulting polynomial is our generating polynomial for our 15 character checksum for long strings: + + x^15 + 0 x^14 + 2 x^13 + E x^12 + 6 x^11 + F x^10 + E x^9 + 4 x^8 + X x^7 + H x^6 + 4 x^5 + X x^4 + 9 x^3 + K x^2 + Y x^1 + H + +(Reminder: the character 0 does ''not'' denote the zero of the field.) diff --git a/bip-0098.mediawiki b/bip-0098.mediawiki index 8540d1ac..a296fdc8 100644 --- a/bip-0098.mediawiki +++ b/bip-0098.mediawiki @@ -241,16 +241,16 @@ Disallowing a node with two SKIP branches eliminates what would otherwise be a s The number of hashing operations required to verify a proof is one less than the number of hashes (SKIP and VERIFY combined), and is exactly equal to the number of inner nodes serialized as the beginning of the proof as N. -The variable-length integer encoding has the property that serialized integers, sorted lexigraphically, will also be sorted numerically. -Since the first serialized item is the number of inner nodes, sorting proofs lexigraphically has the effect of sorting the proofs by the amount of work required to verify. +The variable-length integer encoding has the property that serialized integers, sorted lexicographically, will also be sorted numerically. +Since the first serialized item is the number of inner nodes, sorting proofs lexicographically has the effect of sorting the proofs by the amount of work required to verify. The number of hashes required as input for verification of a proof is N+1 minus the number of SKIP hashes, and can be quickly calculated without parsing the tree structure. -The coding and packing rules for the serialized tree structure were also chosen to make lexigraphical comparison useful (or at least not meaningless). +The coding and packing rules for the serialized tree structure were also chosen to make lexicographical comparison useful (or at least not meaningless). If we consider a fully-expanded tree (no SKIP hashes, all VERIFY) to be encoding a list of elements in the order traversed depth-first from left-to-right, then we can extract proofs for subsets of the list by SKIP'ing the hashes of missing values and recursively pruning any resulting SKIP,SKIP nodes. -Lexigraphically comparing the resulting serialized tree structures is the same as lexigraphically comparing lists of indices from the original list verified by the derived proof. +Lexicographically comparing the resulting serialized tree structures is the same as lexicographically comparing lists of indices from the original list verified by the derived proof. Because the number of inner nodes and the number of SKIP hashes is extractible from the tree structure, both variable-length integers in the proof are redundant and could have been omitted. diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index 8882e003..156eec02 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -56,7 +56,7 @@ development, diversity, etc) to fork the Bitcoin Core software and it's good that there's many alternative implementations of the protocol (forks of Bitcoin Core or written from scratch). -But sometimes a bug in the reimplementaion of the consensus +But sometimes a bug in the reimplementation of the consensus validation rules can prevent users of alternative implementation from following the longest (most work) valid chain. This can result in those users losing coins or being defrauded, making reimplementations diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki index 69b265b1..4822d4a2 100644 --- a/bip-0109.mediawiki +++ b/bip-0109.mediawiki @@ -37,7 +37,7 @@ In particular: * The coinbase scriptSig is not counted * Signature operations in un-executed branches of a Script are not counted -* OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top of the execution stack, it is counted as one signature operation. If it is satisfied by the public key nearest the bottom of the execution stack, it is counted as twenty signature operations. +* OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisfied by the public key nearest the top of the execution stack, it is counted as one signature operation. If it is satisfied by the public key nearest the bottom of the execution stack, it is counted as twenty signature operations. * Signature operations involving invalidly encoded signatures or public keys are not counted towards the limit === Add a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per block === diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index 63a77975..d6ed5460 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -36,7 +36,7 @@ When executed, if any of the following conditions are true, the script interpret Otherwise, script execution will continue as if a NOP had been executed. -BIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age, as measured in block-height or block-time. By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field, we indirectly verify a desired minimum age of the +BIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age, as measured in block-height or block-time. By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field, we indirectly verify a desired minimum age of the output being spent; until that relative age has been reached any script execution pathway including the CHECKSEQUENCEVERIFY will fail to validate, causing the transaction not to be selected for inclusion in a block. diff --git a/bip-0114.mediawiki b/bip-0114.mediawiki index 410e84cc..5b071374 100644 --- a/bip-0114.mediawiki +++ b/bip-0114.mediawiki @@ -111,7 +111,7 @@ The advantages of the current proposal are: * If different parties in a contract do not want to expose their scripts to each other, they may provide only H(Subscript) and keep the Subscript private until redemption. * If they are willing to share the actual scripts, they may combine them into one Subscript for each branch, saving some nOpCount and a few bytes of witness space. -The are some disadvantages, but only when the redemption condition is very complicated: +There are some disadvantages, but only when the redemption condition is very complicated: * It may require more branches than a general MAST design (as shown in the previous example) and take more witness space in redemption * Creation and storage of the MAST structure may take more time and space. However, such additional costs affect only the related parties in the contract but not any other Bitcoin users. diff --git a/bip-0115.mediawiki b/bip-0115.mediawiki index 8bc90f69..042d0570 100644 --- a/bip-0115.mediawiki +++ b/bip-0115.mediawiki @@ -98,7 +98,7 @@ What if ParamBlockHash has leading zeros? Should this be prevented? * If leading zeros are included, they should be compared to the actual block hash. (If they were truncated, fewer bytes would be compared.) * It is unlikely that the leading zeros will ever be necessary for sufficient precision, so the additional space is not a concern. -* Since all block hashes are in principle shorter than than 29 bytes, ParamBlockHash may not be larger than 28 bytes. +* Since all block hashes are in principle shorter than 29 bytes, ParamBlockHash may not be larger than 28 bytes. Why is it safe to allow checking blocks as recently as the immediate previous block? diff --git a/bip-0116.mediawiki b/bip-0116.mediawiki index 86b0f9aa..70b340f5 100644 --- a/bip-0116.mediawiki +++ b/bip-0116.mediawiki @@ -59,7 +59,7 @@ This includes execution pathways or policy conditions which end up not being nee Not only is it inefficient to require this unnecessary information to be present on the blockchain, albeit in the witness, it also impacts privacy and fungibility as some unused script policies may be identifying. Using a Merkle hash tree to commit to the policy options, and then only forcing revelation of the policy used at redemption minimizes this information leakage. -Using Merkle hash trees to commit to policy allows for considerably more complex contracts than would would otherwise be possible, due to various built-in script size and runtime limitations. +Using Merkle hash trees to commit to policy allows for considerably more complex contracts than would otherwise be possible, due to various built-in script size and runtime limitations. With Merkle commitments to policy these size and runtime limitations constrain the complexity of any one policy that can be used rather than the sum of all possible policies. ==Rationale== diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki index a3a690bb..93e0578b 100644 --- a/bip-0118.mediawiki +++ b/bip-0118.mediawiki @@ -73,7 +73,7 @@ To convert a 33-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 34 ==== Signature message ==== -The function ''SigMsg118(hash_type, ext_flag)'' computes the message being signed as a byte array, analogously to ''SigMsg(hash_type, ext_flag)'' defined in [[bip-0341.mediawiki|BIP 341]], ''SigExt118(hash_type,key_version)'' computes the extension, similarly to [[bip-0342.mediawiki|BIP 342]]. +We define the functions ''Msg118(hash_type)'' and ''Ext118(hash_type)'' which compute the message being signed as a byte array. The parameter ''hash_type'' is an 8-bit unsigned value, reusing values defined in [[bip-0341.mediawiki|BIP 341]], with the addition that the values 0x41, 0x42, 0x43, 0xc1, 0xc2, and 0xc3 are also valid for BIP 118 public keys. @@ -82,64 +82,56 @@ We define the following constants using bits 6 and 7 of hash_type: * SIGHASH_ANYPREVOUT = 0x40 * SIGHASH_ANYPREVOUTANYSCRIPT = 0xc0 -As per [[bip-0341.mediawiki|BIP 341]], the parameter ''ext_flag'' is an integer in the range 0-127, used for indicating that extensions are added at the end of the message. The parameter ''key_version'' is an 8-bit unsigned value (an integer in the range 0-255) used for committing to the public key version. - The following restrictions apply and cause validation failure if violated: * Using any undefined ''hash_type'' (not ''0x00'', ''0x01'', ''0x02'', ''0x03'', ''0x41'', ''0x42'', ''0x43'', ''0x81'', ''0x82'', ''0x83'', ''0xc1'', ''0xc2'', or ''0xc3''). * Using SIGHASH_SINGLE without a "corresponding output" (an output with the same index as the input being verified). -If these restrictions aren't violated, ''SigMsg118(hash_type,ext_flag)'' evaluates to the concatenation of the following data, in order (with byte size of each item listed in parentheses). Numerical values in 2, 4, or 8-byte items are encoded in little-endian. +If these restrictions are not violated, ''Msg118(hash_type)'' evaluates as follows. + +If ''hash_type & 0x40 == 0'', then ''Msg118(hash_type) = SigMsg(hash_type, 1)'', where ''SigMsg'' is as defined in [[bip-0341.mediawiki|BIP 341]]. + +If ''hash_type & 0x40 != 0'', then ''Msg118(hash_type)'' is the concatenation of the following data, in order (with byte size of each item listed in parentheses). Numerical values in 2, 4, or 8-byte items are encoded in little-endian. * Control: ** ''hash_type'' (1). * Transaction data: ** ''nVersion'' (4): the ''nVersion'' of the transaction. ** ''nLockTime'' (4): the ''nLockTime'' of the transaction. -** If ''hash_type & 0xc0'' is zero: -*** ''sha_prevouts'' (32): the SHA256 of the serialization of all input outpoints. -*** ''sha_amounts'' (32): the SHA256 of the serialization of all spent output amounts. -*** ''sha_scriptpubkeys'' (32): the SHA256 of the serialization of all spent output ''scriptPubKey''s. -*** ''sha_sequences'' (32): the SHA256 of the serialization of all input ''nSequence''. ** If ''hash_type & 3'' does not equal SIGHASH_NONE or SIGHASH_SINGLE: *** ''sha_outputs'' (32): the SHA256 of the serialization of all outputs in CTxOut format. * Data about this input: -** ''spend_type'' (1): equal to ''(ext_flag * 2) + annex_present'', where ''annex_present'' is 0 if no annex is present, or 1 otherwise (the original witness stack has two or more witness elements, and the first byte of the last element is ''0x50'') -** If ''hash_type & 0xc0'' is non-zero: -*** If ''hash_type & 0xc0'' is SIGHASH_ANYONECANPAY: -**** ''outpoint'' (36): the COutPoint of this input (32-byte hash + 4-byte little-endian). -*** If ''hash_type & 0xc0'' is SIGHASH_ANYONECANPAY or SIGHASH_ANYPREVOUT: -**** ''amount'' (8): value of the previous output spent by this input. -**** ''scriptPubKey'' (35): ''scriptPubKey'' of the previous output spent by this input, serialized as script inside CTxOut. Its size is always 35 bytes. -*** ''nSequence'' (4): ''nSequence'' of this input. -** If ''hash_type & 0xc0'' is zero: -*** ''input_index'' (4): index of this input in the transaction input vector. Index of the first input is 0. +** ''spend_type'' (1): equal to 2 if no annex is present, or 3 otherwise (the original witness stack has two or more witness elements, and the first byte of the last element is ''0x50'') +** If ''hash_type & 0xc0'' is SIGHASH_ANYPREVOUT: +*** ''amount'' (8): value of the previous output spent by this input. +*** ''scriptPubKey'' (35): ''scriptPubKey'' of the previous output spent by this input, serialized as script inside CTxOut. Its size is always 35 bytes. +** ''nSequence'' (4): ''nSequence'' of this input. ** If an annex is present (the lowest bit of ''spend_type'' is set): *** ''sha_annex'' (32): the SHA256 of ''(compact_size(size of annex) || annex)'', where ''annex'' includes the mandatory ''0x50'' prefix. * Data about this output: ** If ''hash_type & 3'' equals SIGHASH_SINGLE: *** ''sha_single_output'' (32): the SHA256 of the corresponding output in CTxOut format. -Similarly, ''SigExt118(hash_type,key_version)'' evaluates to the concatenation of: +Similarly, ''Ext118(hash_type)'' evaluates to the concatenation of the following data, in order: * Extension: ** If ''hash_type & 0xc0'' is not SIGHASH_ANYPREVOUTANYSCRIPT: *** ''tapleaf_hash'' (32): the tapleaf hash as defined in [[bip-0341.mediawiki|BIP 341]] -** ''key_version'' (1). +** ''key_version'' (1): a constant value ''0x01'' representing that this is a signature for a BIP 118 public key. ** ''codesep_pos'' (4): the opcode position of the last executed OP_CODESEPARATOR before the currently executed signature opcode, with the value in little endian (or ''0xffffffff'' if none executed). The first opcode in a script has a position of 0. A multi-byte push opcode is counted as one opcode, regardless of the size of data being pushed. -Note that if ''hash_type & 0x40'' is zero, ''SigMsg118(hash_type,ext_flag) == SigMsg(hash_type,ext_flag)'', and ''SigExt118(hash_type,0x00) == ext'' (where ''ext'' is the message extension as defined in [[bip-0342.mediawiki|BIP 342]]). - To verify a signature ''sig'' for a BIP 118 public key ''p'': -* If the ''sig'' is 64 bytes long, return ''Verify(p, hashTapSigHash(0x00 || SigMsg118(0x00, 1) || SigExt118(0x00, 0x01), sig)'', where ''Verify'' is defined in [[bip-0340.mediawiki|BIP 340]]. -* If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00 and Verify(p, hashTapSighash(0x00 || SigMsg118(sig[64], 1) || SigExt118(sig[64], 0x01), sig[0:64])''. +* If the ''sig'' is 64 bytes long, return ''Verify(p, hashTapSigHash(0x00 || Msg118(0x00) || Ext118(0x00)), sig)'' +* If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00 and Verify(p, hashTapSighash(0x00 || Msg118(sig[64]) || Ext118(sig[64])), sig[0:64])''. * Otherwise, fail. +''Verify'' is as defined in [[bip-0340.mediawiki|BIP 340]]. + The key differences from [[bip-0342.mediawiki|BIP 342]] signature verification are: * In all cases, key_version is set to the constant value 0x01 instead of 0x00.'''Why change key_version?''' Changing key_version ensures that if the same private key is used to generate both a [[bip-0342.mediawiki|BIP 342]] key and a BIP 118 public key, that a signature for the [[bip-0342.mediawiki|BIP 342]] key is not also valid for the BIP 118 public key (and vice-versa). * If SIGHASH_ANYPREVOUT is set, the digest is calculated as if SIGHASH_ANYONECANPAY was set, except outpoint is not included in the digest. -* If SIGHASH_ANYPREVOUTANYSCRIPT is set, the digest is calculated as if SIGHASH_ANYONECANPAY was set, except outpoint, scriptPubKey and tapleaf_hash are not included in the digest. +* If SIGHASH_ANYPREVOUTANYSCRIPT is set, the digest is calculated as if SIGHASH_ANYONECANPAY was set, except outpoint, amount, scriptPubKey and tapleaf_hash are not included in the digest. == Security == diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index 304f228c..be1f70cb 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -3,6 +3,7 @@ Layer: Consensus (soft fork) Title: CHECKTEMPLATEVERIFY Author: Jeremy Rubin + James O'Beirne Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0119 Status: Draft Type: Standards Track @@ -39,159 +40,67 @@ The recommended standardness rules additionally: ==Motivation== -Covenants are restrictions on how a coin may be spent beyond key ownership. This is a general -definition based on the legal definition which even simple scripts using CSV would satisfy. -Covenants in Bitcoin transactions usually refer to restrictions on where coins can be transferred. -Covenants can be useful to construct smart contracts. As covenants are complex to implement -and risk of introducing fungibility discriminants they have not been seriously considered for -inclusion in Bitcoin. +Covenants are restrictions on how a coin may be spent beyond key ownership. +This is a general definition based on the legal definition which even simple +scripts using CSV would satisfy. Covenants in Bitcoin transactions usually +refer to restrictions on where coins can be transferred. Covenants can be +useful to construct smart contracts. Covenants have historically been widely +considered to be unfit for Bitcoin because they are too complex to implement +and risk reducing the fungibility of coins bound by them. -This BIP introduces a simple covenant called a *template* which enables a limited set of highly -valuable use cases without significant risk. +This BIP introduces a simple covenant called a *template* which enables a +limited set of highly valuable use cases without significant risk. BIP-119 +templates allow for '''non-recursive''' fully-enumerated covenants with no dynamic +state. CTV serves as a replacement for a pre-signed transaction oracle, which +eliminates the trust and interactivity requirements. Examples of uses include +vaults, non-interactive payment channel creation, congestion controlled +batching, efficient to construct discreet log contracts, and payment pools, +among many others. For more details on these applications, please see the +references. -A few examples are described below, which should be the subject of future non-consensus -standardization efforts. - -===Congestion Controlled Transactions=== - -When there is a high demand for blockspace it becomes very expensive to make transactions. A large -volume payment processor may aggregate all their payments into a single O(1) transaction commitment -for purposes of confirmation using CHECKTEMPLATEVERIFY. Then, some time later, the payments can -be expanded out of that UTXO when the demand for blockspace is decreased. These payments can be -structured in a tree-like fashion to reduce individual costs of redemption. - -The below chart showcases the structure of these transactions in comparison to -normal transactions and batched transactions. - - - -A simulation is shown below of what impact this could have on mempool backlog -given 5% network adoption, and 50% network adoption. The code for the simulation -is provided in this BIP's subdirectory. - - - - -===Payment Channels=== - -There are numerous payment channel related uses. - -====Batched Channel Creation==== - -Using CHECKTEMPLATEVERIFY for Batched Channel Creation is similar to the use for Congestion Control, -except the leaf node transactions are channels instead of plain payments. The channel can be between -the sender and recipient or a target of recipient's choice. Using an CHECKTEMPLATEVERIFY, the -recipient may give the sender an address which makes a tree of channels unbeknownst to them. -These channels are time insensitive for setup, as all punishments are relative timelocked to the -penultimate transaction node. -Thus, coins sent using a congestion controlled transaction can still enjoy instant liquidity. - -====Non-Interactive Channels==== - -When opening a traditional payment channel, both parties to the channel must participate. This is -because the channel uses pre-signed multi-sig transactions to ensure that a channel can always be -exited by either party, before entering. -With CHECKTEMPLATEVERIFY, it’s possible for a single party to construct a channel which either -party can exit from without requiring signatures from both parties. -These payment channels can operate in one direction, paying to the channel "listener" without need -for their private key to be online. - - -====Increased Channel Routes==== - -In the Lightning Network protocol, Hashed Time Locked Contracts (HTLCS) are used in the construction -of channels. A new HTLC is required per route that the channel is serving in. -In BOLT #2, this maximum number of HTLCs in a channel is hard limited to 483 as the maximum safe -size to prevent the transaction from being too large to be valid. In common software implementations -such as LND, this limit is set much lower to 12 HTLCS. This is because accepting a larger number of -HTLCS makes it more difficult for transactions to confirm during congested periods as they must pay -higher fees. -Therefore, similarly to how congestion control is handled for normal transaction, lightning channel -updates can be done across an CHECKTEMPLATEVERIFY tree, allowing nodes to safely use many more -HTLCS. -Because each HTLC can have its own relative time lock in the tree, this also improves the latency -sensitivity of the lightning protocol on contested channel close. - -===Wallet Vaults=== - -This section will detail two variants of wallet vault that can be built using -CTV. Wallet vaults are a useful tool when greater security is required for -cold storage solutions, providing default transactional paths that move funds -from one's cold storage to a hot wallet. - -One type of cold wallet can be set up such that a customer support desk can, -without further authorization, move a portion of the funds (using multiple -pre-set amounts) into a lukewarm wallet operated by an isolated support desk. -The support desk can then issue some funds to a hot wallet, and send the -remainder back to cold storage with a similar withdrawal mechanism in place. -This is all possible without CHECKTEMPLATEVERIFY, but CHECKTEMPLATEVERIFY -eliminates the need for coordination and online signers, as well as reducing -the ability for a support desk to improperly move funds. Furthermore, all such -designs can be combined with relative time locks to give time for compliance -and risk desks to intervene. This is a 'Coins at Rest' or 'Optically Isolated' -vault, and is shown below. - - - -An alternative design for vaults is also highly effective and simpler to -implement in Sapio, a smart contract programming language. In this design, the -user commits to a single UTXO that contains a program for an annuity of -withdrawals from cold storage to a hot wallet. At any time, the remaining -balance for the annuity can be cancelled and funds locked entirely in cold -storage. The withdrawals to the hot wallet can be 'cancelled' before a maturity -date to ensure the action was authorized. These sort of vaults strongly benefit -from non-interactivity because the withdrawal program can be set up with cold -keys that are permanently offline, except in case of emergency. The image below -shows an instance of this type of wallet vault created with Sapio in Sapio -Studio. These types of wallet vault can also be chained together by taking -advantage of CTV's scriptSig commitment. This type of vault is a 'Coins in Motion' -variant where the coins move along the control path. - - - -===CoinJoin / Payment Pools / Join Pools === - -CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins than -previously because participants agree on a single output which pays all -participants, which will be lower fee than before. Further each participant -doesn't need to know the totality of the outputs committed to by that output, -they only have to verify their own sub-tree will pay them. These trees can -then, using a top-level Schnorr key, be interactively updated on a rolling basis -forming a "Payment Pool". ==Detailed Specification== The below code is the main logic for verifying CHECKTEMPLATEVERIFY, described -in pythonic pseduocode. The canonical specification for the semantics of +in pythonic pseudocode. The canonical specification for the semantics of OP_CHECKTEMPLATEVERIFY as implemented in C++ in the context of Bitcoin Core can be seen in the reference implementation. The execution of the opcode is as follows: - def execute_bip_119(self): - # Before soft-fork activation / failed activation - if not self.flags.script_verify_default_check_template_verify_hash: - # Potentially set for node-local policy to discourage premature use - if self.flags.script_verify_discourage_upgradable_nops: - return self.errors_with(errors.script_err_discourage_upgradable_nops) - return self.return_as_nop() - # CTV always requires at least one stack argument - if len(self.stack) < 1: - return self.errors_with(errors.script_err_invalid_stack_operation) - # CTV only verifies the hash against a 32 byte argument - if len(self.stack[-1]) == 32: - # Ensure the precomputed data required for anti-DoS is available, - # or cache it on first use - if self.context.precomputed_ctv_data == None: - self.context.precomputed_ctv_data = self.context.tx.get_default_check_template_precomputed_data() - if stack[-1] != self.context.tx.get_default_check_template_hash(self.context.nIn, self.context.precomputed_ctv_data) - return self.errors_with(errors.script_err_template_mismatch) - return self.return_as_nop() - # future upgrade can add semantics for this opcode with different length args - # so discourage use when applicable + +def execute_bip_119(self): + # Before soft-fork activation / failed activation + # continue to treat as NOP4 + if not self.flags.script_verify_default_check_template_verify_hash: + # Potentially set for node-local policy to discourage premature use if self.flags.script_verify_discourage_upgradable_nops: return self.errors_with(errors.script_err_discourage_upgradable_nops) - else: - return self.return_as_nop() + return self.return_as_nop() + + # CTV always requires at least one stack argument + if len(self.stack) < 1: + return self.errors_with(errors.script_err_invalid_stack_operation) + + # CTV only verifies the hash against a 32 byte argument + if len(self.stack[-1]) == 32: + # Ensure the precomputed data required for anti-DoS is available, + # or cache it on first use + if self.context.precomputed_ctv_data == None: + self.context.precomputed_ctv_data = self.context.tx.get_default_check_template_precomputed_data() + + # If the hashes do not match, return error + if stack[-1] != self.context.tx.get_default_check_template_hash(self.context.nIn, self.context.precomputed_ctv_data): + return self.errors_with(errors.script_err_template_mismatch) + + return self.return_as_nop() + + # future upgrade can add semantics for this opcode with different length args + # so discourage use when applicable + if self.flags.script_verify_discourage_upgradable_nops: + return self.errors_with(errors.script_err_discourage_upgradable_nops) + else: + return self.return_as_nop() + The computation of this hash can be implemented as specified below (where self is the transaction type). Care must be taken that in any validation context, @@ -202,46 +111,80 @@ including hashes of the scriptsigs, sequences, and outputs. See the section "Denial of Service and Validation Costs" below. This is not a performance optimization. - def get_default_check_template_precomputed_data(self): - result = {} - # If there are no scriptSigs we do not need to precompute a hash - if any(inp.scriptSig for inp in self.vin): - result["scriptSigs"] = sha256(b"".join(ser_string(inp.scriptSig) for inp in self.vin)) - # The same value is also pre-computed for and defined in BIP-341 and can be shared - result["sequences"] = sha256(b"".join(struct.pack(" - # parameter precomputed must be passed in for DoS resistance - def get_default_check_template_hash(self, nIn, precomputed = None): - if precomputed == None: - precomputed = self.get_default_check_template_precomputed_data() +def ser_compact_size(l): + r = b"" + if l < 253: + # Serialize as unsigned char + r = struct.pack("B", l) + elif l < 0x10000: + # Serialize as unsigned char 253 followed by unsigned 2 byte integer (little endian) + r = struct.pack(" A PayToBareDefaultCheckTemplateVerifyHash output matches the following template: - # Extra-fast test for pay-to-basic-standard-template CScripts: - def is_pay_to_bare_default_check_template_verify_hash(self): - return len(self) == 34 and self[0] == 0x20 and self[-1] == OP_CHECKTEMPLATEVERIFY + +# Extra-fast test for pay-to-basic-standard-template CScripts: +def is_pay_to_bare_default_check_template_verify_hash(self): + return len(self) == 34 and self[0] == 0x20 and self[-1] == OP_CHECKTEMPLATEVERIFY + ==Deployment== @@ -250,7 +193,7 @@ Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial. The Bitcoin Core reference implementation includes the below parameters, configured to match Speedy Trial, as that is the current activation mechanism implemented in Bitcoin Core. Should another method become favored by the wider -Bitcoin comminity, that might be used instead. +Bitcoin community, that might be used instead. The start time and bit in the implementation are currently set to bit 5 and NEVER_ACTIVE/NO_TIMEOUT, but this is subject to change while the BIP is a draft. @@ -263,7 +206,7 @@ For the avoidance of unclarity, the parameters to be determined are: consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].nTimeout = Consensus::BIP9Deployment::NO_TIMEOUT; consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].min_activation_height = 0; -Until BIP-119 reaches ACTIVE state and the +Until BIP-119 reaches ACTIVE state and the SCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH flag is enforced, node implementations should (are recommended to) execute a NOP4 as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS (to deny entry to the mempool) for policy and must evaluate as a NOP for consensus (during block validation). @@ -283,12 +226,12 @@ A recent commit hash in that PR including tests and vectors can be found here ht Once the PR is merged, this BIP should be updated to point to the specific code released. Test vectors are available in [/bip-0119/vectors the bip-0119/vectors -directory] for checking compatibility with the refrence implementation and BIP. +directory] for checking compatibility with the reference implementation and BIP. ==Rationale== The goal of CHECKTEMPLATEVERIFY is to be minimal impact on the existing codebase -- in the -future, as we become aware of more complex but shown to be safe use cases new template types can be added. +future, as we become aware of more complex but shown to be safe use cases, new template types can be added. Below we'll discuss the rules one-by-one: @@ -296,7 +239,7 @@ Below we'll discuss the rules one-by-one: The set of data committed to is a superset of data which can impact the TXID of the transaction, other than the inputs. This ensures that for a given known input, the TXIDs can also be known ahead -of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched Channel Creation constructions +of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched Channel Creation constructions as the redemption TXID could be malleated and pre-signed transactions invalidated, unless the channels are built using an Eltoo-like protocol. Note that there may be other types of pre-signed contracts that may or may not be able to use Eltoo-like constructs, therefore making TXIDs predictable makes CTV more @@ -308,7 +251,7 @@ Were these values not committed, it would be possible to delay the spending of an output arbitrarily as well as possible to change the TXID. Committing these values, rather than restricting them to specific values, is -more flexible as it permits users of CHECKTEMPLATEVERIFY the set the version and +more flexible as it permits users of CHECKTEMPLATEVERIFY to set the version and locktime as they please. =====Committing to the ScriptSigs Hash===== @@ -316,7 +259,7 @@ locktime as they please. The scriptsig in a segwit transaction must be exactly empty, unless it is a P2SH segwit transaction in which case it must be only the exact redeemscript. P2SH is incompatible (unless the P2SH hash is broken) with CHECKTEMPLATEVERIFY because the template hash must commit -to the ScriptSig, which must contain the redeemscript, which is a hash cycle. +to the ScriptSig, which must contain the redeemscript, which is a hash cycle. To prevent malleability when not using a segwit input, we also commit to the scriptsig. This makes it possible to use a 2 input CHECKTEMPLATEVERIFY with a legacy pre-signed @@ -371,7 +314,7 @@ We treat the number of inputs as a `uint32_t` because Bitcoin's consensus decodi to `MAX_SIZE=33554432` and that is larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also friendly for manipulation using Bitcoin's current math opcodes, should `OP_CAT` be added. Note that the max inputs in a block is further restricted by the block size to around 25,000, which would fit -into a `uint16_t`, but that is an uneccessary abstraction leak. +into a `uint16_t`, but that is an unnecessary abstraction leak. =====Committing to the Sequences Hash===== @@ -419,7 +362,7 @@ scripts cannot be spent at the same index, which implies that they cannot be spe This makes it safer to design wallet vault contracts without half-spend vulnerabilities. Committing to the current index doesn't prevent one from expressing a CHECKTEMPLATEVERIFY which can -be spent at multiple indicies. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped +be spent at multiple indices. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped in an OP_IF for each index (or Tapscript branches in the future). If OP_CAT or OP_SHA256STREAM are added to Bitcoin, the index may simply be passed in by the witness before hashing. @@ -442,7 +385,7 @@ programs. RIPEMD160, a 20 byte hash, might also be a viable hash in some contexts and has some benefits. For fee efficiency, RIPEMD160 saves 12 bytes. However, RIPEMD160 was not chosen for BIP-119 because it introduces -risks around the verification of programs created by third parties to be subject to a +risks around the verification of programs created by third parties to be subject to a [birthday-attack https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh] on transaction preimages. @@ -533,7 +476,7 @@ An example of a script that could experience an DoS issue without caching is: CTV CTV CTV... CTV -Such a script would cause the intepreter to compute hashes (supposing N CTV's) over O(N*T) data. +Such a script would cause the interpreter to compute hashes (supposing N CTV's) over O(N*T) data. If the scriptSigs non-nullity is not cached, then the O(T) transaction could be scanned over O(N) times as well (although cheaper than hashing, still a DoS). As such, CTV caches hashes and computations over all variable length fields in a transaction. @@ -624,11 +567,11 @@ CHECKTEMPLATEVERIFY has benefits in terms of script size (depending on choice of PK, SIGHASH_ANYPREVOUTANYSCRIPT may use about 2x-3x the bytes) and verification speed, as OP_CHECKTEMPLATEVERIFY requires only hash computation rather than signature operations. This can be significant when constructing large payment -trees or programmatic compilations. CHECKTEMPLATEVERIFY also has a feature-wise +trees or programmatic compilations. CHECKTEMPLATEVERIFY also has a feature-wise benefit in that it provides a robust pathway for future template upgrades. OP_CHECKSIGFROMSTACKVERIFY along with OP_CAT may also be used to emulate -CHECKTEMPLATEVERIFY. However such constructions are more complicated to use +CHECKTEMPLATEVERIFY. However such constructions are more complicated to use than CHECKTEMPLATEVERIFY, and encumbers additional verification overhead absent from CHECKTEMPLATEVERIFY. These types of covenants also bear similar potential recursion issues to OP_COV which make it unlikely for inclusion in Bitcoin. @@ -646,7 +589,7 @@ the future as well as synergies with other possible upgrades. =====CHECKTEMPLATEVERIFY Versions===== OP_CHECKTEMPLATEVERIFY currently only verifies properties of 32 byte arguments. -In the future, meaning could be ascribed to other length arguments. For +In the future, meaning could be ascribed to other length arguments. For example, a 33-byte argument could just the last byte as a control program. In that case, DefaultCheckTemplateVerifyHash could be computed when the flag byte is set to CTVHASH_ALL. Other programs could be added similar to SIGHASH_TYPEs. @@ -673,7 +616,7 @@ sponsors might be considered. An opcode which verifies the exact amount that is being spent in the transaction, the amount paid as fees, or made available in a given output could -be used to make safer OP_CHECKTEMPLATEVERIFY addressses. For instance, if the +be used to make safer OP_CHECKTEMPLATEVERIFY addresses. For instance, if the OP_CHECKTEMPLATEVERIFY program P expects exactly S satoshis, sending S-1 satoshis would result in a frozen UTXO and sending S+n satoshis would result in n satoshis being paid to fee. A range check could restrict the program to only @@ -725,6 +668,14 @@ for older node versions that can be patched but not upgraded to a newer major re *[https://fc16.ifca.ai/bitcoin/papers/MES16.pdf Bitcoin Covenants] *[https://bitcointalk.org/index.php?topic=278122.0 CoinCovenants using SCIP signatures, an amusingly bad idea.] *[https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf Enhancing Bitcoin Transactions with Covenants] +*[https://github.com/jamesob/simple-ctv-vault Simple CTV Vaults] +*[https://github.com/kanzure/python-vaults Python Vaults] +*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html CTV Dramatically Improves DLCs] +*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020225.html Calculus of Covenants] +*[https://rubin.io/bitcoin/2021/12/10/advent-13/ Payment Pools with CTV] +*[https://rubin.io/bitcoin/2021/12/11/advent-14/ Channels with CTV] +*[https://rubin.io/bitcoin/2021/12/09/advent-12/ Congestion Control with CTV] +*[https://rubin.io/bitcoin/2021/12/07/advent-10/ Building Vaults on Bitcoin] ===Note on Similar Alternatives=== diff --git a/bip-0126.mediawiki b/bip-0126.mediawiki index f498b1cb..2c04eb45 100644 --- a/bip-0126.mediawiki +++ b/bip-0126.mediawiki @@ -14,7 +14,7 @@ When a Bitcoin transaction contains inputs that reference previous transaction outputs sent to different Bitcoin addresses, personally identifiable information of the user will leak into the blockchain in an uncontrolled manner. While undesirable, these transactions are frequently unavoidable due to the natural fragmentation of wallet balances over time. -This document proposes a set of best practice guidelines which minimize the uncontrolled disclosure of personally identifiable information by defining standard forms for transactions containing heterogenous input scripts. +This document proposes a set of best practice guidelines which minimize the uncontrolled disclosure of personally identifiable information by defining standard forms for transactions containing heterogeneous input scripts. ==Copyright== @@ -23,8 +23,8 @@ This BIP is in the public domain. ==Definitions== * '''Heterogenous input script transaction (HIT)''': A transaction containing multiple inputs where the scripts of the previous transaction outputs being consumed are not identical (e.g. a transaction spending outputs which were sent to more than one Bitcoin address) -* '''Unavoidable heterogenous input script transaction''': A HIT created as a result of a user’s desire to create a new output with a value larger than the value of his wallet's largest existing unspent output -* '''Intentional heterogenous input script transaction''': A HIT created as part of a user protection protocol for reducing uncontrolled disclosure of personally-identifying information (PII) +* '''Unavoidable heterogeneous input script transaction''': A HIT created as a result of a user’s desire to create a new output with a value larger than the value of his wallet's largest existing unspent output +* '''Intentional heterogeneous input script transaction''': A HIT created as part of a user protection protocol for reducing uncontrolled disclosure of personally-identifying information (PII) Throughout this procedure, when input scripts are evaluated for uniqueness, "input script" should be interpreted to mean, "the script of the previous output referenced by an input to a transaction". @@ -33,10 +33,10 @@ Throughout this procedure, when input scripts are evaluated for uniqueness, "inp The recommendations in this document are designed to accomplish three goals: # Maximise the effectiveness of user-protecting protocols: Users may find that protection protocols are counterproductive if such transactions have a distinctive fingerprint which renders them ineffective. -# Minimise the adverse consequences of unavoidable heterogenous input transactions: If unavoidable HITs are indistinguishable from intentional HITs, a user creating an unavoidable HIT benefits from ambiguity with respect to graph analysis. +# Minimise the adverse consequences of unavoidable heterogeneous input transactions: If unavoidable HITs are indistinguishable from intentional HITs, a user creating an unavoidable HIT benefits from ambiguity with respect to graph analysis. # Limiting the effect on UTXO set growth: To date, non-standardized intentional HITs tend to increase the network's UTXO set with each transaction; this standard attempts to minimize this effect by standardizing unavoidable and intentional HITs to limit UTXO set growth. -In order to achieve these goals, this specification proposes a set of best practices for heterogenous input script transaction creation. These practices accommodate all applicable requirements of both intentional and unavoidable HITs while maximising the effectiveness of both in terms of preventing uncontrolled disclosure of PII. +In order to achieve these goals, this specification proposes a set of best practices for heterogeneous input script transaction creation. These practices accommodate all applicable requirements of both intentional and unavoidable HITs while maximising the effectiveness of both in terms of preventing uncontrolled disclosure of PII. In order to achieve this, two forms of HIT are proposed: Standard form and alternate form. @@ -44,13 +44,13 @@ In order to achieve this, two forms of HIT are proposed: Standard form and alter Applications which wish to comply both with this procedure and BIP69 should apply this procedure prior to applying BIP69. -==Standard form heterogenous input script transaction== +==Standard form heterogeneous input script transaction== ===Rules=== A HIT is Standard form if it adheres to all of the following rules: -# The number of unique output scripts must be equal to the number of unique inputs scripts (irrespective of the number of inputs and outputs). +# The number of unique output scripts must be equal to the number of unique input scripts (irrespective of the number of inputs and outputs). # All output scripts must be unique. # At least one pair of outputs must be of equal value. # The largest output in the transaction is a member of a set containing at least two identically-sized outputs. @@ -63,7 +63,7 @@ The requirement that all output scripts are unique prevents address reuse. Restr The requirement for at least one pair of outputs in an intentional HIT to be of equal value results in optimal behavior, and causes intentional HITs to resemble unavoidable HITs. -==Alternate form heterogenous input script transactions== +==Alternate form heterogeneous input script transactions== The formation of a standard form HIT is not possible in the following cases: @@ -88,7 +88,7 @@ Clients which create intentional HITs must have the capability to form alternate An HIT formed via the preceding procedure will adhere to the following conditions: -# The number of unique inputs scripts must exceed the number of output scripts. +# The number of unique input scripts must exceed the number of output scripts. # All output scripts must be unique. # At least one pair of outputs must be of equal value. ## "Standard outputs" refers to the set of outputs with equal value @@ -100,7 +100,7 @@ An HIT formed via the preceding procedure will adhere to the following condition ## The sum of the inputs in the set minus the value of the change output is equal to the standard value with a tolerance equal to the transaction fee. ## Change outputs with a value of zero (virtual change outputs) are permitted. The are defined for the purpose of testing whether or not a HIT adheres to this specification but are not present in the version of the transaction which is broadcast to the network. -==Non-compliant heterogenous input script transactions== +==Non-compliant heterogeneous input script transactions== If a user wishes to create an output that is larger than half the total size of their spendable outputs, or if their inputs are not distributed in a manner in which the alternate form procedure can be completed, then the user can not create a transaction which is compliant with this procedure. diff --git a/bip-0127.mediawiki b/bip-0127.mediawiki index 15c7755f..87071d8e 100644 --- a/bip-0127.mediawiki +++ b/bip-0127.mediawiki @@ -124,7 +124,7 @@ message FinalProof { // Bitcoin transaction. bytes proof_tx = 1; - // The metadata of the ouputs used in the proof transaction. + // The metadata of the outputs used in the proof transaction. repeated OutputMeta output_metadata = 2; } @@ -219,6 +219,7 @@ A work-in-progress implementation of a tool that produces and verifies proofs in the described format can be found here: https://github.com/stevenroose/reserves +An implementation of the custom proof PSBTs is part of the [https://bitcoindevkit.org/ BDK], and can be found here: https://crates.io/crates/bdk-reserves == Footnotes == diff --git a/bip-0129.mediawiki b/bip-0129.mediawiki index 8719fe42..b5dfae82 100644 --- a/bip-0129.mediawiki +++ b/bip-0129.mediawiki @@ -47,11 +47,14 @@ Concerns #4 and #5 should be handled by Signers and are out of scope of this pro ==Specification== ===Prerequisites=== -This proposal assumes the parties in the multisig support [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032], [https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322], [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] and [https://tools.ietf.org/html/rfc3686 AES encryption]. +This proposal assumes the parties in the multisig support [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032], [https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322], [https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki BIP-0380 Output Script Descriptors] ([https://github.com/bitcoin/bips/blob/master/bip-0381.mediawiki BIP-0381],[https://github.com/bitcoin/bips/blob/master/bip-0382.mediawiki BIP-0382],[https://github.com/bitcoin/bips/blob/master/bip-0383.mediawiki BIP-0383]) and [https://tools.ietf.org/html/rfc3686 AES encryption]. ===File Extensions=== All descriptor and key records should have a .bsms file extension. Encrypted data should have a .dat extension. +===Newline=== +This specification uses line feed (LF) control character \n. + ===Roles=== ====Coordinator==== @@ -141,7 +144,7 @@ Whereas: * Password = "No SPOF" * Salt = TOKEN * c = 2048 -* dkLen = 256 +* dkLen = 256 bits (32 bytes) * DKey = Derived ENCRYPTION_KEY ====Encryption Scheme==== @@ -452,7 +455,7 @@ sh(wsh(multi(2,[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC2 ==Acknowledgement== -Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael Flaxman, Pieter Wuille, Salvatore Ingala, Andrew Chow and others for their feedback on the specification. +Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael Flaxman, Pieter Wuille, Salvatore Ingala, Ava Chow and others for their feedback on the specification. ==References== diff --git a/bip-0132.mediawiki b/bip-0132.mediawiki index e7aed292..173c9198 100644 --- a/bip-0132.mediawiki +++ b/bip-0132.mediawiki @@ -48,7 +48,7 @@ The author doesn't believe this is a problem because a BIP cannot be forced on c == Process == -* '''Submit for Comments.''' The first BIP champion named in the proposal can call a "submit for comments" at any time by posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Dev Mailing List] mailling with the BIP number and a statement that the champion intends to immediately submit the BIP for comments. +* '''Submit for Comments.''' The first BIP champion named in the proposal can call a "submit for comments" at any time by posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Dev Mailing List] mailing with the BIP number and a statement that the champion intends to immediately submit the BIP for comments. ** The BIP must have been assigned BIP-number (i.e. been approved by the BIP editor) to be submitted for comments. * '''Comments.''' ** After a BIP has been submitted for comments, a two-week waiting period begins in which the community should transition from making suggestions about a proposal to publishing their opinions or concerns on the proposal. diff --git a/bip-0133.mediawiki b/bip-0133.mediawiki index c109f12f..b37370d9 100644 --- a/bip-0133.mediawiki +++ b/bip-0133.mediawiki @@ -5,7 +5,7 @@ Author: Alex Morcos Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0133 - Status: Draft + Status: Final Type: Standards Track Created: 2016-02-13 License: PD diff --git a/bip-0135.mediawiki b/bip-0135.mediawiki index 1324746d..a4c06472 100644 --- a/bip-0135.mediawiki +++ b/bip-0135.mediawiki @@ -170,7 +170,7 @@ A given deployment SHALL remain in the DEFINED state until it either passes the starttime (and becomes STARTED) or the timeout time (and becomes FAILED). Once a deployment has STARTED, the signal for that deployment SHALL be tallied -over the the past windowsize blocks whenever a new block is received on that +over the past windowsize blocks whenever a new block is received on that chain. A transition from the STARTED state to the LOCKED_IN state SHALL only occur @@ -183,7 +183,7 @@ when all of these are true: A similar height synchronization precondition SHALL exist for the transition from LOCKED_IN to ACTIVE. These synchronization conditions are expressed by the "mod(height, windowsize) = 0" -clauses in the diagram, and have been been added so that backward compatibility +clauses in the diagram, and have been added so that backward compatibility with BIP9's use of the 2016-block re-targeting periods can be configured for existing deployments (see above 'Optional full backward compatibility' section). @@ -261,7 +261,7 @@ proposal, although a conventional fallow period of 3 months is RECOMMENDED. Due to the constraints set by BIP 34, BIP 66 and BIP 65, there are only 0x7FFFFFFB possible nVersion values available. This limits to at most 30 independent deployments. -By restricting the top 3 bits to 001 we we are left with 29 out of those for +By restricting the top 3 bits to 001 we are left with 29 out of those for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011). diff --git a/bip-0137.mediawiki b/bip-0137.mediawiki index 19dd5364..ccba17fc 100644 --- a/bip-0137.mediawiki +++ b/bip-0137.mediawiki @@ -15,7 +15,7 @@ This document describes a signature format for signing messages with Bitcoin private keys. -The specification is intended to describe the standard for signatures of messages that can be signed and verfied between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme. +The specification is intended to describe the standard for signatures of messages that can be signed and verified between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme. One of the key problems in this area is that there are several different types of Bitcoin addresses and without introducing specific standards it is unclear which type of address format is being used. See [2]. This BIP will attempt to address these issues and define a clear and concise format for Bitcoin signatures. @@ -25,7 +25,7 @@ This BIP is licensed under the 2-clause BSD license. ==Motivation== -Since Bitcoin private keys can not only be used to sign Bitcoin transactions, but also any other message, it has become customary to use them to sign various messages for differing purposes. Some applications of signing messages with a Bitcoin private key are as follows: proof of funds for collateral, credit worthiness, enterence to events, airdrops, audits as well as other applications. While there was no BIP written for how to digitally sign messages with Bitcoin private keys with P2PKH addresses it is a fairly well understood process, however with the introduction of Segwit (both in the form of P2SH and bech32) addresses, it is unclear how to distinguish a P2PKH, P2SH, or bech32 address from one another. This BIP proposes a standard signature format that will allow clients to distinguish between the different address formats. +Since Bitcoin private keys can not only be used to sign Bitcoin transactions, but also any other message, it has become customary to use them to sign various messages for differing purposes. Some applications of signing messages with a Bitcoin private key are as follows: proof of funds for collateral, credit worthiness, entrance to events, airdrops, audits as well as other applications. While there was no BIP written for how to digitally sign messages with Bitcoin private keys with P2PKH addresses it is a fairly well understood process, however with the introduction of Segwit (both in the form of P2SH and bech32) addresses, it is unclear how to distinguish a P2PKH, P2SH, or bech32 address from one another. This BIP proposes a standard signature format that will allow clients to distinguish between the different address formats. ==Specification== @@ -116,7 +116,7 @@ Since this format includes P2PKH keys, it is backwards compatible, but keep in m ==Implications== -Message signing is an important use case and potentially underused due to the fact that, up until now, there has not been a formal specification for how wallets can sign messages using Bitcoin private keys. Bitcoin wallets should be interoperable and use the same conventions for determing a signature's validity. This BIP can also be updated as new signature formats emerge. +Message signing is an important use case and potentially underused due to the fact that, up until now, there has not been a formal specification for how wallets can sign messages using Bitcoin private keys. Bitcoin wallets should be interoperable and use the same conventions for determining a signature's validity. This BIP can also be updated as new signature formats emerge. ==Acknowledgements== diff --git a/bip-0140.mediawiki b/bip-0140.mediawiki index 88131f49..c8f22f78 100644 --- a/bip-0140.mediawiki +++ b/bip-0140.mediawiki @@ -62,7 +62,7 @@ This is the standard ''m-of-n'' script defined in [https://github.com/bitcoin/bi The existing OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY have a bug[[https://bitcoin.org/en/developer-guide#multisig|Developer Documentation - Multisig]] that pops one argument too many from the stack. This bug is not reproduced in the implementation of OP_CHECKSIGEX, so the canonical solution of pushing a dummy value onto the stack is not necessary. The normalization is achieved by normalizing the transaction before computing the signaturehash, i.e., the hash that is signed. -The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures. +The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transaction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures. === Tracking Normalized Transaction IDs === diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 85287296..117ca59d 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -56,7 +56,7 @@ The marker MUST be a 1-byte zero value: 0x00. The flag MUST be a 1-byte non-zero value. Currently, 0x01 MUST be used. -The witness is a serialization of all witness data of the transaction. Each txin is associated with a witness field. A witness field starts with a var_int to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a var_int to indicate the length. Witness data is NOT script. +The witness is a serialization of all witness fields of the transaction. Each txin is associated with a witness field. A witness field starts with a var_int to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a var_int to indicate the length. Witness data is NOT script. A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a 0x00. If all txins are not witness program, a transaction's wtxid is equal to its txid. @@ -83,19 +83,23 @@ If all transactions in a block do not have witness data, the commitment is optio === Witness program === -A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 40 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program". +A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (one of OP_0,OP_1,OP_2,...,OP_16) followed by a direct data push between 2 and 40 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program". +In more detail, this means a scriptPubKey or redeemScript which consists of (in order): +* First, byte 0x00 (OP_0) or any byte between 0x51 (OP_1) and 0x60 (OP_16) inclusive (the version byte). +* Then, a byte ''L'' between 0x02 (push of 2 bytes) and 0x28 (push of 40 bytes) inclusive. +* Finally, ''L'' arbitrary bytes (the witness program). There are two cases in which witness validation logic are triggered. Each case determines the location of the witness version byte and program, as well as the form of the scriptSig: # Triggered by a scriptPubKey that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty or validation fails. (''"native witness program"'') # Triggered when a scriptPubKey is a P2SH script, and the BIP16 redeemScript pushed in the scriptSig is exactly a push of a version byte plus a push of a witness program. The scriptSig must be exactly a push of the BIP16 redeemScript or validation fails. (''"P2SH witness program"'') -If the version byte is 0, and the witness program is 20 bytes: +If the version byte is 0, and the witness program is 20 bytes (''L = 20''): * It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program. * The witness must consist of exactly 2 items (≤ 520 bytes each). The first one a signature, and the second one a public key. * The HASH160 of the public key must match the 20-byte witness program. * After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack. -If the version byte is 0, and the witness program is 32 bytes: +If the version byte is 0, and the witness program is 32 bytes (''L = 32''): * It is interpreted as a pay-to-witness-script-hash (P2WSH) program. * The witness must consist of an input stack to feed to the script, followed by a serialized script (witnessScript). * The witnessScript (≤ 10,000 bytes) is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program. @@ -276,7 +280,7 @@ These commitments could be included in the extensible commitment structure throu Since a version byte is pushed before a witness program, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures. -Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity. +Examples of new script systems include Schnorr signatures, which reduce the size of multisig transactions dramatically; Lamport signatures, which are quantum computing resistant; and Merklized abstract syntax trees, which allow very compact witnesses for conditional scripts with extreme complexity. === Per-input lock-time and relative-lock-time === @@ -303,7 +307,7 @@ As a soft fork, older software will continue to operate without modification. N This BIP will be deployed by "version bits" BIP9 with the name "segwit" and using bit 1. -For Bitcoin mainnet, the BIP9 starttime will be midnight 15 november 2016 UTC (Epoch timestamp 1479168000) and BIP9 timeout will be midnight 15 november 2017 UTC (Epoch timestamp 1510704000). +For Bitcoin mainnet, the BIP9 starttime will be midnight 15 November 2016 UTC (Epoch timestamp 1479168000) and BIP9 timeout will be midnight 15 November 2017 UTC (Epoch timestamp 1510704000). For Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout will be midnight 1 May 2017 UTC (Epoch timestamp 1493596800). diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index 81763a07..9935eaa2 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -39,12 +39,12 @@ A new transaction digest algorithm is defined, but only applicable to sigops in 9. nLocktime of the transaction (4-byte little endian) 10. sighash type of the signature (4-byte little endian) -Semantics of the original sighash types remain unchanged, except the followings: +Semantics of the original sighash types remain unchanged, except the following: # The way of serialization is changed; # All sighash types commit to the amount being spent by the signed input; # FindAndDelete of the signature is not applied to the scriptCode; # OP_CODESEPARATOR(s) after the last executed OP_CODESEPARATOR are not removed from the scriptCode (the last executed OP_CODESEPARATOR and any script before it are always removed); -# SINGLE does not commit to the input index. When ANYONECANPAY is not set, the semantics are unchanged since hashPrevouts and outpoint together implictly commit to the input index. When SINGLE is used with ANYONECANPAY, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index. +# SINGLE does not commit to the input index. When ANYONECANPAY is not set, the semantics are unchanged since hashPrevouts and outpoint together implicitly commit to the input index. When SINGLE is used with ANYONECANPAY, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index. The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. @@ -187,7 +187,7 @@ To ensure consistency in consensus-critical behaviour, developers should test th nHashType: 01000000 sigHash: c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670 - signature: 304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee + signature: 304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000 @@ -551,7 +551,7 @@ These examples show that FindAndDelete for the signature is not app nLockTime: 00000000 The input comes from a P2WSH witness program: - scriptPubKey : 00209e1be07558ea5cc8e02ed1d80c0911048afad949affa36d5c3951e3159dbea19, value: 200000 + scriptPubKey : 00209e1be07558ea5cc8e02ed1d80c0911048afad949affa36d5c3951e3159dbea19, value: 0.00200000 redeemScript : OP_CHECKSIGVERIFY <0x30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> ad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01 diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index 005c5527..8bc11978 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -5,10 +5,11 @@ Author: Jonas Schnelli Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0151 - Status: Withdrawn + Status: Replaced Type: Standards Track Created: 2016-03-23 License: PD + Superseded-By: 324 == Abstract == @@ -84,7 +85,7 @@ a 64 bit nonce and a 64 bit counter into 64 bytes of output. This output is used Poly1305, also by Daniel Bernstein [4], is a one-time Carter-Wegman MAC that computes a 128 bit integrity tag given a message and a single-use 256 bit secret key. -The chacha20-poly1305@openssh.com specified and defined by openssh [5] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [6], but differs in the layout of data passed to the MAC and in the addition of encyption of the packet lengths. +The chacha20-poly1305@openssh.com specified and defined by openssh [5] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [6], but differs in the layout of data passed to the MAC and in the addition of encryption of the packet lengths. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index 8200714b..fad17460 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -211,7 +211,7 @@ There are several design goals for the Short ID calculation: SipHash is a secure, fast, and simple 64-bit MAC designed for network traffic authentication and collision-resistant hash tables. We truncate the output from SipHash-2-4 to 48 bits (see next section) in order to minimize space. The resulting 48-bit hash is certainly not large enough to avoid intentionally created individual collisons, but by using the block hash as a key to SipHash, an attacker cannot predict what keys will be used once their transactions are actually included in a relayed block. We mix in a per-connection 64-bit nonce to obtain independent short IDs on every connection, so that even block creators cannot control where collisions occur, and random collisions only ever affect a small number of connections at any given time. The mixing is done using SHA256(block_header || nonce), which is slow compared to SipHash, but only done once per block. It also adds the ability for nodes to choose the nonce in a better than random way to minimize collisions, though that is not necessary for correct behaviour. Conversely, nodes can also abuse this ability to increase their ability to introduce collisions in the blocks they relay themselves. However, they can already cause more problems by simply refusing to relay blocks. That is inevitable, and this design only seeks to prevent network-wide misbehavior. -====Random collision probabilty==== +====Random collision probability==== Thanks to the block-header-based SipHash keys, we can assume that the only collisions on links between honest nodes are random ones. diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki index 3e7b0d82..0ec68019 100644 --- a/bip-0155.mediawiki +++ b/bip-0155.mediawiki @@ -117,6 +117,11 @@ The list of reserved network IDs is as follows: | CJDNS | 16 | Cjdns overlay network address +|- +| 0x07 +| YGGDRASIL +| 16 +| Yggdrasil overlay network address |} Clients are RECOMMENDED to gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to. @@ -184,6 +189,10 @@ I2P addresses MUST be sent with the I2P network ID, with the decode Cjdns addresses are simply IPv6 addresses in the fc00::/8 range[https://github.com/cjdelisle/cjdns/blob/6e46fa41f5647d6b414612d9d63626b0b952746b/doc/Whitepaper.md#pulling-it-all-together Cjdns whitepaper: Pulling It All Together]. They MUST be sent with the CJDNS network ID. +==Appendix E: Yggdrasil address encoding== + +Yggdrasil addresses are simply IPv6 addresses in the 0200::/7 range[https://yggdrasil-network.github.io/faq.html#will-yggdrasil-conflict-with-my-network-routing Yggdrasil FAQ]. They MUST be sent with the YGGDRASIL network ID. + ==References== diff --git a/bip-0158.mediawiki b/bip-0158.mediawiki index 484e6747..1fadcc7a 100644 --- a/bip-0158.mediawiki +++ b/bip-0158.mediawiki @@ -39,9 +39,6 @@ that is designed to reduce the filter size for regular wallets. ''CompactSize'' is a compact encoding of unsigned integers used in the Bitcoin P2P protocol. -''Data pushes'' are byte vectors pushed to the stack according to the rules of -Bitcoin script. - ''Bit streams'' are readable and writable streams of individual bits. The following functions are used in the pseudocode in this document: * new_bit_stream instantiates a new writable bit stream @@ -85,7 +82,7 @@ one is able to select both Parameters independently, then more optimal values can be selectedhttps://gist.github.com/sipa/576d5f09c3b86c3b1b75598d799fc845. Set membership queries against the hash outputs will have a false positive rate -of M. To avoid integer overflow, the number of items N +of 1 / M. To avoid integer overflow, the number of items N MUST be <2^32 and M MUST be <2^32. The items are first passed through the pseudorandom function ''SipHash'', which @@ -189,7 +186,7 @@ golomb_decode(stream, P: uint) -> uint64: A GCS is constructed from four parameters: * L, a vector of N raw items * P, the bit parameter of the Golomb-Rice coding -* M, the target false positive rate +* M, the inverse of the target false positive rate * k, the 128-bit key used to randomize the SipHash outputs The result is a byte vector with a minimum size of N * (P + 1) @@ -273,10 +270,8 @@ This BIP defines one initial filter type: The basic filter is designed to contain everything that a light client needs to sync a regular Bitcoin wallet. A basic filter MUST contain exactly the following items for each transaction in a block: -* The previous output script (the script being spent) for each input, except - for the coinbase transaction. -* The scriptPubKey of each output, aside from all OP_RETURN output - scripts. +* The previous output script (the script being spent) for each input, except for the coinbase transaction. +* The scriptPubKey of each output, aside from all OP_RETURN output scripts. Any "nil" items MUST NOT be included into the final set of filter elements. @@ -314,6 +309,8 @@ complete serialization of a filter is: * N, encoded as a CompactSize * The bytes of the compressed filter itself +A zero element filter MUST be written as one byte containing zeroes. + ==== Signaling ==== This BIP allocates a new service bit: diff --git a/bip-0158/gentestvectors.go b/bip-0158/gentestvectors.go index 3435eb3c..2d11b144 100644 --- a/bip-0158/gentestvectors.go +++ b/bip-0158/gentestvectors.go @@ -37,7 +37,7 @@ var ( {49291, "Tx pays to empty output script"}, {180480, "Tx spends from empty output script"}, {926485, "Duplicate pushdata 913bcc2be49cb534c20474c4dee1e9c4c317e7eb"}, - {987876, "Coinbase tx has unparseable output script"}, + {987876, "Coinbase tx has unparsable output script"}, {1263442, "Includes witness data"}, {1414221, "Empty data"}, } @@ -207,7 +207,7 @@ func main() { prevOutputScripts, err := fetchPrevOutputScripts(client, block) if err != nil { - fmt.Println("Couldn't fetch prev output scipts: ", err) + fmt.Println("Couldn't fetch prev output scripts: ", err) return } diff --git a/bip-0173.mediawiki b/bip-0173.mediawiki index 1fdd8bed..7087fffa 100644 --- a/bip-0173.mediawiki +++ b/bip-0173.mediawiki @@ -11,6 +11,7 @@ Created: 2017-03-20 License: BSD-2-Clause Replaces: 142 + Superseded-By: 350 ==Introduction== @@ -403,3 +404,12 @@ separator). This document is inspired by the [https://rusty.ozlabs.org/?p=578 address proposal] by Rusty Russell, the [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-February/004402.html base32] proposal by Mark Friedenbach, and had input from Luke Dashjr, Johnson Lau, Eric Lombrozo, Peter Todd, and various other reviewers. + +==Disclosures (added 2024)== + +Due to an oversight in the design of bech32, this checksum scheme is not always +robust against +[[https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb|the insertion +and deletion of fewer than 5 consecutive characters]]. Due to this weakness, +[[bip-0350.mediawiki|BIP-350]] proposes using the scheme described in this BIP +only for Native Segwit v0 outputs. diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index f1decfd8..95a5573b 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -2,7 +2,7 @@ BIP: 174 Layer: Applications Title: Partially Signed Bitcoin Transaction Format - Author: Andrew Chow + Author: Ava Chow Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174 Status: Final @@ -98,7 +98,7 @@ The currently defined global types are as follows: | PSBT_GLOBAL_UNSIGNED_TX = 0x00 | None | No key data -| +| | The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses). | 0 | 2 @@ -107,9 +107,9 @@ The currently defined global types are as follows: |- | Extended Public Key | PSBT_GLOBAL_XPUB = 0x01 -| +| | The 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived. -| <32-bit uint> <32-bit uint>* +| <4 byte fingerprint> <32-bit little endian uint path element>* | The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key. | | @@ -120,7 +120,7 @@ The currently defined global types are as follows: | PSBT_GLOBAL_TX_VERSION = 0x02 | None | No key data -| <32-bit uint> +| <32-bit little endian int version> | The 32-bit little endian signed integer representing the version number of the transaction being created. Note that this is not the same as the PSBT version number specified by the PSBT_GLOBAL_VERSION field. | 2 | 0 @@ -131,7 +131,7 @@ The currently defined global types are as follows: | PSBT_GLOBAL_FALLBACK_LOCKTIME = 0x03 | None | No key data -| <32-bit uint> +| <32-bit little endian uint locktime> | The 32-bit little endian unsigned integer representing the transaction locktime to use if no inputs specify a required locktime. | | 0 @@ -142,7 +142,7 @@ The currently defined global types are as follows: | PSBT_GLOBAL_INPUT_COUNT = 0x04 | None | No key data -| +| | Compact size unsigned integer representing the number of inputs in this PSBT. | 2 | 0 @@ -153,7 +153,7 @@ The currently defined global types are as follows: | PSBT_GLOBAL_OUTPUT_COUNT = 0x05 | None | No key data -| +| | Compact size unsigned integer representing the number of outputs in this PSBT. | 2 | 0 @@ -164,7 +164,7 @@ The currently defined global types are as follows: | PSBT_GLOBAL_TX_MODIFIABLE = 0x06 | None | No key data -| <8-bit uint> +| <8-bit uint flags> | An 8 bit little endian unsigned integer as a bitfield for various transaction modification flags. Bit 0 is the Inputs Modifiable Flag and indicates whether inputs can be modified. Bit 1 is the Outputs Modifiable Flag and indicates whether outputs can be modified. Bit 2 is the Has SIGHASH_SINGLE flag and indicates whether the transaction has a SIGHASH_SINGLE signature who's input and output pairing must be preserved. Bit 2 essentially indicates that the Constructor must iterate the inputs to determine whether and how to add an input. | | 0 @@ -175,7 +175,7 @@ The currently defined global types are as follows: | PSBT_GLOBAL_VERSION = 0xFB | None | No key data -| <32-bit uint> +| <32-bit little endian uint version> | The 32-bit little endian unsigned integer representing the version number of this PSBT. If omitted, the version number is 0. | | @@ -184,9 +184,9 @@ The currently defined global types are as follows: |- | Proprietary Use Type | PSBT_GLOBAL_PROPRIETARY = 0xFC -| -| Compact size unsigned integer , followed by identifier prefix of that length , followed by a subtype , followed by the key data itself . -| +| +| Compact size unsigned integer of the length of the identifier, followed by identifier prefix, followed by a compact size unsigned integer subtype, followed by the key data itself. +| | Any value data as defined by the proprietary type user. | | @@ -212,7 +212,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_NON_WITNESS_UTXO = 0x00 | None | No key data -| +| | The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO. '''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. PSBT_IN_NON_WITNESS_UTXO) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting PSBT_IN_WITNESS_UTXO, both UTXO types must be allowed. | | @@ -223,7 +223,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_WITNESS_UTXO = 0x01 | None | No key data -| <64-bit int> +| <64-bit little endian int amount> | The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO | | @@ -232,9 +232,9 @@ The currently defined per-input types are defined as follows: |- | Partial Signature | PSBT_IN_PARTIAL_SIG = 0x02 -| +| | The public key which corresponds to this signature. -| +| | The signature as would be pushed to the stack from a scriptSig or witness. The signature should be a valid ECDSA signature corresponding to the pubkey that would return true when verified and not a value that would return false or be invalid otherwise (such as a NULLDUMMY). | | @@ -245,7 +245,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_SIGHASH_TYPE = 0x03 | None | No key data -| <32-bit uint> +| <32-bit little endian uint sighash type> | The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature. | | @@ -256,7 +256,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_REDEEM_SCRIPT = 0x04 | None | No key data -| +| | The redeemScript for this input if it has one. | | @@ -267,7 +267,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_WITNESS_SCRIPT = 0x05 | None | No key data -| +| | The witnessScript for this input if it has one. | | @@ -276,9 +276,9 @@ The currently defined per-input types are defined as follows: |- | BIP 32 Derivation Path | PSBT_IN_BIP32_DERIVATION = 0x06 -| +| | The public key -| <32-bit uint> <32-bit uint>* +| <4 byte fingerprint> <32-bit little endian uint path element>* | The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input. | | @@ -289,7 +289,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_FINAL_SCRIPTSIG = 0x07 | None | No key data -| +| | The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. | | @@ -300,7 +300,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_FINAL_SCRIPTWITNESS = 0x08 | None | No key data -| +| | The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. | | @@ -311,7 +311,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_POR_COMMITMENT = 0x09 | None | No key data -| +| | The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. | | @@ -322,7 +322,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_RIPEMD160 = 0x0a | <20-byte hash> | The resulting hash of the preimage -| +| | The hash preimage, encoded as a byte vector, which must equal the key when run through the RIPEMD160 algorithm | | @@ -333,7 +333,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_SHA256 = 0x0b | <32-byte hash> | The resulting hash of the preimage -| +| | The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm | | @@ -344,7 +344,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_HASH160 = 0x0c | <20-byte hash> | The resulting hash of the preimage -| +| | The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm followed by the RIPEMD160 algorithm | | @@ -355,7 +355,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_HASH256 = 0x0d | <32-byte hash> | The resulting hash of the preimage -| +| | The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm twice | | @@ -366,7 +366,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_PREVIOUS_TXID = 0x0e | None | No key data -| +| <32 byte txid> | 32 byte txid of the previous transaction whose output at PSBT_IN_OUTPUT_INDEX is being spent. | 2 | 0 @@ -377,7 +377,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_OUTPUT_INDEX = 0x0f | None | No key data -| <32-bit uint> +| <32-bit little endian uint index> | 32 bit little endian integer representing the index of the output being spent in the transaction with the txid of PSBT_IN_PREVIOUS_TXID. | 2 | 0 @@ -388,7 +388,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_SEQUENCE = 0x10 | None | No key data -| <32-bit uint> +| <32-bit little endian uint sequence> | The 32 bit unsigned little endian integer for the sequence number of this input. If omitted, the sequence number is assumed to be the final sequence number (0xffffffff). | | 0 @@ -399,7 +399,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x11 | None | No key data -| <32-bit uint> +| <32-bit little endian uint locktime> | 32 bit unsigned little endian integer greater than or equal to 500000000 representing the minimum Unix timestamp that this input requires to be set as the transaction's lock time. | | 0 @@ -410,7 +410,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x12 | None | No key data -| <32-bit uiht> +| <32-bit uint locktime> | 32 bit unsigned little endian integer less than 500000000 representing the minimum block height that this input requires to be set as the transaction's lock time. | | 0 @@ -421,7 +421,7 @@ The currently defined per-input types are defined as follows: | PSBT_IN_TAP_KEY_SIG = 0x13 | None | No key data -| +| <64 or 65 byte signature> | The 64 or 65 byte Schnorr signature for key path spending a Taproot output. Finalizers should remove this field after PSBT_IN_FINAL_SCRIPTWITNESS is constructed. | | @@ -430,9 +430,9 @@ The currently defined per-input types are defined as follows: |- | Taproot Script Spend Signature | PSBT_IN_TAP_SCRIPT_SIG = 0x14 -| +| <32 byte xonlypubkey> | A 32 byte X-only public key involved in a leaf script concatenated with the 32 byte hash of the leaf it is part of. -| +| <64 or 65 byte signature> | The 64 or 65 byte Schnorr signature for this pubkey and leaf combination. Finalizers should remove this field after PSBT_IN_FINAL_SCRIPTWITNESS is constructed. | | @@ -441,9 +441,9 @@ The currently defined per-input types are defined as follows: |- | Taproot Leaf Script | PSBT_IN_TAP_LEAF_SCRIPT = 0x15 -| +| | The control block for this leaf as specified in BIP 341. The control block contains the merkle tree path to this leaf. -|