bitcoin/bips
bitcoin/bips
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Compare commits

base: bitcoin:master
Branches Tags
bitcoin:master
bitcoin:gg
bitcoin:20170314-comments
bitcoin:staging
bitcoin:20160201_status_updates_d2f
bitcoin:2015_12_bip1
..
compare: bitcoin:20170314-comments
Branches Tags
bitcoin:master
bitcoin:gg
bitcoin:20170314-comments
bitcoin:staging
bitcoin:20160201_status_updates_d2f
bitcoin:2015_12_bip1

No commits in common. "master" and "20170314-comments" have entirely different histories.
master ... 20170314-c

496 changed files with 1462 additions and 90095 deletions
Show Stats Expand all files Collapse all files

1
.gitattributes vendored
View File

@ -1 +0,0 @@
*.mediawiki linguist-detectable

31
.github/workflows/github-action-checks.yml vendored
View File

@ -1,31 +0,0 @@
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@v5
- run: scripts/link-format-chk.sh
Build-Table-Checks:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- 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@v5
with:
fetch-depth: 2
- run: scripts/diffcheck.sh
Typo-Checks:
name: "Typo Checks"
runs-on: ubuntu-latest
steps:
- name: Checkout Actions Repository
uses: actions/checkout@v5
- name: Check spelling
uses: crate-ci/typos@master

6
.gitignore vendored
View File

@ -1,6 +0,0 @@
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

7
.travis.yml Normal file
View File

@ -0,0 +1,7 @@
os: linux
language: generic
sudo: false
script:
- 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

44
.typos.toml
View File

@ -1,44 +0,0 @@
[default]
extend-ignore-re = [
# NOTE: use here for regex patterns
"xpub.*",
"xprv.*",
"3.*", # address
"5.*", # address
"private_key .*",
"privkey .*",
"tt.*", # <tt> tags
"code.*", # <code> tags
"\\w*<sub>", # prefix for <sub> tags
"OP_SUCCESSx|\\d+",
"pay.*",
"ser.*",
"prefix.*",
"value: .*",
"pqNTRUsign",
"Strnad",
]
[default.extend-words]
# NOTE: use here for false-positives
anc = "anc"
PSBT = "PSBT"
ser = "ser"
# Names
Atack = "Atack"
Falke = "Falke"
Meni = "Meni"
Ono = "Ono"
Toom = "Toom"
[files]
extend-exclude = [
"/*/*.csv",
"/*/*.d*",
"/*/*.go",
"/*/*.json",
"/*/*/*.json",
"/*/*/*/*/*/*.o",
"/*/*/*/*/*/*/*/*.o",
"/*/*.t*",
]

12
CONTRIBUTING.md
View File

@ -1,12 +0,0 @@
# Contributing Guidelines
## Typos
Among other tasks, the CI verifies that changes do not contain common typos.
This check is done using [`typos`](https://github.com/crate-ci/typos).
To run this task locally, install [`typos`](https://github.com/crate-ci/typos)
and then run in the root directory:
```bash
typos
```

1265
README.mediawiki
View File

File diff suppressed because it is too large Load Diff

23
bip-0001.mediawiki
View File

@ -1,11 +1,13 @@
<pre>
BIP: 1
Title: BIP Purpose and Guidelines
Authors: Amir Taaki <genjix@riseup.net>
Status: Closed
Author: Amir Taaki <genjix@riseup.net>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001
Status: Replaced
Type: Process
Assigned: 2011-09-19
Proposed-Replacement: 2
Created: 2011-08-19
Superseded-By: 2
</pre>
==What is a BIP?==
@ -21,7 +23,7 @@ Because the BIPs are maintained as text files in a versioned repository, their r
There are three kinds of BIP:
* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.
* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational BIPs or follow their advice.
* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.
* A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.
==BIP Work Flow==
@ -36,7 +38,7 @@ BIP authors are responsible for collecting community feedback on both the initia
It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.
The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#bip-editors|BIP Editors]] below. Also see [[#bip-editor-responsibilities--workflow|BIP Editor Responsibilities & Workflow]]. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad.
The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#BIP_Editors|BIP Editors]] below. Also see [[#BIP_Editor_Responsibilities__Workflow|BIP Editor Responsibilities & Workflow]]. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad.
Authors MUST NOT self assign BIP numbers, but should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject.
@ -177,9 +179,6 @@ This document was derived heavily from Python's PEP-0001. In many places text wa
==Changelog==
* 2016-12-14:
** Closed: [https://github.com/bitcoin/bips/pull/478 Superseded by BIP2]
* 2016-01-01:
** Clarified early stages of BIP idea championing, collecting community feedback, etc.
* 2015-10-10:
** Added clarifications about submission process and BIP number assignment.
10 Oct 2015 - Added clarifications about submission process and BIP number assignment.
01 Jan 2016 - Clarified early stages of BIP idea championing, collecting community feedback, etc.

86
bip-0002.mediawiki
View File

@ -1,13 +1,15 @@
<pre>
BIP: 2
Title: BIP process, revised
Authors: Luke Dashjr <luke+bip@dashjr.org>
Status: Closed
Author: Luke Dashjr <luke+bip@dashjr.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0002
Status: Active
Type: Process
Assigned: 2016-02-03
License: BSD-2-Clause OR OPUBL-1.0
Created: 2016-02-03
License: BSD-2-Clause
OPL
Replaces: 1
Proposed-Replacement: 3
</pre>
==Abstract==
@ -30,23 +32,23 @@ 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://groups.google.com/g/bitcoindev Bitcoin development mailing list].
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].
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://groups.google.com/g/bitcoindev 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://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Bitcoin development mailing list].
This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal.
Following a discussion, the proposal should be submitted to the [https://github.com/bitcoin/bips BIPs git repository] as a pull request.
This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until an editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers).
This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers).
BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here.
It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.
When the BIP draft is complete, a BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository.
The BIP editors will not unreasonably reject a BIP.
When the BIP draft is complete, the BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository.
The BIP editor will not unreasonably reject a BIP.
Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.
For a BIP to be accepted it must meet certain minimum criteria.
It must be a clear and complete description of the proposed enhancement.
@ -59,23 +61,16 @@ The BIP author may update the draft as necessary in the git repository. Updates
It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.
If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editors. If the original author doesn't respond to email in a timely manner, the BIP editors will make a unilateral decision (it's not like such decisions can't be reversed :).
If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
===BIP Editors===
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]])
* 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]])
The current BIP editor is Luke Dashjr who can be contacted at [[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]].
===BIP Editor Responsibilities & Workflow===
The BIP editors subscribe to the Bitcoin development mailing list.
Off-list BIP-related correspondence should be sent (or CC'd) to the BIP editors.
The BIP editor subscribes to the Bitcoin development mailing list.
Off-list BIP-related correspondence should be sent (or CC'd) to luke_bipeditor@dashjr.org.
For each new BIP that comes in an editor does the following:
@ -100,21 +95,19 @@ 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 or markdown format.
BIPs should be written in mediawiki format.
Each BIP should have the following parts:
* Preamble -- Headers containing metadata about the BIP ([[#bip-header-preamble|see below]]).
* Preamble -- Headers containing metadata about the BIP ([[#BIP header preamble|see below]]).
* Abstract -- A short (~200 word) description of the technical issue being addressed.
* Copyright -- The BIP must be explicitly licensed under acceptable copyright terms ([[#bip-licensing|see below]]).
* Copyright -- The BIP must be explicitly licensed under acceptable copyright terms ([[#BIP licensing|see below]]).
* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms.
@ -181,7 +174,7 @@ BIPs may include auxiliary files such as diagrams. Auxiliary files should be inc
There are three kinds of BIP:
* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. Standards Track BIPs consist of two parts, a design document and a reference implementation.
* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational BIPs or follow their advice.
* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.
* A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.
==BIP status field==
@ -193,13 +186,13 @@ The typical paths of the status of BIPs are as follows:
<img src="bip-0002/process.png"></img>
Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
A BIP editor may also change the status to Deferred when no progress is being made on the BIP.
The BIP editor may also change the status to Deferred when no progress is being made on the BIP.
A BIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.
BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.
A Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
An Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.
@ -215,7 +208,7 @@ Peer services BIPs should be observed to be adopted by at least 1% of public lis
API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications.
Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/bitcoin-wallet/bitcoin-wallet/blob/master/wallet/README.specs.md Bitcoin Wallet for Android's wallet/README.specs.md file].
Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs Bitcoin Wallet for Android's wallet/README.specs file].
These criteria are considered objective ways to observe the de facto adoption of the BIP, and are not to be used as reasons to oppose or reject a BIP. Should a BIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status.
@ -247,7 +240,7 @@ What if a single merchant wishes to block a hard-fork?
How about a small number of merchants (maybe only two) who sell products to each other?
* In this scenario, it would seem the previous Bitcoin is alive and working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP.
* In this scenario, it would seem the previous Bitcoin is alive any working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP.
How can economic agreement veto a soft-fork?
@ -333,7 +326,7 @@ For example, a preamble might include the following License header:
In this case, the BIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement.
It is also possible to license source code differently from the BIP text. An optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.
It is also possible to license source code differently from the BIP text. A optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.
For example, a preamble specifying the optional License-Code header might look like:
@ -357,40 +350,40 @@ In this case, only the acceptable license(s) should be listed in the License and
====Recommended licenses====
* BSD-2-Clause: [https://opensource.org/license/BSD-2-Clause OSI-approved BSD 2-clause license]
* BSD-3-Clause: [https://opensource.org/license/BSD-3-Clause OSI-approved BSD 3-clause license]
* BSD-2-Clause: [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
* BSD-3-Clause: [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license]
* CC0-1.0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
* FSFAP: [https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html FSF All Permissive License]
* GNU-All-Permissive: [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
====Not recommended, but acceptable licenses====
* Apache-2.0: [https://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
* BSL-1.0: [https://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
* Apache-2.0: [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
* BSL-1.0: [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
* CC-BY-4.0: [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
* CC-BY-SA-4.0: [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
* MIT: [https://opensource.org/license/MIT The MIT License]
* AGPL-3.0+: [https://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
* FDL-1.3: [https://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3]
* GPL-2.0+: [https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
* LGPL-2.1+: [https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
* MIT: [https://opensource.org/licenses/MIT Expat/MIT/X11 license]
* AGPL-3.0+: [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
* FDL-1.3: [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3]
* GPL-2.0+: [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
* LGPL-2.1+: [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
====Not acceptable licenses====
All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal unless a later BIP extends this one to add them.
However, BIPs predating the acceptance of this BIP were allowed under other terms, and should use these abbreviation when no other license is granted:
* OPUBL-1.0: [https://opencontent.org/openpub/ Open Publication License, version 1.0]
* OPL: [http://opencontent.org/openpub/ Open Publication License, version 1.0]
* PD: Released into the public domain
===Rationale===
BIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient?
* The OPUBL-1.0 is generally regarded as obsolete, and not a license suitable for new publications.
* Many are unfamiliar with the OPUBL-1.0 terms, and may just prefer to use the public domain rather than license under uncertain terms.
* The OPUBL-1.0 license terms allowed for the author to prevent publication and derived works, which was widely considered inappropriate for Bitcoin standards.
* The OPL is generally regarded as obsolete, and not a license suitable for new publications.
* Many are unfamiliar with the OPL terms, and may just prefer to use the public domain rather than license under uncertain terms.
* The OPL license terms allowed for the author to prevent publication and derived works, which was widely considered inappropriate for Bitcoin standards.
* Public domain is not universally recognised as a legitimate action, thus it is inadvisable.
Why are there software licenses included?
@ -413,6 +406,7 @@ 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==

BIN
bip-0002/process.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 15 KiB

14
bip-0002/process.svg
View File

@ -1,4 +1,4 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 720 206" width="720" height="206">
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 526 206" width="526" height="206">
<defs>
<style type="text/css"><![CDATA[
rect {
@ -20,7 +20,7 @@
<path d="M0,2 L0,11 L8,6 L0,2" style="fill: black;" />
</marker>
</defs>
<rect x="8" y="8" width="128" height="32"/>
<text x="72" y="32" font-size="20" text-anchor="middle">Draft</text>
<path d="M136,24 L200,24"/>
@ -32,22 +32,18 @@
<path d="M456,40 L456,80"/>
<rect x="392" y="80" width="128" height="32"/>
<text x="456" y="104" font-size="20" text-anchor="middle">Replaced</text>
<path d="M120,40 L120,72 L200,72"/>
<rect x="200" y="56" width="128" height="32"/>
<text x="264" y="80" font-size="20" text-anchor="middle">Rejected</text>
<path d="M328,32 L360,32 L360,72 L328,72" stroke-dasharray="4, 2"/>
<path d="M88,40 L88,120 L200,120"/>
<rect x="200" y="104" width="128" height="32"/>
<text x="264" y="128" font-size="20" text-anchor="middle">Withdrawn</text>
<path d="M24,40 L24,166"/>
<rect x="8" y="166" width="128" height="32"/>
<text x="72" y="190" font-size="20" text-anchor="middle">Deferred</text>
<path d="M56,166 L56,40"/>
<path d="M520,24 L584,24"/>
<rect x="584" y="8" width="128" height="32"/>
<text x="648" y="32" font-size="20" text-anchor="middle">Obsolete</text>
</svg>

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.8 KiB

After

Width:  |  Height:  |  Size: 1.6 KiB

802
bip-0003.md
View File

@ -1,802 +0,0 @@
```
BIP: 3
Title: Updated BIP Process
Authors: Murch <murch@murch.one>
Status: Deployed
Type: Process
Assigned: 2025-01-09
License: BSD-2-Clause
Discussion: https://github.com/murchandamus/bips/pull/2
https://gnusha.org/pi/bitcoindev/59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de/#t
Version: 1.4.0
Requires: 123
Replaces: 2
```
## Abstract
This _Bitcoin Improvement Proposal (BIP)_ provides information about the preparation of BIPs and policies relating to
the publication of BIPs. It replaces [BIP 2](bip-0002.mediawiki) with a streamlined process, and may be amended to
address the evolving needs of the BIP process.
## Motivation
BIP 2 was written in 2016.
This BIP revisits aspects of the BIP 2 process
that did not achieve broad adoption, reduces the judgment calls assigned to the BIP Editor role, delineates the
BIP types more clearly, and generalizes the BIP process to fit the community’s use of the repository.
## Fundamentals
### What is a BIP?
BIPs are improvement proposals for Bitcoin. The main topic is information and technologies that support and expand the utility of the Bitcoin
currency. Most BIPs provide a concise, self-contained, technical description of one new concept, feature, or standard.
Some BIPs describe processes, implementation guidelines, best practices, incident reports (e.g.,
[BIP 50](bip-0050.mediawiki)), or other information relevant to the Bitcoin community. However, any topics related to
the Bitcoin protocol, peer-to-peer network, and client software may be acceptable.
BIPs are intended to be a means for proposing new protocol features, coordinating client standards, and
documenting design decisions that have gone into implementations. BIPs may be submitted by anyone, provided the
content is of high quality, e.g., does not waste the community’s time.
The scope of the BIPs
repository is limited to BIPs that do not oppose the fundamental principle that Bitcoin constitutes a peer-to-peer
electronic cash system for the Bitcoin currency.
### BIP Ownership
Each BIP is primarily owned by its authors and represents the authors’ opinion or recommendation. The authors are
expected to foster discussion, address feedback and dissenting opinions, and, if applicable, advance the adoption of
their proposal within the Bitcoin community. As a BIP progresses through the workflow, it becomes increasingly
co-owned by the Bitcoin community.
#### Authors and Deputies
Authors may want additional help with the BIP process after writing an initial draft. In that case, they may assign
one or more Deputies to their BIP. Deputies are stand-in owners of a BIP who were not involved in writing the
document. They support the authors in advancing the proposal, or act as a point of contact for the BIP in the absence of the
authors. Deputies may perform the role of Authors for any aspect of the BIP process unless overruled by an Author.
Deputies share ownership of the BIP at the discretion of the Authors.
### What is the Significance of BIPs?
BIPs do not define what Bitcoin is: individual BIPs do not represent Bitcoin community consensus or a general
recommendation for implementation. A BIP represents a personal recommendation by the BIP authors to the Bitcoin
community. Some BIPs may never be adopted. Some BIPs may be adopted by one or more Bitcoin clients or other related
software. Some may even end up changing the consensus rules that the Bitcoin ecosystem jointly enforces.
### What is the Purpose of the BIPs Repository?
The [BIPs repository](https://github.com/bitcoin/bips/) serves as a publication medium and archive for mature proposals.
Through its high visibility, it facilitates the community-wide consideration of BIPs and provides a well-established
source to retrieve the latest version of any BIP. The repository transparently records all changes to each BIP and
allows any community member to retain a complete copy of the archive easily.
The BIPs repository neither tracks community sentiment[^acceptance] nor ecosystem adoption[^adoption] of BIPs beyond
the brief overview provided via the BIP status (see [Workflow](#workflow) below).
Proposals are published in this repository if they are on-topic and fulfill the editorial criteria.
No formal or informal decision body governs Bitcoin development or decides adoption of BIPs.
## BIP Format and Structure
### Specification
Authors may choose to submit BIPs in MediaWiki or Markdown[^markdown] format.
Each BIP must have a _Preamble_, an _Abstract_, a _Copyright_, and a _Motivation_ section. Authors should consider all issues in the
following list and address each as appropriate.
* Preamble — Headers containing metadata about the BIP (see the section [BIP Header Preamble](#bip-header-preamble)
below).
* Abstract — A short description of the issue being addressed.
* Motivation — Why is this BIP being written? Clearly explain how the existing situation presents a problem and why the proposed idea resolves the
issue or improves upon the current situation.
* Specification — The technical specification should describe the syntax and semantics of any new feature. The
specification should be detailed enough to enable any Bitcoin project to create an interoperable implementation.
* Rationale — The rationale fleshes out the specification by describing what inspired the design and why particular
design decisions were made. It should describe related work and alternate designs that were considered. The rationale
should record relevant objections or important concerns that were raised and addressed as this proposal was developed.
* Backward Compatibility — Any BIP that introduces incompatibilities must include a section describing these incompatibilities and their severity as well as provide instructions on how
implementers and users should deal with these incompatibilities.
* Reference Implementation — Where applicable, a reference implementation, test vectors, and documentation must be
finished before the BIP can be given the status "Complete". Test vectors must be provided in the BIP or
as auxiliary files (see [Auxiliary Files](#auxiliary-files)) under an acceptable license. The reference implementation
can be provided in the BIP, as an auxiliary file, or per linking another code reference that is expected to remain
available permanently such as a pull request, a dedicated branch, a new repository, or similar.
* Changelog — A section to track modifications to a BIP after reaching Complete status.
* Copyright — The BIP must be placed under an acceptable license (see [BIP Licensing](#bip-licensing) below).
#### BIP Header Preamble
Each BIP must begin with an [RFC 822-style header preamble](https://www.w3.org/Protocols/rfc822/). The headers must
appear in the following order. Headers marked with "\*" are optional. All other headers are required.
##### Overview
```
BIP: <BIP number, or "?" before assignment>
* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>
Title: <BIP title (≤ 50 characters)>
Authors: <Authors’ names and email addresses>
* Deputies: <Deputies’ names and email addresses>
Status: <Draft | Complete | Deployed | Closed>
Type: <Specification | Informational | Process>
Assigned: <Date of number assignment (yyyy-mm-dd), or "?" before assignment>
License: <SPDX License Expression>
* Discussion: <Noteworthy discussion threads in "yyyy-mm-dd: URL" format>
* Version: <MAJOR.MINOR.PATCH>
* Requires: <BIP number(s)>
* Replaces: <BIP number(s)>
* Proposed-Replacement: <BIP number(s)>
```
##### Header Descriptions
* BIP — The assigned number of the BIP (without leading zeros). Please use "?" before a number has been assigned by the BIP Editors.
* Layer — The layer of Bitcoin the BIP applies to using the BIP classification defined in [BIP 123](bip-0123.mediawiki).
* Authors — The names (or pseudonyms) and email addresses of all authors of the BIP. The format of each authors header
value must be
Random J. User <address@dom.ain>
Multiple authors are recorded on separate lines:
Authors: Random J. User <address@dom.ain>
Anata Sample <anata@domain.example>
* Deputies — Additional owners of the BIP that are not authors. The Deputies header uses the same format as the
Authors header. See the [BIP Ownership](#bip-ownership) section above.
* Status — The stage of the workflow of the proposal. See the [Workflow](#workflow) section below.
* Type — See the [BIP Types](#bip-types) section below for a description of the three BIP types.
* Assigned – The date a BIP was assigned its number. Please use "?" before a number has been assigned by the BIP Editors.
* License — The License header specifies SPDX License Expressions describing the terms under which the
BIP and its auxiliary files are available. See the [BIP Licensing](#bip-licensing) section below.
* Discussion — The Discussion header points the audience to relevant discussions of the BIP, e.g., the mailing list
thread in which the idea for the BIP was discussed, a thread where a new version of the BIP was presented, or relevant
discussion threads on other platforms. Entries take the format "yyyy-mm-dd: URL", e.g., `2009-01-09:
https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html`, using the date and URL of the start of the
conversation. Multiple discussions should be listed on separate lines.
* Version — The current version number of this BIP. See the [Changelog](#changelog-section-and-version-header) section below.
* Requires — A list of existing BIPs the new proposal depends on. If multiple BIPs
are required, they should be listed in one line separated by a comma and space (e.g., "1, 2").
* Replaces[^proposes-to-replace] — BIP authors may put the numbers of one or more prior BIPs in the Replaces header to recommend that their
BIP succeeds, supersedes, or renders obsolete those prior BIPs.
* Proposed-Replacement[^superseded-by-proposed-replacement] — When a later BIP indicates that it intends to supersede an
existing BIP, the later BIP’s number is added to the Proposed-Replacement header of the existing BIP to indicate the
potential successor BIP.
#### Auxiliary Files
BIPs may include auxiliary files such as diagrams and source code. Auxiliary files must be included in a subdirectory
for that BIP named `bip-XXXX`, where "XXXX" is the BIP number zero-padded to four digits. File names in the subdirectory
do not need to adhere to a specific convention.
### BIP Types
* A **Specification BIP** defines a set of technical rules describing a new feature or affecting the interoperability of implementations. The
distinguishing characteristic of a Specification BIP is that it can be implemented, and implementations can be compliant with
it. Specification BIPs must have a Specification section, must have a Backward Compatibility section (if incompatibilities are introduced), and can only be advanced to Complete after they contain or refer to a reference implementation and test vectors.
* An **Informational BIP** describes a Bitcoin design issue, or provides general guidelines or other information to the
Bitcoin community.
* A **Process BIP** describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process
BIPs are like Specification BIPs, but apply to topics other than the Bitcoin protocol and Bitcoin implementations.
They often require community consensus and are typically binding for the corresponding process. Examples include
procedures, guidelines, and changes to decision-making processes such as the BIP process.
## Workflow
The BIP process starts with a new idea for Bitcoin. Each potential BIP must have authors—people who write the BIP,
gather feedback, shepherd the discussion in the appropriate forums, and finally recommend a mature proposal to the
community.
![Status Diagram](bip-0003/status-diagram.png "Status Diagram for the BIP Workflow")
### Ideation
After having an idea, the authors should evaluate whether it meets the criteria to become a BIP, as described in this
BIP. The idea must be of interest to the broader community or relevant to multiple software projects. Minor improvements
and matters concerning only a single project usually do not require standardization and should instead be brought up directly to
the relevant project.
The authors should first research whether their idea has been considered before. Ideas in Bitcoin are often rediscovered,
and prior related discussions may inform the authors of the issues that may arise in its progression. After some investigation,
the novelty and viability of the idea should be tested by posting a new, dedicated thread about the idea to the [Bitcoin Development Mailing
List](https://groups.google.com/g/bitcoindev). Prior correspondence can be found in the [mailing list
archive](https://gnusha.org/pi/bitcoindev/).
It is recommended that authors establish before or at the start of working on a draft whether their idea may be of
interest to the Bitcoin community.
Authors should avoid opening a pull request with a BIP draft out of the blue.
Vetting an idea publicly before investing time and effort to formally describe the idea is meant to save time for both the authors and
the community. Not only may someone point out relevant discussion topics that were missed in the authors’
research, or that an idea is guaranteed to be rejected based on prior discussions, but describing an idea publicly also
tests whether it is of interest to more people beside the authors.
As a first sketch of the proposal is taking shape, the authors should present it to the [Bitcoin Development Mailing
List](https://groups.google.com/g/bitcoindev). This gives the authors a chance to collect initial feedback and address
fundamental concerns. If the authors wish to work in public on the proposal at this stage, it is recommended that they
open a pull request against one of their forks of the BIPs repository instead of the main BIPs repository.
It is recommended that complicated proposals be split into separate BIPs that each focus on a specific component of the
overall proposal.
### Progression through BIP Statuses
The following sections refer to BIP Status field values. The BIP Status field is defined in the Header Preamble
specification above.
#### Draft
After fleshing out the proposal further and ensuring that it is of high quality and properly formatted, the authors
should open a pull request to the [BIPs repository](https://github.com/bitcoin/bips). The document must adhere to the
formatting requirements specified above and should be provided as a file named with a working title of the form
"bip-title.[md|mediawiki]". Only BIP Editors may assign BIP numbers. Until one has done so, authors should refer to their
BIP by name only.
BIPs that (1) adhere to the formatting requirements, (2) are on-topic, and (3) have materially progressed beyond the
ideation phase, e.g., by generating substantial public discussion and commentary from diverse contributors, by
independent Bitcoin projects working on adopting the proposal, or by the authors working for an extended period toward
improving the proposal based on community feedback, will be assigned a number by a BIP Editor. A number may be
considered assigned only after it has been publicly announced in the pull request by a BIP Editor. The BIP Editors should
not assign a number when they perceive a proposal being met with lack of interest: number assignment facilitates the
distributed discussion of ideas, but before a proposal garners some interest in the Bitcoin community, there is no need
to refer to it by a number.
Proposals are also not ready for number assignment if they duplicate efforts, disregard formatting rules, are too
unfocused or too broad, fail to provide proper motivation, fail to address backward compatibility where necessary, or
fail to specify the feature clearly and comprehensively. Reviewers and BIP Editors should provide guidance on how the
proposal may be improved to progress toward readiness. Pull requests that are proposing off-topic ideas or
have stopped making progress may be closed.
When the proposal is ready and has been assigned a number, a BIP Editor will merge it into the BIPs repository. After the
BIP has been merged to the repository, its main focus should no longer shift significantly, even while the authors may
continue to update the proposal as necessary. Updates to merged documents by the authors should also be submitted as
pull requests.
#### Complete[^complete]
When the authors have concluded all planned work on their proposal, are confident that their BIP represents a net
improvement, is clear, comprehensive, and is
ready for adoption by the Bitcoin community, they may update the BIP’s status to Complete to indicate that they
recommend adoption, implementation, or deployment of the BIP. Where applicable, the authors must ensure that any
proposed specification is solid, not unduly complicated, and definitive. Specification BIPs must come with or refer to a working reference implementation and comprehensive test vectors before they can be moved to Complete. Subsequently, the BIP’s content should only be
adjusted in minor details, e.g., to improve language, clarify ambiguities, backfill omissions in the specification, add
test vectors for edge cases, or address other issues discovered as the BIP is being adopted.
A Complete BIP can only move to Deployed or Closed. Any necessary changes to the specification should be minimal and
interfere as little as possible with ongoing adoption. If a Complete BIP is found to need substantial functional
changes, it may be preferable to move it to Closed[^new-BIP], and to start a new BIP with the changes instead.
Otherwise, it could cause confusion as to what being compliant with the BIP means.
A BIP may remain in the Complete status indefinitely unless its authors or deputies decide to move it to Closed or it is advanced to
Deployed.
Complete is the final status for most successful Informational BIPs.
#### Deployed
A Complete BIP should only be moved to Deployed once it is settled: after its approach has solidified, its
Specification has been put through its paces, feedback from early adopters has been processed, and amendments to the BIP have stopped.
Then, a BIP may be advanced to Deployed upon request by any community member with evidence[^evidence] that
the BIP is in active use. Convincing evidence includes for example: an established project having deployed support
for the BIP in mainnet software releases, a soft fork proposal’s activation criteria having been met on the network, or
rough consensus for the BIP having been demonstrated.
Once Deployed, the BIP is considered final.
Any modifications to the BIP beyond bug fixes, other minor amendments, additions to the test vectors, or editorial
changes should be avoided.
Any breaking changes to the BIP’s Specification should be proposed as a new separate BIP.[^new-BIP]
##### Process BIPs
A Process BIP may change status from Complete to Deployed when it achieves rough consensus on the Bitcoin Development Mailing List. A
proposal is said to have rough consensus if its advancement has been open to discussion on the mailing list for at least
one month, the discussion achieved meaningful engagement, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections
may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be
given in such circumstances. Deployed Process BIPs may be modified indefinitely as long as a proposed modification has
rough consensus per the same criteria.[^living-documents]
#### Closed[^closed]
A BIP that is of historical interest only, and is not being actively worked on, promoted or in active use, should be
marked as Closed. The reason for moving the
proposal to (or from) Closed should be recorded in the Changelog section in the same commit that updates the status.
BIPs do not get deleted, they are retained even after being updated to Closed.
Transitions involving the Closed state are:
##### Draft ↦ Closed
BIP authors may decide on their own to change their BIP’s status from Draft to Closed. If a Draft BIP stops making
progress, sees accumulated feedback unaddressed, or otherwise appears stalled for a year, anyone may propose the BIP
status be updated to Closed. The BIP is then updated to Closed unless the authors assert that they intend to continue work within four weeks of being contacted.
##### Complete ↦ Closed
BIPs that had attained the Complete status, i.e., that had been recommended for adoption, may be moved to Closed per the
authors’ announcement to the Bitcoin Development Mailing List[^bip-announcements-to-list]. However, if someone volunteers to adopt the proposal
within four weeks, they become the BIP's author or deputy (see [Transferring BIP Ownership](#transferring-bip-ownership) below), and the BIP will
remain Complete instead.
##### Deployed ↦ Closed
A BIP may evolve from Deployed to Closed when it is no longer in active use. Any community member may initiate this
Status update by announcing it to the mailing list[^bip-announcements-to-list], and proceed if no objections have been raised for four weeks.
##### Closed ↦ Draft
The Closed status is generally intended to be a final status for BIPs,
and if BIP authors decide to make another attempt at a previously Closed BIP, it is generally recommended to create a new
proposal. (Obviously, the authors may borrow any amount of inspiration or actual text from any prior BIPs as licensing
permits.) The authors should take special care to address the issues that caused the prior attempt’s abandonment. Even
if the prior attempt had been assigned a number, the new BIP will generally be assigned a distinct number. However, if it is
obvious that the new attempt directly continues work on the same idea, it may be reasonable to return the
Closed BIP to Draft status.
### Changelog Section and Version Header
To help implementers understand updates to a BIP, any changes after it has reached Complete must be tracked with version,
date, and description in a Changelog section sorted by most recent version first. The version number is inspired by semantic versioning (MAJOR.MINOR.PATCH).
The MAJOR version is incremented if changes to the BIP’s Specification are introduced that are incompatible with prior
versions (which should be rare after a BIP is Complete, and only happen in well-grounded exceptional cases to a BIP that
is Deployed). The MINOR version is incremented whenever the specification of the BIP is changed or extended in a
backward-compatible way. The PATCH version is incremented for other changes to the BIP that are noteworthy (bug fixes,
test vectors, important clarifications, etc.). Version 1.0.0 is used to label the promotion to
Complete. A Changelog section may be introduced during the Draft phase to record significant changes (using versions 0.x.y).
Example:
> __Changelog__
>
> * __2.0.0__ (2025-01-22):
> * Introduce a breaking change in the specification to fix a bug.
> * __1.1.0__ (2025-01-17):
> * Add a backward compatible extension to the BIP.
> * __1.0.1__ (2025-01-15):
> * Clarify an edge case and add corresponding test vectors.
> * __1.0.0__ (2025-01-14):
> * Complete planned work on the BIP.
After a BIP receives a Changelog, the
Preamble must indicate the latest version in the Version header. The Changelog highlights revisions to BIPs to human readers. A single
BIP shall not recommend more than one variant of an idea at the same time. A different or
competing variant of an existing BIP must be published as a separate BIP.
### Adoption of Proposals
The BIPs repository does not track the sentiment on proposals and does not track the adoption of BIPs beyond whether they
are in active use or not. It is not intended for BIPs to list additional implementations beyond the reference
implementation: the BIPs repository is not a signpost where to find implementations.[^OtherImplementations] After a BIP
is advanced to Complete, it is up to the Bitcoin community to evaluate, adopt, ignore, or reject a BIP. Individual
Bitcoin projects are encouraged to publish a list of BIPs they implement. A good example of this at the time of writing
this BIP can be observed in Bitcoin Core’s [doc/bips.md](https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md)
file.
### Transferring BIP Ownership
It occasionally becomes necessary to transfer ownership of BIPs to new owners. In general, it would be preferable to
retain the original authors of the transferred BIP, but that is up to the original authors. A good reason to transfer
ownership is because the original authors no longer have the time or interest in updating it or following through with
the BIP process, or are unreachable or unresponsive. A bad reason
to transfer ownership is because someone doesn't agree with the direction of the BIP. The community tries to build
consensus around a BIP, but if that's not possible, rather than fighting over control, the dissenters should supply a
competing BIP.
If someone is interested in assuming ownership of a BIP, they should send an email asking to take over, addressed to the
original authors, the BIP Editors, and the Bitcoin Development Mailing List[^bip-announcements-to-list]. If the authors are unreachable or do not respond in a timely
manner (e.g., four weeks), the BIP Editors will make a unilateral decision whether to appoint the applicants as
[Authors or Deputies](#authors-and-deputies) (which may be amended should the original authors make a delayed reappearance).
## BIP Licensing
The Bitcoin project develops a global peer-to-peer digital cash system. Open standards are indispensable for continued
interoperability. Open standards reduce friction, and encourage anybody and everyone to contribute, compete, and
innovate on a level playing field. Only freely licensed contributions are accepted to the BIPs repository.
### Specification
Each new BIP must specify in two ways under which license terms it is made available. First, it must specify an [SPDX
License Expression](https://spdx.dev/ids/) in the License field in the preamble. Second, it must include a matching
Copyright section, possibly providing further details on licensing.
For example, a preamble might include the following License header:
License: CC0-1.0 OR MIT
In this case, the BIP (including all auxiliary files) is made available under the terms of both CC0 1.0 Universal as well as the
MIT License, and anyone may modify and redistribute it provided they comply with the terms of
*either* license, at their option. In other words, the license list is an "OR choice", not an "AND also" requirement. See the [SPDX
documentation](https://spdx.dev/ids/) and the [SPDX License List](https://spdx.org/licenses/) for further details.
Wherever different from those specified in the License header, an auxiliary file or directory should specify the license terms under which it is made available as is common in
software (e.g., with a [`SPDX-License-Identifier: <SPDX License Expression>` comment](https://spdx.dev/ids/),
a license header, or a LICENSE/COPYING file). Such exceptions should also be mentioned in the Copyright section. It is recommended to make any test vectors available
under CC0-1.0 or FSFAP in addition to any other licenses to allow anyone to copy test vectors into their
implementations without introducing license hindrances.
A few BIP2-era BIPs (98, 116, 117, 330, 340) have a no longer used "License-Code" header indicating the license terms applicable to auxiliary source code files. For such cases, please refer to BIP2.
It is recommended that source code included in a BIP (whether within the text or in auxiliary files) be licensed under the same license terms as the project it
is proposed to modify, if any. For example, changes intended for Bitcoin Core would ideally be licensed (also) under the MIT
License.
In all cases, details of the licensing terms must be provided in the Copyright section of the BIP.
#### Acceptable Licenses[^licenses]
Each new BIP must be made available under at least one acceptable license as listed below. BIPs are not required to be
*exclusively* licensed under approved terms, and may also be licensed under other licenses *in addition to* at least one
acceptable license.
In other words, a new BIP must specify an SPDX License Expression that is either "L" or equivalent to "L OR E" for some
acceptable license L from the following list and another SPDX License Expression E.
* BSD-2-Clause: [BSD 2-Clause License](https://opensource.org/license/BSD-2-Clause)
* BSD-3-Clause: [BSD 3-Clause License](https://opensource.org/license/BSD-3-Clause)
* CC0-1.0: [CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/)
* FSFAP: [FSF All Permissive License](https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html)
* CC-BY-4.0: [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/)
* MIT: [The MIT License](https://opensource.org/license/MIT)
* MIT-0: [MIT No Attribution License](https://opensource.org/license/MIT-0)
* Apache-2.0: [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0)
* BSL-1.0: [Boost Software License 1.0](https://www.boost.org/LICENSE_1_0.txt)
#### Not Acceptable Licenses
All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal.
However, BIPs predating this proposal were accepted under other terms, and should use one of the following identifiers.
* LicenseRef-PD: Placed into the public domain
* OPUBL-1.0: [Open Publication License 1.0](https://opencontent.org/openpub/)
## BIP Editors
The current BIP Editors are:
* Bryan Bishop ([kanzure@gmail.com](mailto:kanzure@gmail.com))
* Jon Atack ([jon@atack.com](mailto:jon@atack.com))
* Luke Dashjr ([luke_bipeditor@dashjr.org](mailto:luke_bipeditor@dashjr.org))
* Mark "Murch" Erhardt ([murch@murch.one](mailto:murch@murch.one))
* Olaoluwa Osuntokun ([laolu32@gmail.com](mailto:laolu32@gmail.com))
* Ruben Somsen ([rsomsen@gmail.com](mailto:rsomsen@gmail.com))
### BIP Editor Responsibilities and Workflow
The BIP Editors subscribe to the Bitcoin Development Mailing List and watch the [BIPs
repository](https://github.com/bitcoin/bips).
When either a new BIP idea or an early draft is submitted to the mailing list, BIP Editors or other community members should comment in regard
to:
* Novelty of the idea
* Viability, utility, and relevance of the concept
* Readiness of the proposal
* On-topic for the Bitcoin community
Discussion in pull request comments can often be hard to follow as feedback gets marked as resolved when it is addressed
by authors. Substantive discussion of ideas may be more accessible to a broader audience on the mailing list, where it
is also more likely to be retained by the community memory.
If the BIP needs more work, an editor should ensure that constructive, actionable feedback is provided to the authors
for revision. Once the BIP is ready it should be submitted as a "pull request" to the [BIPs
repository](https://github.com/bitcoin/bips) where it may get further feedback.
For each new BIP pull request that comes in, an editor checks the following:
* The idea has been previously proposed to the Bitcoin Development Mailing List and discussed there
* The described idea is on-topic for the repository
* A draft of the BIP by one of the authors has been previously discussed on the Bitcoin Development Mailing List
* Title accurately describes the content
* Proposal is of general interest and/or pertains to more than one Bitcoin project/implementation
* Document is properly formatted
* Licensing terms are acceptable
* Motivation, Rationale, and Backward Compatibility have been addressed
* Specification provides sufficient detail for implementation
* The defined Layer and Type headers must be correctly assigned for the given specification
* The BIP is ready: it is comprehensible, technically feasible and sound, and all aspects are addressed as necessary
Editors do NOT evaluate whether the proposal is likely to be adopted.
Then, a BIP Editor will:
* Assign a BIP number in the pull request
* Ensure that the BIP is listed in the [README](README.mediawiki)
* Merge the pull request when it is ready
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, mending grammar mistakes, fixing broken links, etc. as long as they do not change the meaning or conflict with the
original intent of the authors. Such a change must be recorded in the Changelog if it’s noteworthy per the criteria
mentioned in the [Changelog](#changelog) section.
## Backward Compatibility
### Changes from BIP 2
#### Workflow
- Status field values are reduced from nine to four:
- Deferred, Obsolete, Rejected, Replaced, and Withdrawn are gathered up into Closed.[^closed]
- Final and Active are collapsed into Deployed.
- Proposed is renamed to Complete.
- The remaining statuses are Draft, Complete, Deployed, and Closed.
- The comment system is abolished.[^comments]
- A BIP in Draft or Complete status may no longer be closed solely on grounds of not making progress for three years.[^rejection]
- A BIP in Draft status may be updated to Closed status if it appears to have stopped making progress for at least a
year and its authors do not assert within four weeks of being contacted that they intend to continue working on it.
- Complete BIPs can only be moved to Closed by its authors and may remain in Complete indefinitely.
- A Changelog section is introduced to track significant changes to BIPs after they have reached the Complete status.
- Process BIPs are living documents that do not ossify and may be modified indefinitely.
- Some judgment calls previously required from BIP Editors are reassigned either to the BIP authors or the repository’s
audience.
#### BIP Format
- The Standards Track type is superseded by the similar Specification type.[^standard-track]
- Many sections are declared optional; it is up to the authors and reviewers to judge whether all relevant topics have
been comprehensively addressed and which topics require a designated section to do so.
- "Other Implementations" sections are discouraged.[^OtherImplementations]
- Auxiliary files are only permitted in the corresponding BIP’s subdirectory, as no one used the alternative of labeling
them with the BIP number.
- Tracking of community consensus and adoption is out of scope for the BIPs repository, except to determine
whether a BIP is in active use for the move into or out of the Deployed status.
- The distinction between recommended and acceptable licenses was dropped.
- Most licenses that have not been used in the BIP process have been dropped from the list of acceptable licenses.
#### Preamble
- "Comments-URI" and "Comments-Summary" headers are dropped from the preamble.[^comments]
- The "Superseded-By" header is replaced with the "Proposed-Replacement" header.
- The "Post-History" header is replaced with the "Discussion" header.
- The optional "Version" header is introduced.
- The "Discussions-To" header is dropped, as it has never been used in any BIP.
- The "License-Code" header has been sunset, as it was used by only five BIPs (98, 116, 117, 330, 340) and created more ambiguity than clarity.
- The "Created" header is renamed to "Assigned", as the header’s value is the date of number assignment.[^assigned]
- Introduce Deputies and optional "Deputies" header.
- The BIP "Title" header may now contain up to 50 characters (increased from 44 in BIP 2).
- The "Layer" header is optional for Specification BIPs or Informational BIPs, as it does not make sense for all BIPs.[^layer]
- Rename the "Author" field to "Authors".
### Updates to Existing BIPs should this BIP be Activated
#### Previous BIP Process
This BIP replaces BIP 2 as the guideline for the BIP process.
#### BIP Types
Standards Track BIPs and eligible Informational BIPs are assigned the Specification type. The Standards Track type is
considered obsolete. Specification BIPs use the Layer header rules specified in [BIP 123](bip-0123.mediawiki).
#### Comments
The Comments-URI and Comments-Summary headers should be removed from all BIPs whose comment page in the wiki is empty.
For existing BIPs whose comment page has content, BIP Authors may keep both headers or remove both headers at their
discretion. It is recommended that existing wiki pages are not modified due to the activation of this BIP.
#### Status Field
After the activation of this BIP, the Status fields of existing BIPs that do not fit the specification in this BIP are
updated to the corresponding values prescribed in this BIP. BIPs that have had Draft status for extended periods will be
moved to Complete or Deployed as applicable in collaboration with their authors. The authors of incomplete Draft BIPs
will be contacted to learn whether the BIPs are still in progress toward Complete, and will otherwise be updated to
Closed as described in the [Workflow](#workflow) section above.
#### Authors Header
The Author header is replaced with the Authors header in all BIPs.
#### Discussion Header
The Post-History header is replaced with the Discussion header in all BIPs.
#### Proposed-Replacement Header
The Superseded-By header is replaced with the Proposed-Replacement header in all BIPs.
#### Licenses
Existing BIPs retain their license terms unchanged.
The License and License-Code headers of BIPs are updated to express those terms using SPDX License Expressions.
## Changelog
* __1.4.0__ (2025-12-09):
* Revert AI guidance, add Changelog section, broaden reference implementation formats, move Type header responsibility to authors, other editorial changes
* __1.3.1__ (2025-11-10):
* Reiterate that numbers are assigned by BIP Editors in pull requests
* __1.3.0__ (2025-10-22):
* Restrict use of AI/LLM tools, require original work.
* __1.2.1__ (2025-09-19):
* Clarify that idea should be discussed on dedicated mailing list thread
* __1.2.0__ (2025-09-19):
* Rename Created header to Assigned to clarify that it holds the date of number assignment
* __1.1.0__ (2025-07-18):
* Switch to SPDX License Expressions, drop License-Code header, and make editorial changes to BIP Licensing section.
* __1.0.1__ (2025-06-27):
* Improve description of acceptance, purpose of the BIPs repository, when Draft BIPs can be closed due to not
making progress, and make other minor improvements to phrasing.
* __1.0.0__ (2025-03-18):
* Complete planned work and move to Proposed.
## Copyright
This BIP is licensed under the [BSD-2-Clause License](https://opensource.org/licenses/BSD-2-Clause). Some content was
adapted from [BIP 2](bip-0002.mediawiki) which was also licensed under the BSD-2-Clause.
## Related Work
- [BIP 1: BIP Purpose and Guidelines](bip-0001.mediawiki)
- [BIP 2: BIP Process, revised](bip-0002.mediawiki)
- [BIP 123: BIP Classification](bip-0123.mediawiki)
- [RFC 822: Standard for ARPA Internet Text Messages](https://datatracker.ietf.org/doc/html/rfc822)
- [RFC 2223: Instructions to RFC Authors](https://datatracker.ietf.org/doc/html/rfc2223)
- [RFC 7282: On Consensus and Humming in the IETF](https://tools.ietf.org/html/rfc7282)
## Acknowledgements
We thank AJ Towns, Jon Atack, Jonas Nick, Larry Ruane, Pieter Wuille, Tim Ruffing, and others for their review,
feedback, and helpful comments.
## Rationale
[^assigned]: **Why was the Created header renamed to Assigned?**
Both BIP 1 and BIP 2 described the Created header as "date created on" in the preamble template, but followed that
up with "Created header records the date that the BIP was assigned a number" as the description of the field. This
has frequently led to confusion, with authors using the date of opening the pull request, the date they started
writing their proposal, the date of number assignment (as prescribed), or various other dates. Aligning the name of
the header and the text in the preamble template with the descriptions will reduce the confusion.
[^standard-track]: **Why was the Specification type introduced?**
The definitions of Informational and Standards Track BIPs caused some confusion in the past. Due to Informational
BIPs being described as optional, Standards Track BIPs were sometimes misunderstood to be generally recommended.
This has led to a number of BIPs that propose new features affecting interoperability of implementations being
assigned the Informational type. The situation is remedied by introducing a new _Specification BIP_ type that is
inclusive of any BIPs that can be implemented and affect interoperability of Bitcoin applications. Since all BIPs
are individual recommendations by the authors (even if some may eventually achieve endorsement by the majority of
the community), the prior reminder that Informational BIPs are optional is dropped.
[^comments]: **Why were comments, Comments-URI, and Comments-Summary removed from the process?**
The comments feature saw insignificant adoption. Few BIPs received any comments and barely any more than two with
only a handful of contributors commenting at all. This led to many situations in which one or two comments ended up
dominating the comment summary. While some of those comments may have been representative of broadly held opinions,
it also overstated the importance of individual comments directly in the Preamble of BIPs. As collecting feedback in
this accessible fashion failed, the new process puts the burden back on the audience to make their own evaluation.
[^layer]: **Why is the layer header now permitted for other BIP types?**
The layer header had already been used by many Informational BIPs, so the rule that it is only available to
Standards Track BIPs is dropped.
[^OtherImplementations]: **What is the issue with "Other Implementations" sections in BIPs?**
In the past, some BIPs had "Other Implementations" sections that caused frequent change requests to existing BIPs.
This put a burden on the BIP authors and BIP Editors, and frequently led to lingering pull requests due to the corresponding BIPs’
authors no longer participating in the process. Many of these alternative implementations eventually became
unmaintained or were low-quality to begin with. Therefore, "Other Implementations" sections are heavily discouraged.
[^complete]: **Why was the Proposed status renamed to Complete?**
Some reviewers of this BIP raised that in a process which outlines the workflow of Bitcoin Improvement _Proposals_
using "Proposed" as a status field value was overloading the term: clearly _proposals_ are proposed at all stages of
the process. "Complete" expresses that the authors have concluded planned work on all parts of the proposal and are
ready to recommend their BIP for adoption. The term "ready" was also considered, but considered too subjective.
[^rejection]: **Why can proposals remain in Draft or Complete indefinitely?**
The automatic 3-year timeout of BIPs has led to some disagreement in the past and seems unnecessary in cases where
the authors remain active in the community and still consider their idea worth pursuing. On the other hand,
Draft proposals that appear stale may be closed after only one year, which should achieve the main goal of
the original rule by limiting the effort and attention spent on proposals that never reach Complete.
[^closed]: **Why was the Closed Status introduced?**
The Closed Status provides value to the audience by indicating which documents are only of historical significance.
Previously, the process had Deferred, Obsolete, Rejected, Replaced, and Withdrawn, which all meant some flavor of
"work has stopped on this." The many statuses complicated the process, may have contributed to process fatigue, and
may have resulted in BIPs’ statuses not being maintained well. The author of this BIP feels that all of the
aforementioned can be represented by _Closed_ without significantly impacting the information quality of the
overview table. Where the many Status variants provided minuscule additional information, the simplification is more
valuable and the Changelog section now collects specific details.
[^acceptance]: **When is a BIP "accepted"?**
Many standards processes such as the PEPs or the IETF have a mechanism for a proposal to be formally accepted by
some council or committee. The BIP Process does not have such a decision body. Bitcoin development and "acceptance"
of BIPs emerges from the participation of stakeholders across the ecosystem, and refers to some vague notion of community
interest and support for a proposal.
BIP 2 had made an attempt to gather community feedback into comment summaries in BIPs directly. Given the low
participation and corresponding low information quality of the summaries that resulted from that feature, this BIP
instead intends to leave the evaluation of BIPs to the reviewers and users.
[^adoption]: **Why does the BIPs repository no longer track adoption?**
In the past, some BIPs maintained lists of projects that had implemented the BIP. These lists generated
noise for subscribers of the repository, often listed implementations of questionable quality, and quickly
grew outdated, therefore providing little value. The repository no longer tracks which projects have implemented
BIPs. Instead, it is recommended that projects publish a list of the BIPs they implement.
[^markdown]: **Which flavor of Markdown is allowed?**
The author of this proposal has no opinion on Markdown flavors, but recommends that proposals stick to the basic
Markdown syntax features commonly shared across Markdown dialects.
[^living-documents]: **Why are Process BIPs living documents?**
In the past years, the existing BIPs process has not always provided a clear approach to all situations. For
example, the content of BIP 2 appears to have been penned especially with fork proposals in mind. It seems clear
that Bitcoin development will evolve in many surprising ways in the future. Instead of mandating the effort of
writing a new process document every time new situations arise, it seems preferable to allow the process to adapt to
the concerns of the future in specific aspects. Therefore, Process BIPs are defined as living documents that remain
open to amendment. If a Process BIP requires large modifications or even a complete overhaul, a new BIP should be
preferred.
[^new-BIP]: **Why should the specification of an implemented BIP no longer be changed?**
After a Complete or Deployed BIP has been deployed by one or more implementations, breaking changes to the
specification could lead to a situation where multiple "compliant" implementations fail at being interoperable,
because they implemented different versions of the same BIP. Therefore, even changes to the specification of
Complete BIPs should be avoided, but Deployed BIPs should never be subject to breaking changes to their
specification.
[^bip-announcements-to-list]: **Why are some BIP status changes announced to the mailing list?**
The BIPs repository does not and cannot track who might be interested in or has deployed a BIP. While concerns were
raised that making announcements to the Bitcoin Developer Mailing List would introduce unnecessary noise, our
rationale is that 1) moving Complete and Deployed BIPs to the Closed status will be a rare occurrence, 2) status
updates will usually not generate a lot of discussion, 3) while the mailing list should preferably only used for
getting review for new BIPs, it is the only channel available to us that can be considered a public announcement to
the audience of the BIPs repository: even if the authors, implementers, or other parties interested in a BIP do not
see the announcement themselves, they may be made aware by someone that does see it.
[^superseded-by-proposed-replacement]: **Why is Superseded-By replaced with Proposed-Replacement?**
Reviewers asked who should get to decide whether a BIP is superseded in case of a disagreement among the authors of
the original BIP, the authors of the new BIP, the editors, or the community? This is addressed by making the
"Replaces" header part of the recommendation of the authors of the new document, and replacing the "Superseded-By"
header with the "Proposed-Replacement" header that lists any proposals that recommend replacing the original document.
[^proposes-to-replace]: **Why was "Replaces" retained instead of changing it to "Proposes-to-Replace"?**
When one BIP proposes to supersede another, it is on the original BIP where things get complicated. The BIP is an
author document, but depending on its progress through the workflow, it may meanwhile be co-owned by the community. Who may decide
whether the original document should endorse a potential replacement BIP? Is it the original authors, the authors of the new
proposal, the BIP Editors, some sort of community process, or a mix of all of the above?
On the new BIP these problems don’t exist in the same manner. As it is freshly written, it is wholly owned by its
authors. The community is not yet invested and the original BIP’s authors do not have a privileged role
in determining the content of the new BIP. The authors of the new BIP can unilaterally recommend that it be
considered a replacement for a prior BIP. From there, the community can evaluate the proposal and adopt or
reject it, thus establishing whether it is successful in superseding the original or not.
[^evidence]: **How is evidence for advancing to Deployed evaluated?**
Whether evidence is deemed convincing to move a BIP to Deployed is up to the BIP Editors and Bitcoin community.
Running a single instance of a personal fork of a software project might be rejected, while a small software project with
dozens of users may be sufficient. The main point of the Deployed status is to indicate that changes to the BIP
could negatively impact users of projects that have already implemented support.
[^licenses]: **Why were some licenses dropped?**
Among the 141 BIPs with licenses in the repository, only nine licenses have ever been used to license BIPs
(although, some BIPs were made available under more than one license) and only one license has been used to license
code:
Licenses used:
* BSD-2-Clause: 55
* PD: 42
* CC0-1.0: 23
* BSD-3-Clause: 19
* OPUBL-1.0: 5
* CC-BY-SA-4.0: 4
* FSFAP: 3
* MIT: 2
* CC-BY-4.0: 1
License-Code used (previous BIP2 format):
* BSD-2-Clause: 1
* CC0-1.0: 1
* MIT: 5
The following previously acceptable licenses were retained per request of reviewers, even though they have so far
never been used in the BIPs process:
* Apache-2.0: [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0)
* BSL-1.0: [Boost Software License 1.0](https://www.boost.org/LICENSE_1_0.txt)
The following previously acceptable licenses have never been used in the BIPs Process and have been dropped:
* AGPL-3.0+: [GNU Affero General Public License (AGPL) 3](https://www.gnu.org/licenses/agpl-3.0.en.html)
* FDL-1.3: [GNU Free Documentation License 1.3](https://www.gnu.org/licenses/fdl-1.3.en.html)
* GPL-2.0+: [GNU General Public License (GPL) 2 or newer](https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html)
* LGPL-2.1+: [GNU Lesser General Public License (LGPL) 2.1 or newer](https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html)
Why are software licenses included?
* Some BIPs, in particular those concerning the consensus layer, may include literal code in the BIP itself which
may not be available under the license terms the authors wish to use for the BIP.
* The author of this BIP has been provided with a learned opinion indicating that software licenses are perfectly
acceptable for licensing "human code" i.e., text as well as Markdown or MediaWiki code.
Why is CC-BY-SA-4.0 no longer acceptable for new BIPs?
* Specification BIPs are required to have a Reference Implementation and Test Vectors to be advanced to Complete. As
the BIPs repository is aiming to make proposals easily adoptable, the intention is for the reference
implementation and test vectors to be as accessible as possible. Copyleft licenses may introduce friction here,
and therefore CC-BY-SA-4.0 (and the GPL-flavors) is no longer considered acceptable for new BIPs. As mentioned
above, existing BIPs will retain their original licensing.
Why are Open Publication License and Public Domain no longer acceptable for new BIPs?
* Public domain is not universally recognised as a legitimate action, thus it is inadvisable.
* The Open Publication License is generally regarded as obsolete, and not a license suitable for new publications.

BIN
bip-0003/status-diagram.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 91 KiB

277
bip-0008.mediawiki
View File

@ -1,277 +0,0 @@
<pre>
BIP: 8
Title: Version bits with lock-in by height
Authors: Shaolin Fry <shaolinfry@protonmail.ch>
Luke Dashjr <luke+bip@dashjr.org>
Status: Draft
Type: Informational
Assigned: 2017-02-01
License: BSD-3-Clause OR CC0-1.0
</pre>
==Abstract==
This document specifies an alternative to [[bip-0009.mediawiki|BIP9]] that corrects for a number of perceived mistakes.
Block heights are used for start and timeout rather than POSIX timestamps.
It additionally introduces an activation parameter that can guarantee activation of backward-compatible changes (further called "soft forks").
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
==Motivation==
BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide optional flag day activation after a reasonable time, as well as for accelerated activation by majority of hash rate before the flag date.
Due to using timestamps rather than block heights, it was found to be a risk that a sudden loss of significant hashrate could interfere with a late activation.
Block time is somewhat unreliable and may be intentionally or unintentionally inaccurate, so thresholds based on block time are not ideal. Secondly, BIP9 specified triggers based on the first retarget after a given time, which is non-intuitive. Since each new block must increase the height by one, thresholds based on block height are much more reliable and intuitive and can be calculated exactly for difficulty retarget.
==Specification==
===Parameters===
Each soft fork deployment is specified by the following per-chain parameters (further elaborated below):
# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier.
# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
# The '''startheight''' specifies the height of the first block at which the bit gains its meaning.
# The '''timeoutheight''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is considered failed on all descendants of the block.
# The '''threshold''' specifies the minimum number of block per retarget period which indicate lock-in of the soft fork during the subsequent period.
# The '''minimum_activation_height''' specifies the height of the first block at which the soft fork is allowed to become active.
# The '''lockinontimeout''' boolean if set to true, blocks are required to signal in the final period, ensuring the soft fork has locked in by timeoutheight.
===Selection guidelines===
The following guidelines are suggested for selecting these parameters for a soft fork:
# '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
# '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes.
# '''startheight''' should be set to some block height in the future. If '''minimum_activation_height''' is not going to be set, then '''startheight''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. Some allowance should be made for potential release delays. If '''minimum_activation_height''' is going to be set, then '''startheight''' can be set to be soon after software with parameters is expected to be released. This shifts the time for upgrading from before signaling begins to during the LOCKED_IN state.
# '''timeoutheight''' should be set to a block height when it is considered reasonable to expect the entire economy to have upgraded by, probably at least 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
# '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet.
# '''minimum_activation_height''' should be set to several retarget periods in the future if the '''startheight''' is to be very soon after software with parameters is expected to be released. '''minimum_activation_height''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. This allows more time to be spent in the LOCKED_IN state so that nodes can upgrade. This may be set to 0 to have the LOCKED_IN state be a single retarget period.
# '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligible percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.)
A later deployment using the same bit is possible as long as the startheight is after the previous one's
timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
'''startheight''', '''timeoutheight''', and '''minimum_activation_height''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4032 blocks (2 retarget intervals) after '''startheight'''.
===States===
With each block and soft fork, we associate a deployment state. The possible states are:
# '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
# '''STARTED''' for blocks at or beyond the startheight.
# '''MUST_SIGNAL''' for one retarget period prior to the timeout, if LOCKED_IN was not reached and '''lockinontimeout''' is true.
# '''LOCKED_IN''' for at least one retarget period after the first retarget period with STARTED (or MUST_SIGNAL) blocks of which at least threshold have the associated bit set in nVersion. A soft fork remains in LOCKED_IN until at least '''minimum_activation_height''' is reached.
# '''ACTIVE''' for all blocks after the LOCKED_IN state.
# '''FAILED''' for all blocks after the timeoutheight if LOCKED_IN is not reached.
===Bit flags===
The nVersion block header field is to be interpreted as a 32-bit little-endian integer (as present), and bits are selected within this integer as values (1 << N) where N is the bit number.
Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be
001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.
Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available.
This restricts us to at most 30 independent deployments. By restricting the top 3 bits to 001 we get 29 out of those
for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011).
When a block nVersion does not have top bits 001, it is treated as if all
bits are 0 for the purposes of deployments.
Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on consensus rules.
===New consensus rules===
The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget period have already failed to signal, any further blocks that fail to signal are invalid.
===State transitions===
<img src="bip-0008/states.png" align="middle"></img>
Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight'''.
Regardless of the value of '''lockinontimeout''', if LOCKED_IN is reached, ACTIVE will be reached either one retarget period later, or at '''minimum_activation_height''', whichever comes later.
The genesis block has state DEFINED for each deployment, by definition.
State GetStateForBlock(block) {
if (block.height == 0) {
return DEFINED;
}
All blocks within a retarget period have the same state. This means that if
floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed to have the same state for every
deployment.
if ((block.height % 2016) != 0) {
return GetStateForBlock(block.parent);
}
Otherwise, the next state depends on the previous state:
switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) {
We remain in the initial state until we reach the start block height.
case DEFINED:
if (block.height >= startheight) {
return STARTED;
}
return DEFINED;
After a period in the STARTED state, we tally the bits set,
and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
version numbers.
If the threshold hasn't been met, lockinontimeout is true, and we are at the last period before the timeout, then we transition to MUST_SIGNAL.
If the threshold hasn't been met and we reach the timeout, we transition directly to FAILED.
Note that a block's state never depends on its own nVersion; only on that of its ancestors.
case STARTED:
int count = 0;
walk = block;
for (i = 0; i < 2016; i++) {
walk = walk.parent;
if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) {
++count;
}
}
if (count >= threshold) {
return LOCKED_IN;
} else if (lockinontimeout && block.height + 2016 >= timeoutheight) {
return MUST_SIGNAL;
} else if (block.height >= timeoutheight) {
return FAILED;
}
return STARTED;
If we have finished a period of MUST_SIGNAL, we transition directly to LOCKED_IN.
case MUST_SIGNAL:
return LOCKED_IN;
After at least one retarget period of LOCKED_IN, we automatically transition to ACTIVE if the minimum activation height is reached. Otherwise LOCKED_IN continues.
case LOCKED_IN:
if (block.height >= minimum_activation_height) {
return ACTIVE;
} else {
return LOCKED_IN;
}
And ACTIVE and FAILED are terminal states, which a deployment stays in once they're reached.
case ACTIVE:
return ACTIVE;
case FAILED:
return FAILED;
}
}
'''Implementation'''
It should be noted that the states are maintained along block chain
branches, but may need recomputation when a reorganization happens.
Given that the state for a specific block/deployment combination is completely determined by its ancestry before the
current retarget period (i.e. up to and including its ancestor with height block.height - 1 - (block.height % 2016)),
it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016
block, indexed by its parent.
===Mandatory signalling===
Blocks received while in the MUST_SIGNAL phase must be checked to ensure that they signal as required. For example:
if (GetStateForBlock(block) == MUST_SIGNAL) {
int nonsignal = 0;
walk = block;
while (true) {
if ((walk.nVersion & 0xE0000000) != 0x20000000 || ((walk.nVersion >> bit) & 1) != 1) {
++nonsignal;
if (nonsignal > 2016 - threshold) {
return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal");
}
}
if (walk.nHeight % 2016 == 0) {
// checked every block in this retarget period
break;
}
walk = walk.parent;
}
}
Implementations should be careful not to ban peers that send blocks that are invalid due to not signalling (or blocks that build on those blocks), as that would allow an incompatible chain that is only briefly longer than the compliant chain to cause a split of the p2p network. If that occurred, nodes that have not set ''lockinontimeout'' may not see new blocks in the compliant chain, and thus not reorg to it at the point when it has more work, and would thus not be following the valid chain with the most work.
Implementations with ''lockinontimeout'' set to true may potentially follow a lower work chain than nodes with ''lockinontimeout'' set to false for an extended period. In order for this not to result in a net split nodes with ''lockinontimeout'' set to true, those nodes may need to preferentially connect to each other. Deployments proposing that implementations set ''lockinontimeout'' to true should either use parameters that do not risk there being a higher work alternative chain, or specify a mechanism for implementations that support the deployment to preferentially peer with each other.
===Warning mechanism===
To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion. Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state).
===getblocktemplate changes===
The template request Object is extended to include a new item:
{| class="wikitable"
!colspan=4| template request
|-
! Key !! Required !! Type !! Description
|-
| rules || No || Array of Strings || list of supported softfork deployments, by name
|}
The template Object is also extended:
{| class="wikitable"
!colspan=4| template
|-
! Key !! Required !! Type !! Description
|-
| rules || Yes || Array of Strings || list of softfork deployments, by name, that are active state
|-
| vbavailable || Yes || Object || set of pending, supported softfork deployments; each uses the softfork name as the key, and the softfork bit as its value
|-
| vbrequired || No || Number || bit mask of softfork deployment version bits the server requires enabled in submissions
|}
The "version" key of the template is retained, and used to indicate the server's preference of deployments.
If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF].
Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired".
Servers MUST set bits in "vbrequired" for deployments in MUST_SIGNAL state, to ensure blocks produced are valid.
Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character.
Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113.
If a client does not understand a rule without the prefix, it may use it unmodified for mining.
On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction).
A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified.
=== Reference implementation ===
https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip8
==Contrasted with BIP 9==
* The '''lockinontimeout''' flag is added, providing a way to guarantee transition to LOCKED_IN.
* Block heights are used for the deployment monotonic clock, rather than median-time-past.
==Backwards compatibility==
BIP8 and BIP9 deployments should not share concurrent active deployment bits. Nodes that only implement BIP9 will not activate a BIP8 soft fork if hashpower threshold is not reached by '''timeoutheight''', however, those nodes will still accept the blocks generated by activated nodes.
==Deployments==
A living list of deployment proposals can be found [[bip-0008/assignments.mediawiki|here]].
==References==
[[bip-0009.mediawiki|BIP9]]
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html Mailing list discussion]
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.

6
bip-0008/assignments.mediawiki
View File

@ -1,6 +0,0 @@
==Deployments==
List of deployments.
State can be defined, active, failed. Dates are in UTC.

35
bip-0008/states.dot
View File

@ -1,35 +0,0 @@
digraph {
rankdir=TD;
node [style="rounded,filled,bold", shape=box, fixedsize=true, width=1.5, fontname="Arial"];
edge [weight = 100];
"DEFINED" -> "STARTED" [label="height >= start_height"];
"STARTED" -> "MUST_SIGNAL" [label="height + 2016 >= timeoutheight AND lockinontimeout"];
"STARTED" -> "FAILED" [label="height >= timeoutheight\nAND\nNOT lockinontimeout"];
"LOCKED_IN" -> "ACTIVE" [label="height >= minimum_activation_height"];
"LOCKED_IN":se -> "LOCKED_IN":ne [label="height < minimum_activation_height"];
"MUST_SIGNAL" -> "LOCKED_IN" [label="always"];
edge [weight = 1];
"STARTED" -> "LOCKED_IN" [label="height < timeoutheight\nAND\nthreshold reached"];
"FAILED" -> "LOCKED_IN" [style=invis];
"DEFINED":sw -> "DEFINED":nw;
"STARTED":sw -> "STARTED":nw;
"ACTIVE":sw -> "ACTIVE":nw;
"FAILED":sw -> "FAILED":nw;
"STARTED" [fillcolor="#a0a0ff"];
"MUST_SIGNAL" [fillcolor="#a0a0ff"];
"LOCKED_IN" [fillcolor="#ffffa0"];
"ACTIVE" [fillcolor="#a0ffa0"];
"FAILED" [fillcolor="#ffa0a0"];
{ rank=same; "STARTED" "MUST_SIGNAL" }
{ rank=same; "FAILED" "LOCKED_IN" }
{ rank=sink; "ACTIVE" }
}

BIN
bip-0008/states.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 59 KiB

126
bip-0008/states.svg
View File

@ -1,126 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generated by graphviz version 2.46.1 (0)
-->
<!-- Pages: 1 -->
<svg width="937pt" height="348pt"
viewBox="0.00 0.00 937.00 348.37" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 344.37)">
<polygon fill="white" stroke="transparent" points="-4,4 -4,-344.37 933,-344.37 933,4 -4,4"/>
<!-- DEFINED -->
<g id="node1" class="node">
<title>DEFINED</title>
<path fill="lightgrey" stroke="black" stroke-width="2" d="M114,-333.75C114,-333.75 30,-333.75 30,-333.75 24,-333.75 18,-327.75 18,-321.75 18,-321.75 18,-309.75 18,-309.75 18,-303.75 24,-297.75 30,-297.75 30,-297.75 114,-297.75 114,-297.75 120,-297.75 126,-303.75 126,-309.75 126,-309.75 126,-321.75 126,-321.75 126,-327.75 120,-333.75 114,-333.75"/>
<text text-anchor="middle" x="72" y="-312.05" font-family="Arial" font-size="14.00">DEFINED</text>
</g>
<!-- DEFINED&#45;&gt;DEFINED -->
<g id="edge9" class="edge">
<title>DEFINED:sw&#45;&gt;DEFINED:nw</title>
<path fill="none" stroke="black" d="M18,-297.75C12,-287.25 0,-287.25 0,-315.75 0,-334.01 4.92,-340.57 10.04,-340.17"/>
<polygon fill="black" stroke="black" points="12.41,-342.75 18,-333.75 8.02,-337.3 12.41,-342.75"/>
</g>
<!-- STARTED -->
<g id="node2" class="node">
<title>STARTED</title>
<path fill="#a0a0ff" stroke="black" stroke-width="2" d="M114,-246.75C114,-246.75 30,-246.75 30,-246.75 24,-246.75 18,-240.75 18,-234.75 18,-234.75 18,-222.75 18,-222.75 18,-216.75 24,-210.75 30,-210.75 30,-210.75 114,-210.75 114,-210.75 120,-210.75 126,-216.75 126,-222.75 126,-222.75 126,-234.75 126,-234.75 126,-240.75 120,-246.75 114,-246.75"/>
<text text-anchor="middle" x="72" y="-225.05" font-family="Arial" font-size="14.00">STARTED</text>
</g>
<!-- DEFINED&#45;&gt;STARTED -->
<g id="edge1" class="edge">
<title>DEFINED&#45;&gt;STARTED</title>
<path fill="none" stroke="black" d="M72,-297.55C72,-285.91 72,-270.3 72,-256.99"/>
<polygon fill="black" stroke="black" points="75.5,-256.93 72,-246.93 68.5,-256.93 75.5,-256.93"/>
<text text-anchor="middle" x="155" y="-268.55" font-family="Times,serif" font-size="14.00">height &gt;= start_height</text>
</g>
<!-- STARTED&#45;&gt;STARTED -->
<g id="edge10" class="edge">
<title>STARTED:sw&#45;&gt;STARTED:nw</title>
<path fill="none" stroke="black" d="M18,-210.75C12,-200.25 0,-200.25 0,-228.75 0,-247.01 4.92,-253.57 10.04,-253.17"/>
<polygon fill="black" stroke="black" points="12.41,-255.75 18,-246.75 8.02,-250.3 12.41,-255.75"/>
</g>
<!-- MUST_SIGNAL -->
<g id="node3" class="node">
<title>MUST_SIGNAL</title>
<path fill="#a0a0ff" stroke="black" stroke-width="2" d="M634,-246.75C634,-246.75 550,-246.75 550,-246.75 544,-246.75 538,-240.75 538,-234.75 538,-234.75 538,-222.75 538,-222.75 538,-216.75 544,-210.75 550,-210.75 550,-210.75 634,-210.75 634,-210.75 640,-210.75 646,-216.75 646,-222.75 646,-222.75 646,-234.75 646,-234.75 646,-240.75 640,-246.75 634,-246.75"/>
<text text-anchor="middle" x="592" y="-225.05" font-family="Arial" font-size="14.00">MUST_SIGNAL</text>
</g>
<!-- STARTED&#45;&gt;MUST_SIGNAL -->
<g id="edge2" class="edge">
<title>STARTED&#45;&gt;MUST_SIGNAL</title>
<path fill="none" stroke="black" d="M126.18,-228.75C222.75,-228.75 424.19,-228.75 527.64,-228.75"/>
<polygon fill="black" stroke="black" points="527.94,-232.25 537.94,-228.75 527.94,-225.25 527.94,-232.25"/>
<text text-anchor="middle" x="332" y="-235.55" font-family="Times,serif" font-size="14.00">height + 2016 &gt;= timeoutheight AND lockinontimeout</text>
</g>
<!-- FAILED -->
<g id="node4" class="node">
<title>FAILED</title>
<path fill="#ffa0a0" stroke="black" stroke-width="2" d="M114,-129.75C114,-129.75 30,-129.75 30,-129.75 24,-129.75 18,-123.75 18,-117.75 18,-117.75 18,-105.75 18,-105.75 18,-99.75 24,-93.75 30,-93.75 30,-93.75 114,-93.75 114,-93.75 120,-93.75 126,-99.75 126,-105.75 126,-105.75 126,-117.75 126,-117.75 126,-123.75 120,-129.75 114,-129.75"/>
<text text-anchor="middle" x="72" y="-108.05" font-family="Arial" font-size="14.00">FAILED</text>
</g>
<!-- STARTED&#45;&gt;FAILED -->
<g id="edge3" class="edge">
<title>STARTED&#45;&gt;FAILED</title>
<path fill="none" stroke="black" d="M72,-210.28C72,-191.69 72,-161.99 72,-140.25"/>
<polygon fill="black" stroke="black" points="75.5,-140 72,-130 68.5,-140 75.5,-140"/>
<text text-anchor="middle" x="162.5" y="-181.55" font-family="Times,serif" font-size="14.00">height &gt;= timeoutheight</text>
<text text-anchor="middle" x="162.5" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text>
<text text-anchor="middle" x="162.5" y="-151.55" font-family="Times,serif" font-size="14.00">NOT lockinontimeout</text>
</g>
<!-- LOCKED_IN -->
<g id="node5" class="node">
<title>LOCKED_IN</title>
<path fill="#ffffa0" stroke="black" stroke-width="2" d="M634,-129.75C634,-129.75 550,-129.75 550,-129.75 544,-129.75 538,-123.75 538,-117.75 538,-117.75 538,-105.75 538,-105.75 538,-99.75 544,-93.75 550,-93.75 550,-93.75 634,-93.75 634,-93.75 640,-93.75 646,-99.75 646,-105.75 646,-105.75 646,-117.75 646,-117.75 646,-123.75 640,-129.75 634,-129.75"/>
<text text-anchor="middle" x="592" y="-108.05" font-family="Arial" font-size="14.00">LOCKED_IN</text>
</g>
<!-- STARTED&#45;&gt;LOCKED_IN -->
<g id="edge7" class="edge">
<title>STARTED&#45;&gt;LOCKED_IN</title>
<path fill="none" stroke="black" d="M126.08,-218.75C163.11,-212.29 213.23,-202.95 257,-192.75 329.78,-175.79 346.33,-165.17 419,-147.75 454.78,-139.17 495.06,-130.94 527.74,-124.62"/>
<polygon fill="black" stroke="black" points="528.47,-128.04 537.63,-122.72 527.15,-121.17 528.47,-128.04"/>
<text text-anchor="middle" x="503.5" y="-181.55" font-family="Times,serif" font-size="14.00">height &lt; timeoutheight</text>
<text text-anchor="middle" x="503.5" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text>
<text text-anchor="middle" x="503.5" y="-151.55" font-family="Times,serif" font-size="14.00">threshold reached</text>
</g>
<!-- MUST_SIGNAL&#45;&gt;LOCKED_IN -->
<g id="edge6" class="edge">
<title>MUST_SIGNAL&#45;&gt;LOCKED_IN</title>
<path fill="none" stroke="black" d="M592,-210.28C592,-191.69 592,-161.99 592,-140.25"/>
<polygon fill="black" stroke="black" points="595.5,-140 592,-130 588.5,-140 595.5,-140"/>
<text text-anchor="middle" x="616.5" y="-166.55" font-family="Times,serif" font-size="14.00">always</text>
</g>
<!-- FAILED&#45;&gt;FAILED -->
<g id="edge12" class="edge">
<title>FAILED:sw&#45;&gt;FAILED:nw</title>
<path fill="none" stroke="black" d="M18,-93.75C12,-83.25 0,-83.25 0,-111.75 0,-130.01 4.92,-136.57 10.04,-136.17"/>
<polygon fill="black" stroke="black" points="12.41,-138.75 18,-129.75 8.02,-133.3 12.41,-138.75"/>
</g>
<!-- FAILED&#45;&gt;LOCKED_IN -->
<!-- LOCKED_IN&#45;&gt;LOCKED_IN -->
<g id="edge5" class="edge">
<title>LOCKED_IN:se&#45;&gt;LOCKED_IN:ne</title>
<path fill="none" stroke="black" d="M646,-93.75C652,-83.25 664,-83.25 664,-111.75 664,-130.01 659.08,-136.57 653.96,-136.17"/>
<polygon fill="black" stroke="black" points="655.98,-133.3 646,-129.75 651.59,-138.75 655.98,-133.3"/>
<text text-anchor="middle" x="796.5" y="-108.05" font-family="Times,serif" font-size="14.00">height &lt; minimum_activation_height</text>
</g>
<!-- ACTIVE -->
<g id="node6" class="node">
<title>ACTIVE</title>
<path fill="#a0ffa0" stroke="black" stroke-width="2" d="M634,-42.75C634,-42.75 550,-42.75 550,-42.75 544,-42.75 538,-36.75 538,-30.75 538,-30.75 538,-18.75 538,-18.75 538,-12.75 544,-6.75 550,-6.75 550,-6.75 634,-6.75 634,-6.75 640,-6.75 646,-12.75 646,-18.75 646,-18.75 646,-30.75 646,-30.75 646,-36.75 640,-42.75 634,-42.75"/>
<text text-anchor="middle" x="592" y="-21.05" font-family="Arial" font-size="14.00">ACTIVE</text>
</g>
<!-- LOCKED_IN&#45;&gt;ACTIVE -->
<g id="edge4" class="edge">
<title>LOCKED_IN&#45;&gt;ACTIVE</title>
<path fill="none" stroke="black" d="M592,-93.55C592,-81.91 592,-66.3 592,-52.99"/>
<polygon fill="black" stroke="black" points="595.5,-52.93 592,-42.93 588.5,-52.93 595.5,-52.93"/>
<text text-anchor="middle" x="730.5" y="-64.55" font-family="Times,serif" font-size="14.00">height &gt;= minimum_activation_height</text>
</g>
<!-- ACTIVE&#45;&gt;ACTIVE -->
<g id="edge11" class="edge">
<title>ACTIVE:sw&#45;&gt;ACTIVE:nw</title>
<path fill="none" stroke="black" d="M538,-6.75C532,3.75 520,3.75 520,-24.75 520,-43.01 524.92,-49.57 530.04,-49.17"/>
<polygon fill="black" stroke="black" points="532.41,-51.75 538,-42.75 528.02,-46.3 532.41,-51.75"/>
</g>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 8.4 KiB

30
bip-0009.mediawiki
View File

@ -1,13 +1,15 @@
<pre>
BIP: 9
Title: Version bits with timeout and delay
Authors: Pieter Wuille <pieter.wuille@gmail.com>
Peter Todd <pete@petertodd.org>
Greg Maxwell <greg@xiph.org>
Rusty Russell <rusty@rustcorp.com.au>
Status: Deployed
Author: Pieter Wuille <pieter.wuille@gmail.com>
Peter Todd <pete@petertodd.org>
Greg Maxwell <greg@xiph.org>
Rusty Russell <rusty@rustcorp.com.au>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0009
Status: Final
Type: Informational
Assigned: 2015-10-04
Created: 2015-10-04
License: PD
</pre>
@ -17,9 +19,9 @@ This document specifies a proposed change to the semantics of the 'version' fiel
==Motivation==
[[bip-0034.mediawiki|BIP 34]] introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.
BIP 34 introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.
In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in [[bip-0066.mediawiki|BIP 66]] and [[bip-0065.mediawiki|BIP 65]], which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.
In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66 and BIP 65, which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.
==Specification==
@ -111,13 +113,13 @@ referred to as MTP in the diagram above, and is treated as a monotonic clock def
After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set,
and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016).
The transition to FAILED takes precedence, as otherwise an ambiguity can arise.
The transition to FAILED takes precendence, as otherwise an ambiguity can arise.
There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the
other one simultaneously transitions to STARTED, which would mean both would demand setting the bit.
Note that a block's state never depends on its own nVersion; only on that of its ancestors.
case STARTED:
case STARTED:
if (GetMedianTimePast(block.parent) >= timeout) {
return FAILED;
}
@ -193,9 +195,9 @@ If versionbits is being used, "version" MUST be within the versionbits range of
Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired".
Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character.
Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs [[bip-0016.mediawiki|16]], [[bip-0065.mediawiki|65]], [[bip-0066.mediawiki|66]], [[bip-0068.mediawiki|68]], [[bip-0112.mediawiki|112]], and [[bip-0113.mediawiki|113]].
Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113.
If a client does not understand a rule without the prefix, it may use it unmodified for mining.
On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be [[bip-0034.mediawiki|BIP 34]] (because it modifies coinbase construction) and [[bip-0141.mediawiki|141]] (since it modifies the txid hashing and adds a commitment to the generation transaction).
On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction).
A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified.
==Support for future changes==
@ -203,7 +205,7 @@ A client that does not understand a rule prefixed by '!' must not attempt to pro
The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account.
'''Modified thresholds'''
The 1916 threshold (based on BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
The 1916 threshold (based on in BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
'''Conflicting soft forks'''
At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes.
@ -215,7 +217,7 @@ Soft forks right now are typically treated as booleans: they go from an inactive
The failure timeout allows eventual reuse of bits even if a soft fork was
never activated, so it's clear that the new use of the bit refers to a
new BIP. It's deliberately very coarse-grained, to take into account
new BIP. It's deliberately very course grained, to take into account
reasonable development and deployment delays. There are unlikely to be
enough failed proposals to cause a bit shortage.

2
bip-0009/assignments.mediawiki
View File

@ -29,7 +29,7 @@ State can be defined, active, failed. Dates are in UTC.
| 1
| 2016-11-15 00:00:00
| 2017-11-15 00:00:00
| active since #481824
| -
| 2016-05-01 00:00:00
| 2017-05-01 00:00:00
| active since #834624

22
bip-0009/states.gv
View File

@ -1,22 +0,0 @@
/* 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;
}

BIN
bip-0009/states.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 49 KiB

After

Width:  |  Height:  |  Size: 30 KiB

23
bip-0010.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 10
Layer: Applications
Title: Multi-Sig Transaction Distribution
Authors: Alan Reiner <etotheipi@gmail.com>
Status: Closed
Author: Alan Reiner <etotheipi@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0010
Status: Withdrawn
Type: Informational
Assigned: 2011-10-28
Created: 2011-10-28
</pre>
A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the proposed transaction and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction.
@ -26,7 +28,7 @@ This BIP proposes the following process, with terms in quotes referring to recom
# One party will initiate this process by creating a "Distribution Proposal", which could be abbreviated DP, or TxDP
# The user creating the TxDP (the preparer) will create the transaction as they would like to see it spent, but with blank TxIn scripts (where the signatures scripts will eventually go).
# The proposed transaction will be spending a set of unspent TxOuts available in the blockchain. The full transactions containing these TxOuts will be serialized and included, as well. This so that the values of the TxIns can be verified before signing (the prev-tx-hash is part of the data being signed, but the value is not). By including the full tx, the signing party can verify that the tx matches the OutPoint hash, and then verify input values, all without any access to the blockchain.
# The TxDP will have an "DP ID" or "Unsigned ID" which is the hash of the proposed transaction with blanked scripts, in Base58. This is a specific naming convention to make sure it is not confused with the actual transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected). The final Tx ID can be referred to as its "Broadcast ID", in order to distinguish it from the pre-signed ID.
# The TxDP will have an "DP ID" or "Unsigned ID" which is the hash of the proposed transaction with blanked scripts, in Base58. This is a specific naming convention to make sure it is not confused with the actual the transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected). The final Tx ID can be referred to as its "Broadcast ID", in order to distinguish it from the pre-signed ID.
# The TxDP will have a potentially-unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it.
# Identical TxDP objects with different signatures can be easily combined. This allows one party to send out all the requests for signatures at once, and combine them all when they are received (instead of having to "pass it around".
# For cases where the TxDP might be put into a file or sent via email, it should use .txdp or .btcdp suffix
@ -91,17 +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 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.
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.
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 _SIG_ lines between serializations, though it is not the recommended method for combining TxDPs.
== Changelog ==
* 2014-11-26:
** Withdrawn after Armory stopped using BIP10 and no other projects were known to implement support (see [https://github.com/bitcoin/bips/pull/125 bips#125]).
* 2011-10-28:
** Original Draft published.
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 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.
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.

18
bip-0011.mediawiki
View File

@ -2,11 +2,13 @@
BIP: 11
Layer: Applications
Title: M-of-N Standard Transactions
Authors: Gavin Andresen <gavinandresen@gmail.com>
Status: Deployed
Type: Specification
Assigned: 2011-10-18
Discussion: 2011-10-02
Author: Gavin Andresen <gavinandresen@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0011
Status: Final
Type: Standards Track
Created: 2011-10-18
Post-History: 2011-10-02
</pre>
==Abstract==
@ -21,7 +23,7 @@ A couple of motivating use cases:
* A wallet secured by a "wallet protection service" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business.
* Three-party escrow (buyer, seller, and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).<br />If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins. Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP.
* Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).<br />If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins. Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP.
==Specification==
@ -36,7 +38,7 @@ OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig:
(OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack).
The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accommodate 3-signature transactions, this will be increased to 500 bytes.
The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accomodate 3-signature transactions, this will be increased to 500 bytes.
==Rationale==
@ -52,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/77f21f1583deb89bf3fffe80fe9b181fedb1dd60
https://github.com/gavinandresen/bitcoin-git/tree/op_eval
== Post History ==

16
bip-0012.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 12
Layer: Consensus (soft fork)
Title: OP_EVAL
Authors: Gavin Andresen <gavinandresen@gmail.com>
Status: Closed
Type: Specification
Assigned: 2011-10-18
Author: Gavin Andresen <gavinandresen@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0012
Status: Withdrawn
Type: Standards Track
Created: 2011-10-18
</pre>
==Abstract==
@ -41,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 vulnerabilities.
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.
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 interpret 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 interepret 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.
@ -73,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/77f21f1583deb89bf3fffe80fe9b181fedb1dd60
https://github.com/gavinandresen/bitcoin-git/tree/op_eval
==See Also==

16
bip-0013.mediawiki
View File

@ -2,17 +2,19 @@
BIP: 13
Layer: Applications
Title: Address Format for pay-to-script-hash
Authors: Gavin Andresen <gavinandresen@gmail.com>
Status: Deployed
Type: Specification
Assigned: 2011-10-18
Author: Gavin Andresen <gavinandresen@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0013
Status: Final
Type: Standards Track
Created: 2011-10-18
</pre>
==Abstract==
This BIP describes a new type of Bitcoin address to support arbitrarily complex transactions. Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin.
In essence, an address encoded under this proposal represents the encoded hash of a [https://en.bitcoin.it/wiki/Script script], rather than the encoded hash of an ECDSA public key.
In essence, an address encoded under this proposal represents the encoded hash of a [[script]], rather than the encoded hash of an ECDSA public key.
==Motivation==
@ -20,7 +22,7 @@ Enable "end-to-end" secure wallets and payments to fund escrow transactions or o
==Specification==
The new bitcoin address type is constructed in the same manner as existing bitcoin addresses (see [https://en.bitcoin.it/Base58Check_encoding Base58Check encoding]):
The new bitcoin address type is constructed in the same manner as existing bitcoin addresses (see [[Base58Check encoding]]):
base58-encode: [one-byte version][20-byte hash][4-byte checksum]
@ -48,7 +50,7 @@ This proposal is not backwards compatible, but it fails gracefully-- if an older
==Reference Implementation==
See base58.cpp/base58.h at https://github.com/bitcoin/bitcoin/tree/master/src
See base58.cpp1/base58.h at https://github.com/bitcoin/bitcoin/src
==See Also==

17
bip-0014.mediawiki
View File

@ -2,13 +2,14 @@
BIP: 14
Layer: Peer Services
Title: Protocol Version and User Agent
Authors: Amir Taaki <genjix@riseup.net>
Patrick Strateman <bitcoin-bips@covertinferno.org>
Status: Deployed
Type: Specification
Assigned: 2011-11-10
Discussion: 2011-11-02: https://gnusha.org/pi/bitcoindev/1320268981.72296.YahooMailNeo@web121003.mail.ne1.yahoo.com/
2011-11-10: https://gnusha.org/pi/bitcoindev/1320959761.36702.YahooMailNeo@web121014.mail.ne1.yahoo.com/
Author: Amir Taaki <genjix@riseup.net>
Patrick Strateman <bitcoin-bips@covertinferno.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0014
Status: Final
Type: Standards Track
Created: 2011-11-10
Post-History: 2011-11-02
</pre>
In this document, bitcoin will be used to refer to the protocol while Satoshi will refer to the current client in order to prevent confusion.
@ -27,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 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).
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).
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.

20
bip-0015.mediawiki
View File

@ -2,15 +2,17 @@
BIP: 15
Layer: Applications
Title: Aliases
Authors: Amir Taaki <genjix@riseup.net>
Status: Closed
Type: Specification
Assigned: 2011-12-10
Author: Amir Taaki <genjix@riseup.net>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0015
Status: Deferred
Type: Standards Track
Created: 2011-12-10
</pre>
[[bip-0070.mediawiki|BIP 0070]] (payment protocol) may be seen as the alternative to Aliases.
Using vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is that they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist.
Using vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist.
This document aims to layout through careful argument, a bitcoin alias system. This is a big modification to the protocol that is not easily changed in the future and has big ramifications. There is impetus in getting it correct the first time. Aliases have to be robust and secure.
@ -34,7 +36,7 @@ Their FirstBits alias becomes:
It is enough information to be given the FirstBits alias ''1brmlab''. When someone wishes to make a purchase, without FirstBits, they either have to type out their address laboriously by hand, scan their QR code (which requires a mobile handset that this author does not own) or find their address on the internet to copy and paste into the client to send bitcoins. FirstBits alleviates this impracticality by providing an easy method to make payments.
Together with Vanitygen (vanity generator), it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination.
Together with [[vanitygen|Vanitygen (vanity generator)]], it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination.
However FirstBits has its own problems. One is that the possible aliases one is able to generate is limited by the available computing power available. It may not be feasible to generate a complete or precise alias that is wanted- only approximates may be possible. It is also computationally resource intensive which means a large expenditure of power for generating unique aliases in the future, and may not scale up to the level of individuals at home or participants with hand-held devices in an environment of ubiquitous computing.
@ -206,7 +208,7 @@ NameResolutionService::~NameResolutionService()
void NameResolutionService::ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain)
{
// split address at @ furthest to the right
// split address at @ furthrest to the right
size_t nPosAtsym = strHandle.rfind('@');
strNickname = strHandle.substr(0, nPosAtsym);
strDomain = strHandle.substr(nPosAtsym + 1, strHandle.size());
@ -346,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 retrieves 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 retreives 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).
@ -399,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 information.
See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more informations.

21
bip-0016.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 16
Layer: Consensus (soft fork)
Title: Pay to Script Hash
Authors: Gavin Andresen <gavinandresen@gmail.com>
Status: Deployed
Type: Specification
Assigned: 2012-01-03
Author: Gavin Andresen <gavinandresen@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0016
Status: Final
Type: Standards Track
Created: 2012-01-03
</pre>
==Abstract==
@ -38,7 +40,7 @@ The rules for validating these outpoints when relaying transactions or consideri
# Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint.
# {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey.
These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) <ref>[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]</ref>. There are transactions earlier than 1333238400 in the block chain that fail these new validation rules. <ref>[https://web.archive.org/web/20141122040355/http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]</ref>. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details).
These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) <ref>[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]</ref>. There are transaction earlier than 1333238400 in the block chain that fail these new validation rules. <ref>[http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]</ref>. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details).
For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is:
@ -56,7 +58,7 @@ Examples:
+3 signature operations:
{2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG}
+22 signature operations:
+22 signature operations
{OP_CHECKSIG OP_IF OP_CHECKSIGVERIFY OP_ELSE OP_CHECKMULTISIGVERIFY OP_ENDIF}
==Rationale==
@ -72,7 +74,7 @@ The signature operation counting rules are intended to be easy and quick to impl
There is a 1-confirmation attack on old implementations, but it is expensive and difficult in practice. The attack is:
# Attacker creates a pay-to-script-hash transaction that is valid as seen by old software, but invalid for new implementation, and sends themselves some coins using it.
# Attacker also creates a standard transaction that spends the pay-to-script-hash transaction, and pays the victim who is running old software.
# Attacker also creates a standard transaction that spends the pay-to-script transaction, and pays the victim who is running old software.
# Attacker mines a block that contains both transactions.
If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block.
@ -99,7 +101,7 @@ If a majority of hashing power does not support the new validation rules, then r
===520-byte limitation on serialized script size===
As a consequence of the requirement for backwards compatibility the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus it is not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes.
As a consequence of the requirement for backwards compatiblity the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus it is not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes.
==Reference Implementation==
@ -114,5 +116,4 @@ https://gist.github.com/gavinandresen/3966071
* [[bip-0016/qa.mediawiki|Quality Assurance test checklist]]
== References ==
<references/>
<references>

2
bip-0016/qa.mediawiki
View File

@ -1,4 +1,4 @@
This page is a Quality Assurance test plan for [[../bip-0016.mediawiki|BIP 16]]. If you see a test missing, please add it.
This page is a Quality Assurance test plan for [[BIP 16]]. If you see a test missing, please add it.
If you can help test, please edit this page to sign-off on it.
{| class="wikitable"

12
bip-0017.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 17
Layer: Consensus (soft fork)
Title: OP_CHECKHASHVERIFY (CHV)
Authors: Luke Dashjr <luke+bip17@dashjr.org>
Status: Closed
Type: Specification
Assigned: 2012-01-18
Author: Luke Dashjr <luke+bip17@dashjr.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0017
Status: Withdrawn
Type: Standards Track
Created: 2012-01-18
License: BSD-2-Clause
</pre>
@ -84,7 +86,7 @@ Avoiding a block-chain split by malicious pay-to-script transactions requires ca
* A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners.
To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.
To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.
To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "p2sh/CHV" in the input of the coinbase transaction for blocks that they create.

10
bip-0018.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 18
Layer: Consensus (soft fork)
Title: hashScriptCheck
Authors: Luke Dashjr <luke+bip17@dashjr.org>
Status: Complete
Type: Specification
Assigned: 2012-01-27
Author: Luke Dashjr <luke+bip17@dashjr.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0018
Status: Proposed
Type: Standards Track
Created: 2012-01-27
License: BSD-2-Clause
</pre>

12
bip-0019.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 19
Layer: Applications
Title: M-of-N Standard Transactions (Low SigOp)
Authors: Luke Dashjr <luke+bip17@dashjr.org>
Status: Closed
Type: Specification
Assigned: 2012-01-30
Author: Luke Dashjr <luke+bip17@dashjr.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0019
Status: Draft
Type: Standards Track
Created: 2012-01-30
License: BSD-2-Clause
</pre>
@ -44,7 +46,7 @@ But only for n less than or equal to 3.
These transactions are redeemed using a standard scriptSig:
...signatures...
The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accommodate 3-signature transactions, this will be increased to 500 bytes.
The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accomodate 3-signature transactions, this will be increased to 500 bytes.
===Templates===
scriptPubKey:

19
bip-0020.mediawiki
View File

@ -2,12 +2,13 @@
BIP: 20
Layer: Applications
Title: URI Scheme
Authors: Luke Dashjr <luke+bip@dashjr.org>
Status: Closed
Type: Specification
Assigned: 2011-01-10
Author: Luke Dashjr <luke+bip@dashjr.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0020
Status: Replaced
Type: Standards Track
Created: 2011-01-10
License: BSD-2-Clause
Proposed-Replacement: 21
</pre>
BIP 0020 is based off an earlier document by Nils Schneider. '''And has been replaced by BIP 0021'''
@ -33,7 +34,7 @@ Graphical bitcoin clients SHOULD register themselves as the handler for the "bit
=== BNF grammar ===
(See also [[#simpler-syntax|a simpler representation of syntax]])
(See also [[#Simpler syntax|a simpler representation of syntax]])
bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = base58 *base58
@ -53,8 +54,8 @@ Graphical bitcoin clients SHOULD register themselves as the handler for the "bit
*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: message that is shown to the user after scanning the QR code
*size: amount of base bitcoin units ([[#transfer-amountsize|see below]])
*message: message that shown to the user after scanning the QR code
*size: amount of base bitcoin units ([[#Transfer amount/size|see below]])
*send: used to send bitcoin, rather than to request them
*(others): optional, for future extensions
@ -96,7 +97,7 @@ Make it possible for later generations to improve our work, to mend our errors,
=== Simpler syntax ===
This section is non-normative and does not cover all possible syntax.
Please see the [[#bnf-grammar|BNF grammar]] above for the normative syntax.
Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax.
[foo] means optional, &lt;bar&gt; are placeholders

38
bip-0021.mediawiki
View File

@ -2,21 +2,15 @@
BIP: 21
Layer: Applications
Title: URI Scheme
Authors: Nils Schneider <nils.schneider@gmail.com>
Matt Corallo <bip21@bluematt.me>
Status: Closed
Type: Specification
Assigned: 2012-01-29
Replaces: 20
Proposed-Replacement: 321
Author: Nils Schneider <nils.schneider@gmail.com>
Matt Corallo <bip21@bluematt.me>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0021
Status: Final
Type: Standards Track
Created: 2012-01-29
</pre>
=Superseded by BIP 321=
This BIP has been superseded and replaced with BIP 321. Please see [[bip-0321.mediawiki|BIP 321]] instead.
=Original BIP=
This BIP is a modification of an earlier [[bip-0020.mediawiki|BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed.
==Abstract==
@ -43,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
@ -63,10 +57,11 @@ The scheme component ("bitcoin:") is case-insensitive, and implementations must
*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: message that describes the transaction to the user ([[#examples|see examples below]])
*message: message that describes the transaction to the user ([[#Examples|see examples below]])
*size: amount of base bitcoin units ([[#Transfer amount/size|see below]])
*(others): optional, for future extensions
==== Transfer amount ====
==== Transfer amount/size ====
If an amount is provided, it MUST be specified in decimal BTC.
All amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions.
@ -106,8 +101,6 @@ Please see the BNF grammar above for the normative syntax.
=== Examples ===
Note: The addresses used in these examples are intentionally invalid to prevent accidental transactions.
Just the address:
bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W
@ -128,6 +121,11 @@ Some future version that has variables which are (currently) not understood but
Characters must be URI encoded properly.
== Reference Implementation ==
== 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.
Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858.
=== Libraries ===
* Javascript - https://github.com/bitcoinjs/bip21
* Java - https://github.com/SandroMachado/BitcoinPaymentURI
* Swift - https://github.com/SandroMachado/BitcoinPaymentURISwift

20
bip-0022.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 22
Layer: API/RPC
Title: getblocktemplate - Fundamentals
Authors: Luke Dashjr <luke+bip22@dashjr.org>
Status: Deployed
Type: Specification
Assigned: 2012-02-28
Author: Luke Dashjr <luke+bip22@dashjr.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0022
Status: Final
Type: Standards Track
Created: 2012-02-28
License: BSD-2-Clause
</pre>
@ -24,7 +26,7 @@ This BIP is licensed under the BSD 2-clause license.
A JSON-RPC method is defined, called "getblocktemplate".
It accepts exactly one argument, which MUST be an Object of request parameters.
If the request parameters include a "mode" key, that is used to explicitly select between the default "template" request or a [[bip-0023.mediawiki#block-proposal|"proposal"]].
If the request parameters include a "mode" key, that is used to explicitly select between the default "template" request or a [[bip-0023.mediawiki#Block Proposal|"proposal"]].
Block template creation can be influenced by various parameters:
{| class="wikitable"
@ -32,7 +34,7 @@ Block template creation can be influenced by various parameters:
|-
! Key !! Required !! Type !! Description
|-
| capabilities || No || Array of Strings || SHOULD contain a list of the following, to indicate client-side support: [[#optional-long-polling|"longpoll"]], "coinbasetxn", "coinbasevalue", [[bip-0023.mediawiki#block-proposal|"proposal"]], [[bip-0023.mediawiki#logical-services|"serverlist"]], "workid", and any of the [[bip-0023.mediawiki#mutations|mutations]]
| capabilities || No || Array of Strings || SHOULD contain a list of the following, to indicate client-side support: [[#Optional: Long Polling|"longpoll"]], "coinbasetxn", "coinbasevalue", [[bip-0023.mediawiki#Block Proposal|"proposal"]], [[bip-0023.mediawiki#Logical Services|"serverlist"]], "workid", and any of the [[bip-0023.mediawiki#Mutations|mutations]]
|-
| mode || No || String || MUST be "template" or omitted
|}
@ -55,17 +57,17 @@ getblocktemplate MUST return a JSON Object containing the following keys:
|-
| sizelimit || No || Number || number of bytes allowed in blocks
|-
| transactions || Should || Array of Objects || Objects containing [[#transactions-object-format|information for Bitcoin transactions]] (excluding coinbase)
| transactions || Should || Array of Objects || Objects containing [[#Transactions Object Format|information for Bitcoin transactions]] (excluding coinbase)
|-
| version || Yes || Number || always 1 or 2 (at least for bitcoin) - clients MUST understand the implications of the version they use (eg, comply with [[bip-0034.mediawiki|BIP 0034]] for version 2)
|-
| coinbaseaux || No || Object || data that SHOULD be included in the coinbase's scriptSig content. Only the values (hexadecimal byte-for-byte) in this Object should be included, not the keys. This does not include the block height, which is required to be included in the scriptSig by [[bip-0034.mediawiki|BIP 0034]]. It is advisable to encode values inside "PUSH" opcodes, so as to not inadvertently expend SIGOPs (which are counted toward limits, despite not being executed).
|-
| coinbasetxn || this or ↓ || Object || [[#transactions-object-format|information for coinbase transaction]]
| coinbasetxn || this or ↓ || Object || [[#Transactions Object Format|information for coinbase transaction]]
|-
| coinbasevalue || this or ↑ || Number || total funds available for the coinbase (in Satoshis)
|-
| workid || No || String || if provided, this value must be returned with results (see [[#block-submission|Block Submission]])
| workid || No || String || if provided, this value must be returned with results (see [[#Block Submission|Block Submission]])
|}
==== Transactions Object Format ====

24
bip-0023.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 23
Layer: API/RPC
Title: getblocktemplate - Pooled Mining
Authors: Luke Dashjr <luke+bip22@dashjr.org>
Status: Deployed
Type: Specification
Assigned: 2012-02-28
Author: Luke Dashjr <luke+bip22@dashjr.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0023
Status: Final
Type: Standards Track
Created: 2012-02-28
License: BSD-2-Clause
</pre>
@ -27,15 +29,15 @@ Something can be said to have BIP 23 Level 1 support if it implements at least:
* [http://www.ietf.org/rfc/rfc1945.txt RFC 1945]
* [http://json-rpc.org/wiki/specification JSON-RPC 1.0]
* [[bip-0022.mediawiki|BIP 22 (non-optional sections)]]
* [[bip-0022.mediawiki#optional-long-polling|BIP 22 Long Polling]]
* [[#basic-pool-extensions|BIP 23 Basic Pool Extensions]]
* [[#mutations|BIP 23 Mutation "coinbase/append"]]
* [[#submission-abbreviation|BIP 23 Submission Abbreviation "submit/coinbase"]]
* [[#mutations|BIP 23 Mutation "time/increment"]] (only required for servers)
* [[bip-0022.mediawiki#Optional: Long Polling|BIP 22 Long Polling]]
* [[#Basic Pool Extensions|BIP 23 Basic Pool Extensions]]
* [[#Mutations|BIP 23 Mutation "coinbase/append"]]
* [[#Submission Abbreviation|BIP 23 Submission Abbreviation "submit/coinbase"]]
* [[#Mutations|BIP 23 Mutation "time/increment"]] (only required for servers)
It can be said to have BIP 23 Level 2 support if it also implements:
* [[#mutations|BIP 23 Mutation "transactions/add"]]
* [[#block-proposals|BIP 23 Block Proposals]]
* [[#Mutations|BIP 23 Mutation "transactions/add"]]
* [[#Block Proposals|BIP 23 Block Proposals]]
===Basic Pool Extensions===

12
bip-0030.mediawiki
View File

@ -2,15 +2,17 @@
BIP: 30
Layer: Consensus (soft fork)
Title: Duplicate transactions
Authors: Pieter Wuille <pieter.wuille@gmail.com>
Status: Deployed
Type: Specification
Assigned: 2012-02-22
Author: Pieter Wuille <pieter.wuille@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0030
Status: Final
Type: Standards Track
Created: 2012-02-22
License: BSD-2-Clause
</pre>
==Abstract==
This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementation has with them.
This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementations has with them.
==Copyright==

10
bip-0031.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 31
Layer: Peer Services
Title: Pong message
Authors: Mike Hearn <hearn@google.com>
Status: Deployed
Type: Specification
Assigned: 2012-04-11
Author: Mike Hearn <hearn@google.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0031
Status: Final
Type: Standards Track
Created: 2012-04-11
</pre>
==Abstract==

94
bip-0032.mediawiki
View File

@ -3,17 +3,17 @@ RECENT CHANGES:
* (30 Apr 2013) Switched from multiplication by I<sub>L</sub> to addition of I<sub>L</sub> (faster, easier implementation)
* (25 May 2013) Added test vectors
* (15 Jan 2014) Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions.
* (24 Feb 2017) Added test vectors for hardened derivation with leading zeros
* (4 Nov 2020) Added new test vectors for hardened derivation with leading zeros
<pre>
BIP: 32
Layer: Applications
Title: Hierarchical Deterministic Wallets
Authors: Pieter Wuille <pieter.wuille@gmail.com>
Status: Deployed
Author: Pieter Wuille <pieter.wuille@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0032
Status: Final
Type: Informational
Assigned: 2012-02-11
Created: 2012-02-11
License: BSD-2-Clause
</pre>
@ -23,7 +23,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 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.
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.
==Copyright==
@ -35,7 +35,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 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.
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.
==Specification: Key derivation==
@ -50,10 +50,10 @@ Addition (+) of two coordinate pair is defined as application of the EC group op
Concatenation (||) is the operation of appending one byte sequence onto another.
As standard conversion functions, we assume:
* point(p): returns the coordinate pair resulting from EC point multiplication (repeated application of the EC group operation) of the secp256k1 base point with the integer p (i.e., the operation used to compute a public key from a private key).
* point(p): returns the coordinate pair resulting from EC point multiplication (repeated application of the EC group operation) of the secp256k1 base point with the integer p.
* ser<sub>32</sub>(i): serialize a 32-bit unsigned integer i as a 4-byte sequence, most significant byte first.
* ser<sub>256</sub>(p): serializes the integer p as a 32-byte sequence, most significant byte first.
* ser<sub>P</sub>(P): serializes the coordinate pair P = (x,y) (i.e., the public key) as a byte sequence using [https://www.secg.org/sec1-v2.pdf SEC1]'s compressed form: (0x02 or 0x03) || ser<sub>256</sub>(x), where the header byte depends on the parity of the omitted y coordinate.
* ser<sub>P</sub>(P): serializes the coordinate pair P = (x,y) as a byte sequence using SEC1's compressed form: (0x02 or 0x03) || ser<sub>256</sub>(x), where the header byte depends on the parity of the omitted y coordinate.
* parse<sub>256</sub>(p): interprets a 32-byte sequence as a 256-bit number, most significant byte first.
@ -102,7 +102,7 @@ The function N((k, c)) &rarr; (K, c) computes the extended public key correspond
To compute the public child key of a parent private key:
* N(CKDpriv((k<sub>par</sub>, c<sub>par</sub>), i)) (works always).
* CKDpub(N(k<sub>par</sub>, c<sub>par</sub>), 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 below 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 for more information.
====Public parent key &rarr; private child key====
@ -117,25 +117,25 @@ To shorten notation, we will write CKDpriv(CKDpriv(CKDpriv(m,3<sub>H</sub>),2),5
* N(m/a<sub>H</sub>/b/c) = N(m/a<sub>H</sub>/b)/c = N(m/a<sub>H</sub>)/b/c.
However, N(m/a<sub>H</sub>) cannot be rewritten as N(m)/a<sub>H</sub>, as the latter is not possible.
Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public key allows reconstruction of all descendant non-hardened public keys.
Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public keys allows reconstruction of all descendant non-hardened public keys.
===Key identifiers===
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized ECDSA public key K, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself).
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized ECSDA public key K, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself).
The first 32 bits of the identifier are called the key fingerprint.
===Serialization format===
Extended public and private keys are serialized as follows:
* 4 bytes: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 derived keys, ....
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)
* 4 bytes: child number. This is ser<sub>32</sub>(i) for i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. (0x00000000 if master key)
* 32 bytes: the chain code
* 33 bytes: the public key or private key data (ser<sub>P</sub>(K) for public keys, 0x00 || ser<sub>256</sub>(k) for private keys)
This 78 byte structure can be encoded like other Bitcoin data in Base58, by first adding 32 checksum bits (derived from the double SHA-256 checksum), and then converting to the Base58 representation. This results in a Base58-encoded string of exactly 111 characters. Because of the choice of the version bytes, the Base58 representation will start with "xprv" or "xpub" on mainnet, "tprv" or "tpub" on testnet.
This 78 byte structure can be encoded like other Bitcoin data in Base58, by first adding 32 checksum bits (derived from the double SHA-256 checksum), and then converting to the Base58 representation. This results in a Base58-encoded string of up to 112 characters. Because of the choice of the version bytes, the Base58 representation will start with "xprv" or "xpub" on mainnet, "tprv" or "tpub" on testnet.
Note that the fingerprint of the parent only serves as a fast way to detect parent and child nodes in software, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.
@ -149,13 +149,13 @@ The total number of possible extended keypairs is almost 2<sup>512</sup>, but th
* Calculate I = HMAC-SHA512(Key = "Bitcoin seed", Data = S)
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.
* Use parse<sub>256</sub>(I<sub>L</sub>) as master secret key, and I<sub>R</sub> as master chain code.
In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or parse<sub>256</sub>(I<sub>L</sub>) ≥ n, the master key is invalid.
In case I<sub>L</sub> is 0 or ≥n, the master key is invalid.
<img src=bip-0032/derivation.png></img>
==Specification: Wallet structure==
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. The layout defined in this section is a default only, though clients are encouraged to mimic it for compatibility, even if not all features are supported.
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. The layout defined in this section is a default only, though clients are encouraged to mimick it for compatibility, even if not all features are supported.
===The default wallet layout===
@ -182,7 +182,7 @@ When a business has several independent offices, they can all use wallets derive
====Recurrent business-to-business transactions: N(m/i<sub>H</sub>/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 a variable payout address.
Such a mechanism could also be used by mining pool operators as variable payout address.
====Unsecure money receiver: N(m/i<sub>H</sub>/0)====
@ -199,7 +199,7 @@ In addition to the expectations from the EC public-key cryptography itself:
the intended security properties of this standard are:
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.
* Given any number (2 ≤ N ≤ 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (k<sub>par</sub>,c<sub>par</sub>) such that for each j in (0..N-1) CKDpriv((k<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.
Note however that the following properties do not exist:
Note however that the following properties does not exist:
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a non-hardened child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>.
@ -210,7 +210,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 keys 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 key never risks compromising the master or other accounts.
==Test Vectors==
@ -259,53 +259,31 @@ Seed (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c
** ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt
** ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j
===Test vector 3===
==Implementations==
These vectors test for the retention of leading zeros. See [https://github.com/bitpay/bitcore-lib/issues/47 bitpay/bitcore-lib#47] and [https://github.com/iancoleman/bip39/issues/58 iancoleman/bip39#58] for more information.
Two Python implementations exist:
Seed (hex): 4b381541583be4423346c643850da4b320e46a87ae3d2a4e6da11eba819cd4acba45d239319ac14f863b8d5ab5a0d0c64d2e8a1e7d1457df2e5a3c51c73235be
* Chain m
** ext pub: xpub661MyMwAqRbcEZVB4dScxMAdx6d4nFc9nvyvH3v4gJL378CSRZiYmhRoP7mBy6gSPSCYk6SzXPTf3ND1cZAceL7SfJ1Z3GC8vBgp2epUt13
** ext prv: xprv9s21ZrQH143K25QhxbucbDDuQ4naNntJRi4KUfWT7xo4EKsHt2QJDu7KXp1A3u7Bi1j8ph3EGsZ9Xvz9dGuVrtHHs7pXeTzjuxBrCmmhgC6
* Chain m/0<sub>H</sub>
** ext pub: xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y
** ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L
PyCoin (https://github.com/richardkiss/pycoin) is a suite of utilities for dealing with Bitcoin that includes BIP0032 wallet features. BIP32Utils (https://github.com/jmcorgan/bip32utils) is a library and command line interface specifically focused on BIP0032 wallets and scripting.
===Test vector 4===
2 Java implementations exist: https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java and https://github.com/bushidowallet/bushido-java-core/tree/master/src/main/java/com/bushidowallet/core/bitcoin/bip32
These vectors test for the retention of leading zeros. See [https://github.com/btcsuite/btcutil/issues/172 btcsuite/btcutil#172] for more information.
A C++ implementation is available at https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinCore/src/hdkeys.h
Seed (hex): 3ddd5602285899a946114506157c7997e5444528f3003f6134712147db19b678
* Chain m
** ext pub: xpub661MyMwAqRbcGczjuMoRm6dXaLDEhW1u34gKenbeYqAix21mdUKJyuyu5F1rzYGVxyL6tmgBUAEPrEz92mBXjByMRiJdba9wpnN37RLLAXa
** ext prv: xprv9s21ZrQH143K48vGoLGRPxgo2JNkJ3J3fqkirQC2zVdk5Dgd5w14S7fRDyHH4dWNHUgkvsvNDCkvAwcSHNAQwhwgNMgZhLtQC63zxwhQmRv
* Chain m/0<sub>H</sub>
** ext pub: xpub69AUMk3qDBi3uW1sXgjCmVjJ2G6WQoYSnNHyzkmdCHEhSZ4tBok37xfFEqHd2AddP56Tqp4o56AePAgCjYdvpW2PU2jbUPFKsav5ut6Ch1m
** ext prv: xprv9vB7xEWwNp9kh1wQRfCCQMnZUEG21LpbR9NPCNN1dwhiZkjjeGRnaALmPXCX7SgjFTiCTT6bXes17boXtjq3xLpcDjzEuGLQBM5ohqkao9G
* Chain m/0<sub>H</sub>/1<sub>H</sub>
** ext pub: xpub6BJA1jSqiukeaesWfxe6sNK9CCGaujFFSJLomWHprUL9DePQ4JDkM5d88n49sMGJxrhpjazuXYWdMf17C9T5XnxkopaeS7jGk1GyyVziaMt
** ext prv: xprv9xJocDuwtYCMNAo3Zw76WENQeAS6WGXQ55RCy7tDJ8oALr4FWkuVoHJeHVAcAqiZLE7Je3vZJHxspZdFHfnBEjHqU5hG1Jaj32dVoS6XLT1
An Objective-C implementation is available at https://github.com/oleganza/CoreBitcoin/blob/master/CoreBitcoin/BTCKeychain.h
===Test vector 5===
A Ruby implementation is available at https://github.com/GemHQ/money-tree
These vectors test that invalid extended keys are recognized as invalid.
Two Go implementations exist:
* xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6LBpB85b3D2yc8sfvZU521AAwdZafEz7mnzBBsz4wKY5fTtTQBm (pubkey version / prvkey mismatch)
* xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFGTQQD3dC4H2D5GBj7vWvSQaaBv5cxi9gafk7NF3pnBju6dwKvH (prvkey version / pubkey mismatch)
* xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6Txnt3siSujt9RCVYsx4qHZGc62TG4McvMGcAUjeuwZdduYEvFn (invalid pubkey prefix 04)
* xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFGpWnsj83BHtEy5Zt8CcDr1UiRXuWCmTQLxEK9vbz5gPstX92JQ (invalid prvkey prefix 04)
* xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6N8ZMMXctdiCjxTNq964yKkwrkBJJwpzZS4HS2fxvyYUA4q2Xe4 (invalid pubkey prefix 01)
* xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFAzHGBP2UuGCqWLTAPLcMtD9y5gkZ6Eq3Rjuahrv17fEQ3Qen6J (invalid prvkey prefix 01)
* xprv9s2SPatNQ9Vc6GTbVMFPFo7jsaZySyzk7L8n2uqKXJen3KUmvQNTuLh3fhZMBoG3G4ZW1N2kZuHEPY53qmbZzCHshoQnNf4GvELZfqTUrcv (zero depth with non-zero parent fingerprint)
* xpub661no6RGEX3uJkY4bNnPcw4URcQTrSibUZ4NqJEw5eBkv7ovTwgiT91XX27VbEXGENhYRCf7hyEbWrR3FewATdCEebj6znwMfQkhRYHRLpJ (zero depth with non-zero parent fingerprint)
* xprv9s21ZrQH4r4TsiLvyLXqM9P7k1K3EYhA1kkD6xuquB5i39AU8KF42acDyL3qsDbU9NmZn6MsGSUYZEsuoePmjzsB3eFKSUEh3Gu1N3cqVUN (zero depth with non-zero index)
* xpub661MyMwAuDcm6CRQ5N4qiHKrJ39Xe1R1NyfouMKTTWcguwVcfrZJaNvhpebzGerh7gucBvzEQWRugZDuDXjNDRmXzSZe4c7mnTK97pTvGS8 (zero depth with non-zero index)
* DMwo58pR1QLEFihHiXPVykYB6fJmsTeHvyTp7hRThAtCX8CvYzgPcn8XnmdfHGMQzT7ayAmfo4z3gY5KfbrZWZ6St24UVf2Qgo6oujFktLHdHY4 (unknown extended key version)
* DMwo58pR1QLEFihHiXPVykYB6fJmsTeHvyTp7hRThAtCX8CvYzgPcn8XnmdfHPmHJiEDXkTiJTVV9rHEBUem2mwVbbNfvT2MTcAqj3nesx8uBf9 (unknown extended key version)
* xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzF93Y5wvzdUayhgkkFoicQZcP3y52uPPxFnfoLZB21Teqt1VvEHx (private key 0 not in 1..n-1)
* xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFAzHGBP2UuGCqWLTAPLcMtD5SDKr24z3aiUvKr9bJpdrcLg1y3G (private key n not in 1..n-1)
* xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6Q5JXayek4PRsn35jii4veMimro1xefsM58PgBMrvdYre8QyULY (invalid pubkey 020000000000000000000000000000000000000000000000000000000000000007)
* xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHL (invalid checksum)
hdkeychain (https://github.com/conformal/btcutil/tree/master/hdkeychain) provides an API for bitcoin hierarchical deterministic extended keys (BIP0032). Go HD Wallet (https://github.com/WeMeetAgain/go-hdwallet).
Two JavaScript implementations exist: available at https://github.com/sarchar/brainwallet.github.com/tree/bip32 and https://github.com/bitpay/bitcore
A PHP implemetation is available at https://github.com/Bit-Wasp/bitcoin-lib-php
A C# implementation is available at https://github.com/NicolasDorier/NBitcoin (ExtKey, ExtPubKey)
A Haskell implementation is available at https://github.com/haskoin/haskoin together with a CLI interface at https://github.com/np/hx
==Acknowledgements==

10
bip-0033.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 33
Layer: Peer Services
Title: Stratized Nodes
Authors: Amir Taaki <genjix@riseup.net>
Status: Closed
Type: Specification
Assigned: 2012-05-15
Author: Amir Taaki <genjix@riseup.net>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0033
Status: Draft
Type: Standards Track
Created: 2012-05-15
</pre>
== Abstract ==

12
bip-0034.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 34
Layer: Consensus (soft fork)
Title: Block v2, Height in Coinbase
Authors: Gavin Andresen <gavinandresen@gmail.com>
Status: Deployed
Type: Specification
Assigned: 2012-07-06
Author: Gavin Andresen <gavinandresen@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0034
Status: Final
Type: Standards Track
Created: 2012-07-06
</pre>
==Abstract==
@ -20,7 +22,7 @@ Bitcoin blocks and transactions are versioned binary structures. Both currently
==Specification==
# Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them).
# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "minimally encoded serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 150 or so years with 2<sup>23</sup>-1 blocks), following bytes are little-endian representation of the number (including a sign bit). Height is the height of the mined block in the block chain, where the genesis block is height zero (0).
# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 150 or so years with 2<sup>23</sup>-1 blocks), following bytes are little-endian representation of the number (including a sign bit). Height is the height of the mined block in the block chain, where the genesis block is height zero (0).
# 75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100)
# 95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100)

14
bip-0035.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 35
Layer: Peer Services
Title: mempool message
Authors: Jeff Garzik <jgarzik@exmulti.com>
Status: Deployed
Type: Specification
Assigned: 2012-08-16
Author: Jeff Garzik <jgarzik@exmulti.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0035
Status: Final
Type: Standards Track
Created: 2012-08-16
</pre>
==Abstract==
@ -14,7 +16,7 @@ Make a network node's transaction memory pool accessible via a new "mempool" mes
==Motivation==
Several use cases make it desirable to expose a network node's transaction memory pool:
Several use cases make it desireable 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.
@ -22,7 +24,7 @@ Several use cases make it desirable to expose a network node's transaction memor
==Specification==
# The mempool message is defined as an empty message where pchCommand == "mempool"
# Upon receipt of a "mempool" message, the node will respond with an "inv" message containing MSG_TX hashes of all the transactions in the node's transaction memory pool, if any.
# Upon receipt of a "mempool" message, the node will respond with an "inv" message containing MSG_TX hashes of all the transactions in the node's transaction memory pool, if any.
# The typical node behavior in response to an "inv" is "getdata". However, the reference Satoshi implementation ignores requests for transaction hashes outside that which is recently relayed. To support "mempool", an implementation must extend its "getdata" message support to querying the memory pool.
# Feature discovery is enabled by checking two "version" message attributes:
## Protocol version >= 60002

16
bip-0036.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 36
Layer: Peer Services
Title: Custom Services
Authors: Stefan Thomas <justmoon@members.fsf.org>
Status: Closed
Type: Specification
Assigned: 2012-08-03
Author: Stefan Thomas <justmoon@members.fsf.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0036
Status: Draft
Type: Standards Track
Created: 2012-08-03
License: PD
</pre>
@ -24,7 +26,7 @@ Two new fields are added to the <code>version</code> command, after <code>extra_
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || service_count || [[Protocol_specification#variable-length-integer|var_int]] || Number of extra services
| 1+ || service_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of extra services
|-
| ? || service_list || service[] || List of service definitions
|}
@ -34,11 +36,11 @@ The service definitions <code>service[]</code> are given in the following format
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || service_name || [[#variable-length-string|var_str]] || Unique service identifier
| ? || service_name || [[#Variable length string|var_str]] || Unique service identifier
|-
| 4 || service_version || uint32_t || Identifies service version being used by the node
|-
| ? || service_data || [[#variable-length-string|var_str]] || Additional service-specific data
| ? || service_data || [[#Variable length string|var_str]] || Additional service-specific data
|}
A node MUST NOT announce two services with the same <code>service_name</code>. If a remote node sends such a <code>version</code> message the client MAY disconnect.

12
bip-0037.mediawiki
View File

@ -2,13 +2,13 @@
BIP: 37
Layer: Peer Services
Title: Connection Bloom filtering
Authors: Mike Hearn <hearn@google.com>
Matt Corallo <bip37@bluematt.me>
Author: Mike Hearn <hearn@google.com>
Matt Corallo <bip37@bluematt.me>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0037
Status: Deployed
Type: Specification
Assigned: 2012-10-24
Status: Final
Type: Standards Track
Created: 2012-10-24
License: PD
</pre>
@ -159,7 +159,7 @@ A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in
** Check whether this node corresponds to a leaf node (transaction) that is to be included OR any parent thereof:
*** If so, append a '1' bit to the flag bits
*** Otherwise, append a '0' bit.
** Check whether this node is an internal node (non-leaf) AND is the parent of an included leaf node:
** Check whether this node is a internal node (non-leaf) AND is the parent of an included leaf node:
*** If so:
**** Descend into its left child node, and process the subtree beneath it entirely (depth-first).
**** If this node has a right child node too, descend into it as well.

50
bip-0038.mediawiki
View File

@ -2,13 +2,13 @@
BIP: 38
Layer: Applications
Title: Passphrase-protected private key
Authors: Mike Caldwell <mcaldwell@swipeclock.com>
Aaron Voisine <voisine@gmail.com>
Author: Mike Caldwell <mcaldwell@swipeclock.com>
Aaron Voisine <voisine@gmail.com>
Comments-Summary: Unanimously Discourage for implementation
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0038
Status: Deployed
Type: Specification
Assigned: 2012-11-20
Status: Draft (Some confusion applies: The announcements for this never made it to the list, so it hasn't had public discussion)
Type: Standards Track
Created: 2012-11-20
License: PD
</pre>
@ -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.
@ -64,9 +64,9 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a base58check encoded P2PKH bitcoin address using the DER compressed public key format. When not set, it should be a base58check encoded P2PKH bitcoin address using the DER uncompressed public key format.
*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 indicates whether a lot and sequence number are encoded into the first factor, and activates special behavior for including them in the decryption process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
@ -75,10 +75,10 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
@ -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 specified 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 specifid 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,10 +209,14 @@ 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:
* https://github.com/casascius/Bitcoin-Address-Utility
* via https: https://casascius.com/btcaddress-alpha.zip
* at github: 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===
@ -272,7 +276,7 @@ Test 2:
Test 1:
*Passphrase: MOLON LABE
*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX
*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX
*Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j
*Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh
*Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8
@ -280,9 +284,9 @@ Test 1:
*Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD
*Lot/Sequence: 263183/1
Test 2:
Test 2:
*Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ
*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
*Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH
*Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf
*Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D

65
bip-0039.mediawiki
View File

@ -2,16 +2,15 @@
BIP: 39
Layer: Applications
Title: Mnemonic code for generating deterministic keys
Authors: Marek Palatinus <slush@satoshilabs.com>
Pavol Rusnak <stick@satoshilabs.com>
Aaron Voisine <voisine@gmail.com>
Sean Bowe <ewillbefull@gmail.com>
Author: Marek Palatinus <slush@satoshilabs.com>
Pavol Rusnak <stick@satoshilabs.com>
Aaron Voisine <voisine@gmail.com>
Sean Bowe <ewillbefull@gmail.com>
Comments-Summary: Unanimously Discourage for implementation
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0039
Status: Deployed
Type: Specification
Assigned: 2013-09-10
License: MIT
Status: Proposed
Type: Standards Track
Created: 2013-09-10
</pre>
==Abstract==
@ -19,22 +18,18 @@
This BIP describes the implementation of a mnemonic code or mnemonic sentence --
a group of easy to remember words -- for the generation of deterministic wallets.
It consists of two parts: generating the mnemonic and converting it into a
It consists of two parts: generating the mnemonic, and converting it into a
binary seed. This seed can be later used to generate deterministic wallets using
BIP-0032 or similar methods.
==Copyright==
This BIP falls under the MIT License.
==Motivation==
A mnemonic code or sentence is superior for human interaction compared to the
handling of raw binary or hexadecimal representations of a wallet seed. The
handling of raw binary or hexidecimal representations of a wallet seed. The
sentence could be written on paper or spoken over the telephone.
This guide is meant to be a way to transport computer-generated randomness with
a human-readable transcription. It's not a way to process user-created
a human readable transcription. It's not a way to process user-created
sentences (also known as brainwallets) into a wallet seed.
==Generating the mnemonic==
@ -44,14 +39,14 @@ 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 <code>ENT / 32</code> bits of its SHA256 hash. This checksum is
taking the first <pre>ENT / 32</pre> 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
use the joined words as a mnemonic sentence.
The following table describes the relation between the initial entropy
length (ENT), the checksum length (CS), and the length of the generated mnemonic
length (ENT), the checksum length (CS) and the length of the generated mnemonic
sentence (MS) in words.
<pre>
@ -72,12 +67,12 @@ MS = (ENT + CS) / 11
An ideal wordlist has the following characteristics:
a) smart selection of words
- the wordlist is created in such a way that it's enough to type the first four
- the wordlist is created in such way that it's enough to type the first four
letters to unambiguously identify the word
b) similar words avoided
- word pairs like "build" and "built", "woman" and "women", or "quick" and "quickly"
not only make remembering the sentence difficult but are also more error
not only make remembering the sentence difficult, but are also more error
prone and more difficult to guess
c) sorted wordlists
@ -102,7 +97,7 @@ This seed can be later used to generate deterministic wallets using BIP-0032 or
similar methods.
The conversion of the mnemonic sentence to a binary seed is completely independent
from generating the sentence. This results in a rather simple code; there are no
from generating the sentence. This results in rather simple code; there are no
constraints on sentence structure and clients are free to implement their own
wordlists or even whole sentence generators, allowing for flexibility in wordlists
for typo detection or other purposes.
@ -118,14 +113,7 @@ will make the desired wallet available.
==Wordlists==
Since the vast majority of BIP39 wallets supports only the English wordlist,
it is '''strongly discouraged''' to use non-English wordlists for generating
the mnemonic sentences.
If you still feel your application really needs to use a localized wordlist,
use one of the following instead of inventing your own.
* [[bip-0039/bip-0039-wordlists.md|Wordlists]]
* [[bip-0039/bip-0039-wordlists.md|Moved to separate document]]
==Test vectors==
@ -143,3 +131,24 @@ 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==
Objective-C:
* https://github.com/nybex/NYMnemonic
Haskell:
* https://github.com/haskoin/haskoin
.NET C# (PCL):
* https://github.com/Thashiznets/BIP39.NET
.NET C# (PCL):
* https://github.com/NicolasDorier/NBitcoin
JavaScript:
* https://github.com/bitpay/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]])
Ruby:
* https://github.com/sreekanthgs/bip_mnemonic

72
bip-0039/bip-0039-wordlists.md
View File

@ -1,59 +1,56 @@
# Wordlists
#Wordlists
* [English](english.txt)
* [Japanese](japanese.txt)
* [Korean](korean.txt)
* [Spanish](spanish.txt)
* [Chinese (Simplified)](chinese_simplified.txt)
* [Chinese (Traditional)](chinese_traditional.txt)
* [French](french.txt)
* [Italian](italian.txt)
* [Czech](czech.txt)
* [Portuguese](portuguese.txt)
## Wordlists (Special Considerations)
##Wordlists (Special Considerations)
### Japanese
###Japanese
1. **Developers implementing phrase generation or checksum verification must separate words using ideographic spaces / accommodate users inputting ideographic spaces.**
(UTF-8 bytes: **0xE38080**; C/C+/Java: **"\u3000"**; Python: **u"\u3000"**)
1. **Developers implementing phrase generation or checksum verification must separate words using ideographic spaces / accommodate users inputting ideographic spaces.**
(UTF-8 bytes: **0xE38080**; C/C+/Java: **"\u3000"**; Python: **u"\u3000"**)
However, code that only accepts Japanese phrases but does not generate or verify them should be fine as is.
This is because when generating the seed, normalization as per the spec will
automatically change the ideographic spaces into normal ASCII spaces, so as long as your code never shows the user an ASCII space
separated phrase or tries to split the phrase input by the user, dealing with ASCII or Ideographic space is the same.
2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the
ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily
2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the
ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily
for two smaller words (This would be a problem with any of the 3 character sets in Japanese)
### Spanish
###Spanish
1. Words can be uniquely determined by typing the first 4 characters (sometimes less).
1. Words can be uniquely determined typing the first 4 characters (sometimes less).
2. Special Spanish characters like 'ñ', 'ü', 'á', etc... are considered equal to 'n', 'u', 'a', etc... in terms of identifying a word. Therefore, there is no need to use a Spanish keyboard to introduce the passphrase, an application with the Spanish wordlist will be able to identify the words after the first 4 chars have been typed even if the chars with accents have been replaced with the equivalent without accents.
3. There are no words in common between the Spanish wordlist and any other language wordlist, therefore it is possible to detect the language with just one word.
### Chinese
###Chinese
1. Chinese text typically does not use any spaces as word separators. For the sake of
uniformity, we propose to use normal ASCII spaces (0x20) to separate words as per standard.
### French
###French
Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch
([The pull request](https://github.com/bitcoin/bips/issues/152))
1. High priority on simple and common French words.
1. High priority on simple and common french words.
2. Only words with 5-8 letters.
3. A word is fully recognizable by typing the first 4 letters (special French characters "é-è" are considered equal to "e", for example "museau" and "musée" can not be together).
3. A word is fully recognizable by typing the first 4 letters (special french characters "é-è" are considered equal to "e", for exemple "museau" and "musée" can not be together).
4. Only infinitive verbs, adjectives and nouns.
5. No pronouns, no adverbs, no prepositions, no conjunctions, no interjections (unless a noun/adjective is also popular than its interjection like "mince;chouette").
6. No numeral adjectives.
7. No words in the plural (except invariable words like "univers", or same spelling as singular like "heureux").
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 only 1 letter of difference.
10. No very similar words with 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".
@ -68,7 +65,7 @@ Credits: @paoloaga @Polve
Words chosen using the following rules:
1. Simple and common Italian words.
1. Simple and common italian words.
2. Length between 4 and 8 characters.
3. First 4 letters must be unique between all words.
4. No accents or special characters.
@ -76,42 +73,11 @@ Words chosen using the following rules:
6. No plural words.
7. No words that remind negative/sad/bad things.
8. If both female/male words are available, choose male version.
9. No words with double vowels (like: lineetta).
9. No words with double vocals (like: lineetta).
10. No words already used in other language mnemonic sets.
11. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must be at least other 3 different letters.
12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must not be the same sequence of 3 or more letters.
12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there not must be the same sequence of 3 or more letters.
Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good.
Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good.
All the words have been manually selected and automatically checked against the rules.
### Czech
Credits: @zizelevak (Jan Lansky zizelevak@gmail.com)
Words chosen using the following rules:
1. Words are 4-8 letters long.
2. Words can be uniquely determined by typing the first 4 letters.
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 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
Credits: @alegotardo @bitmover-studio @brenorb @kuthullu @ninjastic @sabotag3x @Trimegistus
1. Words can be uniquely determined by typing the first 4 characters.
2. No accents or special characters.
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 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 one of negative/sad/bad things.
11. No very similar words with only 1 letter of difference.

2048
bip-0039/czech.txt
View File

File diff suppressed because it is too large Load Diff

4
bip-0039/french.txt
View File

@ -1,4 +1,4 @@
abaisser
abaisser
abandon
abdiquer
abeille
@ -2045,4 +2045,4 @@ yacht
zèbre
zénith
zeste
zoologie
zoologie

2048
bip-0039/korean.txt
View File

File diff suppressed because it is too large Load Diff

2048
bip-0039/portuguese.txt
View File

File diff suppressed because it is too large Load Diff

14
bip-0042.mediawiki
View File

@ -2,20 +2,20 @@
BIP: 42
Layer: Consensus (soft fork)
Title: A finite monetary supply for Bitcoin
Authors: Pieter Wuille <pieter.wuille@gmail.com>
Author: Pieter Wuille <pieter.wuille@gmail.com>
Comments-Summary: Unanimously Recommended for implementation
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0042
Status: Deployed
Type: Specification
Assigned: 2014-04-01
Status: Draft
Type: Standards Track
Created: 2014-04-01
License: PD
</pre>
==Abstract==
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 mibillennium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years.
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.
@ -42,7 +42,7 @@ Note that several other programming languages do not exhibit this behaviour, mak
===Floating-point approximation===
An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript.
An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript.
===Truncation===

16
bip-0043.mediawiki
View File

@ -2,11 +2,13 @@
BIP: 43
Layer: Applications
Title: Purpose Field for Deterministic Wallets
Authors: Marek Palatinus <slush@satoshilabs.com>
Pavol Rusnak <stick@satoshilabs.com>
Status: Deployed
Type: Specification
Assigned: 2014-04-24
Author: Marek Palatinus <slush@satoshilabs.com>
Pavol Rusnak <stick@satoshilabs.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0043
Status: Draft
Type: Informational
Created: 2014-04-24
</pre>
==Abstract==
@ -18,7 +20,7 @@ based on algorithm described in BIP-0032 (BIP32 from now on).
Although Hierarchical Deterministic Wallet structure as described by BIP32
is an important step in user experience and security of the cryptocoin wallets,
the BIP32 specification offers implementers too many degrees of freedom.
the BIP32 specification offers implementors too many degrees of freedom.
Multiple implementations may claim they are BIP32 compatible, but in fact
they can produce wallets with different logical structures making them
non-interoperable. This situation unfortunately renders "BIP32 compatible"
@ -40,8 +42,6 @@ We encourage different schemes to apply for assigning a separate BIP number
and use the same number for purpose field, so addresses won't be generated
from overlapping BIP32 spaces.
Purpose codes from 10001 to 19999 are reserved for [[https://github.com/satoshilabs/slips|SLIPs]].
Example: Scheme described in BIP44 should use 44' (or 0x8000002C) as purpose.
Note that m / 0' / * is already taken by BIP32 (default account), which

19
bip-0044.mediawiki
View File

@ -2,14 +2,13 @@
BIP: 44
Layer: Applications
Title: Multi-Account Hierarchy for Deterministic Wallets
Authors: Marek Palatinus <slush@satoshilabs.com>
Pavol Rusnak <stick@satoshilabs.com>
Author: Marek Palatinus <slush@satoshilabs.com>
Pavol Rusnak <stick@satoshilabs.com>
Comments-Summary: Mixed review (one person)
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0044
Status: Deployed
Type: Specification
Assigned: 2014-04-24
Requires: 32, 43
Status: Proposed
Type: Standards Track
Created: 2014-04-24
</pre>
==Abstract==
@ -264,6 +263,14 @@ is required and a pull request to the above file should be created.
|m / 44' / 1' / 1' / 1 / 1
|}
==Compatible wallets==
* [[https://mytrezor.com|myTREZOR web wallet]] ([[https://github.com/trezor/webwallet|source]])
* [[https://play.google.com/store/apps/details?id=com.bonsai.wallet32|Wallet32 @ Android]] ([[https://github.com/ksedgwic/Wallet32|source]])
* [[https://play.google.com/store/apps/details?id=com.mycelium.wallet|Mycelium Bitcoin Wallet (Android)]] ([[https://github.com/mycelium-com/wallet|source]])
* [[https://copay.io/|Copay]] ([[https://github.com/bitpay/copay|source]])
* [[https://maza.club/encompass|Encompass]] ([[https://github.com/mazaclub/encompass|source]])
* [[https://www.coinvault.io/|CoinVault]] ([[https://github.com/CoinVault/dotblock|source]])
==Reference==
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]

56
bip-0045.mediawiki
View File

@ -2,19 +2,21 @@
BIP: 45
Layer: Applications
Title: Structure for Deterministic P2SH Multisignature Wallets
Authors: Manuel Araoz <manu@bitpay.com>
Ryan X. Charles <ryan@bitpay.com>
Matias Alejo Garcia <matias@bitpay.com>
Status: Complete
Type: Specification
Assigned: 2014-04-25
Author: Manuel Araoz <manu@bitpay.com>
Ryan X. Charles <ryan@bitpay.com>
Matias Alejo Garcia <matias@bitpay.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0045
Status: Proposed
Type: Standards Track
Created: 2014-04-25
</pre>
==Abstract==
This BIP defines a structure for hierarchical deterministic P2SH multi-party
multi-signature wallets (HDPM wallets from now on) based on the algorithm
described in BIP-0032 (BIP32 from now on) and purpose scheme described in
described in BIP-0032 (BIP32 from now on) and purpose scheme described in
BIP-0043 (BIP43 from now on).
This BIP is a particular application of BIP43.
@ -60,8 +62,8 @@ Hardened derivation is used at this level.
The index of the party creating a P2SH multisig address. The indices can
be determined independently by lexicographically sorting the purpose public
keys of each cosigner. Each cosigner creates addresses on its own branch,
even though they have independent extended master public key, as explained
keys of each cosigner. Each cosigner creates addresses on it's own branch,
even though they have independent extended master public key, as explained
in the "Address generation" section.
Note that the master public key is not shared amongst the cosigners. Only the
@ -77,12 +79,12 @@ purpose public keys:
03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13
</pre>
it should use <code>m / 45 ' / 0 / *</code> for
<code>039863fb5f07b667d9b1ca68773c6e6cdbcac0088ffba9af46f6f6acd153d44463</code>,
<code>m / 45 ' / 1 / *</code> for
<code>03a473275a750a20b7b71ebeadfec83130c014da4b53f1c4743fcf342af6589a38</code>,
and <code>m / 45 ' / 2 / *</code> for
<code>03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13</code>,
it should use `m / 45 ' / 0 / *` for
`039863fb5f07b667d9b1ca68773c6e6cdbcac0088ffba9af46f6f6acd153d44463`,
`m / 45 ' / 1 / *` for
`03a473275a750a20b7b71ebeadfec83130c014da4b53f1c4743fcf342af6589a38`,
and `m / 45 ' / 2 / *` for
`03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13`,
as dictated by their lexicographical order.
@ -100,7 +102,7 @@ chain is used for addresses which are not meant to be visible outside of the
wallet and is used for return transaction change.
For example, if cosigner 2 wants to generate a change address, he would use
<code>m / 45 ' / 2 / 1 / *</code>, and <code>m / 45 ' / 2 / 0 / *</code> for a receive
`m / 45 ' / 2 / 1 / *`, and `m / 45 ' / 2 / 0 / *` for a receive
address.
Non-hardened derivation is used at this level.
@ -116,7 +118,7 @@ Non-hardened derivation is used at this level.
Each party generates their own extended master keypair and shares the
extended purpose' public key with the others, which is stored encrypted.
Each party can generate any of the other's derived public keys, but only
his own private keys.
his own private keys.
===Address Generation Procedure===
When generating an address, each party can independently generate the N needed
@ -135,18 +137,18 @@ others using the next index, and calculate the needed script for the address.
Example: Cosigner #2 wants to receive a payment to the shared wallet. His last
used index on his own branch is 4. Then, the path for the next receive
address is <code>m/45'/2/0/5</code>. He uses this same path in all of the cosigners
address is `m/45'/2/0/5`. He uses this same path in all of the cosigners
trees to generate a public key for each one, and from that he gets the new
p2sh address.
====Change address case====
Again, each cosigner generates addresses only on his own branch. One of the
n cosigners wants to create an outgoing payment, for which he'll need a change
address. He generates a new address using the same procedure as above, but
using a separate index to track the used change addresses.
using a separate index to track the used change addresses.
Example: Cosigner #5 wants to send a payment from the shared wallet, for which
he'll need a change address. His last used change index on his own branch is
11. Then, the path for the next change address is <code>m/45'/5/1/12</code>. He uses
11. Then, the path for the next change address is `m/45'/5/1/12`. He uses
this same path in all of the cosigners trees to generate a public key for each
one, and from that he gets the new p2sh address.
@ -161,7 +163,7 @@ that specific address (using the same path that generated the public key in
that address, but deriving the private key instead), and sign it. Once the
proposal reaches m signatures, any cosigner can broadcast it to the network,
becoming final. The specifics of how this proposal is structured, and the
protocol to accept or reject it, belong to another BIP, in my opinion.
protocol to accept or reject it, belong to another BIP, in my opinion.
===Address discovery===
@ -169,8 +171,8 @@ When the master seed is imported from an external source the software should
start to discover the addresses in the following manner:
# for each cosigner:
# derive the cosigner's node (<code>m / 45' / cosigner_index</code>)
# for both the external and internal chains on this node (<code>m / 45' / cosigner_index / 0</code> and <code>m / 45' / cosigner_index / 1</code>):
# derive the cosigner's node (`m / 45' / cosigner_index`)
# for both the external and internal chains on this node (`m / 45' / cosigner_index / 0` and `m / 45' / cosigner_index / 1`):
# scan addresses of the chain; respect the gap limit described below
Please note that the algorithm uses the transaction history, not address
@ -180,7 +182,7 @@ even if the earlier ones don't have transactions
===Address gap limit===
Address gap limit is currently set to 20. If the software hits 20 unused
Address gap limit is currently set to 20. If the software hits 20 unused
addresses (no transactions associated with that address) in a row, it expects
there are no used addresses beyond this point and stops searching the address chain.
@ -190,13 +192,13 @@ an external chain by generating a new address.
===Rationale===
This structure provides a general way of doing HDPM wallets between m-of-n
This stucture provides a general way of doing HDPM wallets between m-of-n
parties. Here are some explanations about the design decisions made.
The reason for using separate branches for each cosigner is we don't want
two of them generating the same address and receiving simultaneous payments
to it. The ideal case is that each address receives at most one payment,
requested by the corresponding cosigner.
requested by the corresponding cosigner.
==Examples==
@ -242,7 +244,7 @@ requested by the corresponding cosigner.
| m / 45' / 2 / 1 / 9
|}
==Compatible wallets==
==Compatible walets==
* [[https://copay.io|Copay wallet]] ([[https://github.com/bitpay/copay|source]])

192
bip-0046.mediawiki
View File

@ -1,192 +0,0 @@
<pre>
BIP: 46
Layer: Applications
Title: Address Scheme for Timelocked Fidelity Bonds
Authors: Chris Belcher <belcher@riseup.net>
Thebora Kompanioni <theborakompanioni+bip46@gmail.com>
Status: Draft
Type: Specification
Assigned: 2022-04-01
License: CC0-1.0
Discussion: 2022-05-01: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020389.html
</pre>
== Abstract ==
This BIP defines the derivation scheme for HD wallets which create timelocked addresses used for creating fidelity bonds. It also gives advice to wallet developers on how to use fidelity bonds to sign over messages, such as certificates, which are needed when using fidelity bonds that are stored offline.
== Copyright ==
This document is licensed under the Creative Commons CC0 1.0 Universal license.
== Motivation ==
Fidelity bonds are used to resist sybil attacks in certain decentralized anonymous protocols. They are created by locking up bitcoins using the `OP_CHECKLOCKTIMEVERIFY` opcode.
Having a common derivation scheme allows users of wallet software to have a backup of their fidelity bonds by storing only the HD seed and a reference to this BIP. Importantly the user does not need to backup any timelock values.
We largely use the same approach used in BIPs 49, 84 and 86 for ease of implementation.
This allows keeping the private keys of fidelity bonds in cold storage, which increases the sybil resistance of a system without hot wallet risk.
== Backwards Compatibility ==
This BIP is not backwards compatible by design as described in the Considerations section of [[bip-0049.mediawiki|BIP 49]]. An incompatible wallet will not discover fidelity bonds at all and the user will notice that something is wrong.
== Background ==
=== Fidelity bonds ===
A fidelity bond is a mechanism where bitcoin value is deliberately sacrificed to make a cryptographic identity expensive to obtain. A way to create a fidelity bond is to lock up bitcoins by sending them to a timelocked address. The valuable thing being sacrificed is the time-value-of-money.
The sacrifice must be done in a way that can be proven to a third party. This proof can be made by showing the UTXO outpoint, the address redeemscript and a signature which signs a message using the private key corresponding to the public key in the redeemscript.
The sacrificed value is an objective measurement that can't be faked and which can be verified by anybody (just like, for example PoW mining). Sybil attacks can be made very expensive by forcing a hypothetical sybil attacker to lock up many bitcoins for a long time. JoinMarket implements fidelity bonds for protection from sybil attackers. At the time of writing over 600 BTC in total have been locked up with some for many years. Their UTXOs and signatures have been advertised to the world as proof. We can calculate that for a sybil attacker to succeed in unmixing all the CoinJoins, they would have to lock up over 100k BTC for several years.
=== Fidelity bonds in cold storage ===
To allow for holding fidelity bonds in cold storage, there is an intermediate keypair called the certificate.
UTXO key ---signs---> certificate ---signs---> endpoint
Where the endpoint might be a IRC nickname or Tor onion hostname. The certificate keypair can be kept online and used to prove ownership of the fidelity bond. Even if the hot wallet private keys are stolen, the coins in the timelocked address will still be safe, although the thief will be able to impersonate the fidelity bond until the expiry.
== Rationale ==
It is useful for the user to avoid having to keep a record of the timelocks in the time-locked addresses. So only a limited small set of timelocks are defined by this BIP. This way the user must only store their seed phrase, and knowledge that they have coins stored using this BIP standard. The user doesn't need to remember or store any dates.
This standard is already implemented and deployed in JoinMarket. As most changes would require a protocol change of a live system, there is limited scope for changing this standard in review. This BIP is more about documenting something which already exists, warts and all.
== Specifications ==
This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] master private key. It also defines the format of the certificate that can be signed by the deterministic address key.
=== Public key derivation ===
To derive a public key from the root account, this BIP uses a similar account-structure as defined in BIP [[bip-0084.mediawiki|44]] but with <tt>change</tt> set to <tt>2</tt>.
<pre>
m / 84' / 0' / 0' / 2 / index
</pre>
A key derived with this derivation path pattern will be referred to as <tt>derived_key</tt> further
in this document.
For <tt>index</tt>, addresses are numbered from 0 in a sequentially increasing manner with a fixed upper bound: The index only goes up to <tt>959</tt> inclusive. Only 960 addresses can be derived for a given BIP32 master key. Furthermore there is no concept of a gap limit, instead wallets must always generate all 960 addresses and check for all of them if they have a balance and history.
=== Timelock derivation ===
The timelock used in the time-locked address is derived from the <tt>index</tt>. The timelock is a unix time. It is always at the start of the first second at the beginning of the month (see [[#test-vectors|Test vectors]]). The <tt>index</tt> counts upwards the months from January 2020, ending in December 2099. At 12 months per year for 80 years this totals 960 timelocks. Note that care must be taken with the year 2038 problem on 32-bit systems.
<pre>
year = 2020 + index // 12
month = 1 + index % 12
</pre>
=== Address derivation ===
To derive the address from the above calculated public key and timelock, we create a <tt>witness script</tt> which locks the funds until the <tt>timelock</tt>, and then checks the signature of the <tt>derived_key</tt>. The <tt>witness script</tt> is hashed with SHA256 to produce a 32-byte hash value that forms the <tt>witness program</tt> in the output script of the P2WSH address.
witnessScript: <timelock> OP_CHECKLOCKTIMEVERIFY OP_DROP <derived_key> OP_CHECKSIG
witness: <signature> <witnessScript>
scriptSig: (empty)
scriptPubKey: 0 <32-byte-hash>
(0x0020{32-byte-hash})
=== Message signing ===
In order to support signing of certificates, implementers should support signing ASCII messages.
The certificate message is defined as `"fidelity-bond-cert" || "|" || cert_pubkey || "|" || cert_expiry`.
The certificate expiry `cert_expiry` is the number of the 2016-block period after which the certificate is no longer valid. For example, if `cert_expiry` is 330 then the certificate will become invalid after block height 665280 (:=330x2016). The purpose of the expiry parameter is so that in case the certificate keypair is compromised, the attacker can only impersonate the fidelity bond for a limited amount of time.
A certificate message can be created by another application external to this standard. It is then prepended with the string `0x18 || "Bitcoin Signed Message:\n"` and a byte denoting the length of the certificate message. The whole thing is then signed with the private key of the <tt>derived_key</tt>. This part is identical to the "Sign Message" function which many wallets already implement.
Almost all wallets implementing this standard can use their already-existing "Sign Message" function to sign the certificate message. As the certificate message itself is always an ASCII string, the wallet may not need to specially implement this section at all but just rely on users copypasting their certificate message into the already-existing "Sign Message" user interface. This works as long as the wallet knows how to use the private key of the timelocked address for signing messages.
It is most important for wallet implementations of this standard to support creating the certificate signature. Verifying the certificate signature is less important.
== Test vectors ==
<pre>
mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
rootpriv = xprv9s21ZrQH143K3GJpoapnV8SFfukcVBSfeCficPSGfubmSFDxo1kuHnLisriDvSnRRuL2Qrg5ggqHKNVpxR86QEC8w35uxmGoggxtQTPvfUu
rootpub = xpub661MyMwAqRbcFkPHucMnrGNzDwb6teAX1RbKQmqtEF8kK3Z7LZ59qafCjB9eCRLiTVG3uxBxgKvRgbubRhqSKXnGGb1aoaqLrpMBDrVxga8
// First timelocked address = m/84'/0'/0'/2/0
derived private_key = L2tQBEdhC48YLeEWNg3e4msk94iKfyVa9hdfzRwUERabZ53TfH3d
derived public_key = 02a1b09f93073c63f205086440898141c0c3c6d24f69a18db608224bcf143fa011
unix locktime = 1577836800
string locktime = 2020-01-01 00:00:00
redeemscript = 0400e10b5eb1752102a1b09f93073c63f205086440898141c0c3c6d24f69a18db608224bcf143fa011ac
scriptPubKey = 0020bdee9515359fc9df912318523b4cd22f1c0b5410232dc943be73f9f4f07e39ad
address = bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84
// Test certificate using the first timelocked address
// Note that as signatures contains a random nonce, it might not be exactly the same when your code generates it
// p2pkh address is the p2pkh address corresponding to the derived public key, it can be used to verify the message
// signature in any wallet that supports Verify Message.
// As mentioned before, it is more important for implementers of this standard to support signing such messages, not verifying them
message = fidelity-bond-cert|020000000000000000000000000000000000000000000000000000000000000001|375
address = bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84
p2pkh address = 16vmiGpY1rEaYnpGgtG7FZgr2uFCpeDgV6
signature = H2b/90XcKnIU/D1nSCPhk8OcxrHebMCr4Ok2d2yDnbKDTSThNsNKA64CT4v2kt+xA1JmGRG/dMnUUH1kKqCVSHo=
// 2nd timelocked address = m/84'/0'/0'/2/1
derived private_key = KxctaFBzetyc9KXeUr6jxESCZiCEXRuwnQMw7h7hroP6MqnWN6Pf
derived public_key = 02599f6db8b33265a44200fef0be79c927398ed0b46c6a82fa6ddaa5be2714002d
unix locktime = 1580515200
string locktime = 2020-02-01 00:00:00
redeemscript = 0480bf345eb1752102599f6db8b33265a44200fef0be79c927398ed0b46c6a82fa6ddaa5be2714002dac
scriptPubKey = 0020b8f898643991608524ed04e0c6779f632a57f1ffa3a3a306cd81432c5533e9ae
address = bc1qhrufsepej9sg2f8dqnsvvaulvv490u0l5w36xpkds9pjc4fnaxhq7pcm4h
// timelocked address after the year 2038 = m/84'/0'/0'/2/240
derived private_key = L3SYqae23ZoDDcyEA8rRBK83h1MDqxaDG57imMc9FUx1J8o9anQe
derived public_key = 03ec8067418537bbb52d5d3e64e2868e67635c33cfeadeb9a46199f89ebfaab226
unix locktime = 2208988800
string locktime = 2040-01-01 00:00:00
redeemscript = 05807eaa8300b1752103ec8067418537bbb52d5d3e64e2868e67635c33cfeadeb9a46199f89ebfaab226ac
scriptPubKey = 0020e7de0ad2720ae1d6cc9b6ad91af57eb74646762cf594c91c18f6d5e7a873635a
address = bc1qul0q45njptsadnymdtv34at7karyva3v7k2vj8qc7m2702rnvddq0z20u5
// last timelocked address = m/84'/0'/0'/2/959
derived private_key = L5Z9DDMnj5RZMyyPiQLCvN48Xt7GGmev6cjvJXD8uz5EqiY8trNJ
derived public_key = 0308c5751121b1ae5c973cdc7071312f6fc10ab864262f0cbd8134f056166e50f3
unix locktime = 4099766400
string locktime = 2099-12-01 00:00:00
redeemscript = 0580785df400b175210308c5751121b1ae5c973cdc7071312f6fc10ab864262f0cbd8134f056166e50f3ac
scriptPubKey = 0020803268e042008737cf439748cbb5a4449e311da9aa64ae3ac56d84d059654f85
address = bc1qsqex3czzqzrn0n6rjayvhddygj0rz8df4fj2uwk9dkzdqkt9f7zs5c493u
// Test certificate and endpoint signing using the first timelocked address = m/84'/0'/0'/2/0 (see above)
bond private_key = L2tQBEdhC48YLeEWNg3e4msk94iKfyVa9hdfzRwUERabZ53TfH3d
bond p2pkh address = 16vmiGpY1rEaYnpGgtG7FZgr2uFCpeDgV6
certificate private_key = KyZpNDKnfs94vbrwhJneDi77V6jF64PWPF8x5cdJb8ifgg2DUc9d
certificate public_key = 0330d54fd0dd420a6e5f8d3624f5f3482cae350f79d5f0753bf5beef9c2d91af3c
certificate p2pkh address = 1JaUQDVNRdhfNsVncGkXedaPSM5Gc54Hso
certificate message = fidelity-bond-cert|0330d54fd0dd420a6e5f8d3624f5f3482cae350f79d5f0753bf5beef9c2d91af3c|375
certificate signature = INOP3cB9UW7F1e1Aglj8rI9QhnyxmgWDEPt+nOMvl7hJJne7rH/KCNDYvLiqNuB9qWaWUojutjRsgPJrvyDQ+0Y=
// example endpoint signing two IRC nicknames (used in JoinMarket)
endpoint message = J54LS6YyJPoseqFS|J55VZ6U6ZyFDNeuv
endpoint signature = H18WE4MugDNoWZIf9jU0njhQptdUyBDUf7lToG9bpMKmeJK0lOoABaDs5bKnohSuZ0e9gnSco5OL9lXdKU7gP5E=
</pre>
Code generating these test vectors can be found here: https://github.com/chris-belcher/timelocked-addresses-fidelity-bond-bip-testvectors
== Reference ==
* [[https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af/|Design for improving JoinMarket's resistance to sybil attacks using fidelity bonds]]
* [[https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/fidelity-bonds.md|JoinMarket fidelity bonds doc page]]
* [[bip-0065.mediawiki|BIP65 - OP_CHECKLOCKTIMEVERIFY]]
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
* [[bip-0049.mediawiki|BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts]]
* [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based accounts]]
* [[bip-0086.mediawiki|BIP86 - Key Derivation for Single Key P2TR Outputs]]

34
bip-0047.mediawiki
View File

@ -1,26 +1,20 @@
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
<pre>
BIP: 47
Layer: Applications
Title: Reusable Payment Codes for Hierarchical Deterministic Wallets
Authors: Justus Ranvier <justus@openbitcoinprivacyproject.org>
Author: Justus Ranvier <justus@openbitcoinprivacyproject.org>
Comments-Summary: Unanimously Discourage for implementation
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0047
Status: Deployed
Status: Draft
Type: Informational
Assigned: 2015-04-24
Created: 2015-04-24
</pre>
==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.
@ -156,7 +150,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 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 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
@ -164,7 +158,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: <pre>a</pre>
## Alice selects the public key associated with Bob's notification address: <pre>B, where B = bG</pre>
## Alice calculates a secret point: <pre>S = aB</pre>
## Alice calculates a 64 byte blinding factor: <pre>s = HMAC-SHA512(o, x)</pre>
## Alice calculates a 64 byte blinding factor: <pre>s = HMAC-SHA512(x, o)</pre>
### "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.
@ -180,7 +174,7 @@ Note: this procedure is used if Bob uses a version 1 payment code (regardless of
## Bob selects the designated pubkey: <pre>A, where A = aG</pre>
## Bob selects the private key associated with his notification address: <pre>b</pre>
## Bob calculates a secret point: <pre>S = bA</pre>
## Bob calculates the blinding factor: <pre>s = HMAC-SHA512(x, o)</pre>
## Bob calculates the binding factor: <pre>s = HMAC-SHA512(x, o)</pre>
### "x" is the x value of the secret point
### "o" is the outpoint being spent by the designated input.
## Bob interprets the 80 byte payload as a payment code, except:
@ -224,7 +218,7 @@ The following actions are recommended to reduce this risk:
====Sending====
# Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH as follows:
# Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH follows:
## Alice selects the 0th private key derived from her payment code: <pre>a</pre>
## Alice selects the next unused public key derived from Bob's payment code, starting from zero: <pre>B, where B = bG</pre>
### The "next unused" public key is based on an index specific to the Alice-Bob context, not global to either Alice or Bob
@ -235,7 +229,7 @@ The following actions are recommended to reduce this risk:
<img src="bip-0047/reusable_payment_codes-04.png" />
<img src="bip-0047/reusable_payment_codes-05.png" />
# 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 0<sup>th</sup> 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 n shared secrets with Alice, using the 0<sup>th</sup> 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 the ephemeral deposit addresses using the same procedure as Alice: <pre>B' = B + sG</pre>
## Bob calculate the private key for each ephemeral address as: <pre>b' = b + s</pre>
<img src="bip-0047/reusable_payment_codes-02.png" />
@ -275,7 +269,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-queryable blockchain explorer.
The required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queriable 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.
@ -318,7 +312,7 @@ A recipient specifies their preference for alternate notification by setting the
===Bitmessage Notification===
A recipient which prefers to receive notifications via Bitmessage indicates this preference by:
A recipient prefers to receive notifications via Bitmessage indiates this preference by:
* Setting bit 0 of the features byte to 1
* Setting byte 67 of the serialized payment code to the desired Bitmessage address version
@ -350,12 +344,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 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 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 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 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:

253
bip-0048.mediawiki
View File

@ -1,253 +0,0 @@
<pre>
BIP: 48
Layer: Applications
Title: Multi-Script Hierarchy for Multi-Sig Wallets
Authors: Fontaine <dentondevelopment@protonmail.com>
Status: Deployed
Type: Specification
Assigned: 2020-12-16
License: MIT
</pre>
==Abstract==
This BIP defines a logical hierarchy for deterministic multi-sig wallets based on an algorithm
described in BIP-0067 (BIP67 from now on), BIP-0032 (BIP32 from now on), purpose scheme described in
BIP-0043 (BIP43 from now on), and multi-account hierarchy described in
BIP-0044 (BIP44 from now on).
This BIP is a particular application of BIP43.
==Copyright==
This BIP falls under the MIT License.
==Motivation==
The motivation of this BIP is to define the existing industry wide practice of utilizing m/48'
derivation paths in hierarchical deterministic multi-sig wallets so that other developers may
benefit from a standard. This BIP allows for future script types to easily be appended to the
specification so that a new BIP is not required for every future script type.
The hierarchy proposed in this paper is quite comprehensive. It allows the handling of
multiple accounts, external and internal chains per account, multiple script types and
millions of addresses per chain.
This paper was inspired from BIP44.
==Backwards compatibility==
Currently a number of wallets utilize the ‎<code>m/48'</code> derivation scheme for HD multi-sig accounts.
This BIP is intended to maintain the *existing* real world use of the ‎<code>m/48'</code> derivation.
No breaking changes are made so as to avoid "loss of funds" to existing users.
Wallets which currently support the ‎<code>m/48'</code> derivation will not need to make any changes
to comply with this BIP.
==Specification==
===Key sorting===
Any wallet that supports BIP48 inherently supports deterministic key sorting as per BIP67 so that all possible
multi-signature addresses/scripts are derived from deterministically sorted public keys.
===Path levels===
We define the following 6 levels in BIP32 path:
<pre>
m / purpose' / coin_type' / account' / script_type' / change / address_index
</pre>
<code>h</code> or <code>'</code> in the path indicates that BIP32 hardened derivation is used.
Each level has a special meaning, described in the chapters below.
===Purpose===
Purpose is a constant set to 48' following the BIP43 recommendation.
It indicates that the subtree of this node is used according to this specification.
Hardened derivation is used at this level.
===Coin type===
One master node (seed) can be used for multiple Bitcoin networks.
Sharing the same space for various networks has some disadvantages.
Avoiding reusing addresses across networks and improving privacy issues.
Coin type <code>0</code> for mainnet and <code>1</code> for testnet.
Hardened derivation is used at this level.
===Account===
This level splits the key space into independent user identities, following the BIP44 pattern,
so the wallet never mixes the coins across different accounts.
Users can use these accounts to organize the funds in the same
fashion as bank accounts; for donation purposes (where all
addresses are considered public), for saving purposes,
for common expenses etc.
Accounts are numbered from index 0 in sequentially increasing manner.
This number is used as child index in BIP32 derivation.
Hardened derivation is used at this level.
===Script===
This level splits the key space into two separate <code>script_type</code>(s). To provide
forward compatibility for future script types this specification can be easily extended.
Currently the only script types covered by this BIP are Native Segwit (p2wsh) and
Nested Segwit (p2sh-p2wsh).
The following path represents Nested Segwit (p2sh-p2wsh) mainnet, account 0:
<code>1'</code>: Nested Segwit (p2sh-p2wsh) <code>m/48'/0'/0'/1'</code></br>
The following path represents Native Segwit (p2wsh) mainnet, account 0:
<code>2'</code>: Native Segwit (p2wsh) <code>m/48'/0'/0'/2'</code></br>
The recommended default for wallets is pay to witness script hash <code>m/48'/0'/0'/2'</code>.
===Change===
Constant 0 is used for external chain and constant 1 for internal chain (also
known as change addresses). External chain is used for addresses that are meant
to be visible outside of the wallet (e.g. for receiving payments). Internal
chain is used for addresses which are not meant to be visible outside of the
wallet and is used for return transaction change.
Public derivation is used at this level.
===Index===
Addresses are numbered from index 0 in sequentially increasing manner.
This number is used as child index in BIP32 derivation.
Public derivation is used at this level.
==Examples==
{|
|network
|account
|script
|chain
|address
|path
|-
|mainnet
|first
|p2sh-p2wsh
|external
|first
|m / 48' / 0' / 0' / 1' / 0 / 0
|-
|mainnet
|first
|p2wsh
|external
|first
|m / 48' / 0' / 0' / 2' / 0 / 0
|-
|mainnet
|first
|p2wsh
|external
|second
|m / 48' / 0' / 0' / 2' / 0 / 1
|-
|mainnet
|first
|p2wsh
|change
|first
|m / 48' / 0' / 0' / 2' / 1 / 0
|-
|mainnet
|first
|p2wsh
|change
|second
|m / 48' / 0' / 0' / 2' / 1 / 1
|-
|mainnet
|second
|p2wsh
|external
|first
|m / 48' / 0' / 1' / 2' / 0 / 0
|-
|mainnet
|second
|p2wsh
|external
|second
|m / 48' / 0' / 1' / 2' / 0 / 1
|-
|testnet
|first
|p2sh-p2wsh
|external
|first
|m / 48' / 1' / 0' / 1' / 0 / 0
|-
|testnet
|first
|p2wsh
|external
|second
|m / 48' / 1' / 0' / 2' / 0 / 1
|-
|testnet
|first
|p2wsh
|change
|first
|m / 48' / 1' / 0' / 2' / 1 / 0
|-
|testnet
|first
|p2wsh
|change
|second
|m / 48' / 1' / 0' / 2' / 1 / 1
|-
|testnet
|second
|p2wsh
|external
|first
|m / 48' / 1' / 1' / 2' / 0 / 0
|-
|testnet
|second
|p2wsh
|external
|second
|m / 48' / 1' / 1' / 2' / 0 / 1
|-
|testnet
|second
|p2wsh
|change
|first
|m / 48' / 1' / 1' / 2' / 1 / 0
|-
|testnet
|second
|p2wsh
|change
|second
|m / 48' / 1' / 1' / 2' / 1 / 1
|}
==Reference==
* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]

37
bip-0049.mediawiki
View File

@ -2,12 +2,12 @@
BIP: 49
Layer: Applications
Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts
Authors: Daniel Weigl <DanielWeigl@gmx.at>
Author: Daniel Weigl <Daniel.Weigl@mycelium.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0049
Status: Deployed
Type: Specification
Assigned: 2016-05-19
Status: Draft
Type: Informational
Created: 2016-05-19
License: PD
</pre>
@ -20,19 +20,19 @@ This BIP defines the derivation scheme for HD wallets using the P2WPKH-nested-in
With the usage of P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh|BIP 141]]) transactions it is necessary to have a common derivation scheme.
It allows the user to use different HD wallets with the same masterseed and/or a single account seamlessly.
Thus the user needs to create dedicated segregated witness accounts, which ensures that only wallets compatible with this BIP
will detect the accounts and handle them appropriately.
Thus the user needs to create a dedicated segregate witness accounts, which ensures that only wallets compatible with this BIP
will detect the account and handle them appropriately.
===Considerations===
Two generally different approaches are possible for current BIP44 capable wallets:
1) Allow the user to use the same account(s) that they already use, but add segregated witness encoded addresses to it.
1) Allow the user to use the same account(s) that they already uses, but add segregated witness encoded addresses to it
1.1) Use the same public keys as defined in BIP44, but in addition to the normal P2PKH address also derive the P2SH address from it.
1.2) Use the same account root, but branch off and derive different external and internal chain roots to derive dedicated public keys for the segregated witness addresses.
2) Create dedicated accounts used only for segregated witness addresses.
2) Create dedicated accounts only used for segregated witness addresses.
The solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP49-compatible wallet masterseed into/in a non-BIP49-compatible wallet, the account might show up but also it might miss some UTXOs.
@ -53,7 +53,7 @@ serialization method.
m / purpose' / coin_type' / account' / change / address_index
</pre>
For the `purpose`-path level it uses `49'`. The rest of the levels are used as defined in BIP44.
For the `purpose`-path level it uses `49'`. The rest of the levels are used as defined in BIP44
===Address derivation===
@ -66,36 +66,27 @@ To derive the P2SH address from the above calculated public key, we use the enca
scriptPubKey: HASH160 <20-byte-script-hash> EQUAL
(0xA914{20-byte-script-hash}87)
===Extended Key Version===
When serializing extended keys, this scheme uses alternate version bytes. Extended public keys use <code>0x049d7cb2</code> to produce a "ypub" prefix, and private keys use <code>0x049d7878</code> to produce a "yprv" prefix. Testnet uses <code>0x044a5262</code> "upub" and <code>0x044a4e28</code> "uprv."
Additional registered version bytes are listed in [[https://github.com/satoshilabs/slips/blob/master/slip-0132.md|SLIP-0132]].
==Backwards Compatibility==
This BIP is not backwards compatible by design as described under [[#considerations|considerations]]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong.
This BIP is not backwards compatible by design as described under [#considerations]. A not compatible wallet will not discover accounts at all and the user will notice that something is wrong.
==Test vectors==
<pre>
masterseedWords = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
masterseed = uprv8tXDerPXZ1QsVNjUJWTurs9kA1KGfKUAts74GCkcXtU8GwnH33GDRbNJpEqTvipfCyycARtQJhmdfWf8oKt41X9LL1zeD2pLsWmxEk3VAwd (testnet)
masterseed = tprv8ZgxMBicQKsPe5YMU9gHen4Ez3ApihUfykaqUorj9t6FDqy3nP6eoXiAo2ssvpAjoLroQxHqr3R5nE3a5dU3DHTjTgJDd7zrbniJr6nrCzd (testnet)
// Account 0, root = m/49'/1'/0'
account0Xpriv = uprv91G7gZkzehuMVxDJTYE6tLivdF8e4rvzSu1LFfKw3b2Qx1Aj8vpoFnHdfUZ3hmi9jsvPifmZ24RTN2KhwB8BfMLTVqaBReibyaFFcTP1s9n (testnet)
account0Xpub = upub5EFU65HtV5TeiSHmZZm7FUffBGy8UKeqp7vw43jYbvZPpoVsgU93oac7Wk3u6moKegAEWtGNF8DehrnHtv21XXEMYRUocHqguyjknFHYfgY (testnet)
account0Xpriv = tprv8gRrNu65W2Msef2BdBSUgFdRTGzC8EwVXnV7UGS3faeXtuMVtGfEdidVeGbThs4ELEoayCAzZQ4uUji9DUiAs7erdVskqju7hrBcDvDsdbY (testnet)
// Account 0, first receiving private key = m/49'/1'/0'/0/0
account0recvPrivateKey = cULrpoZGXiuC19Uhvykx7NugygA3k86b3hmdCeyvHYQZSxojGyXJ
account0recvPrivateKeyHex = 0xc9bdb49cfbaedca21c4b1f3a7803c34636b1d7dc55a717132443fc3f4c5867e8
account0recvPublicKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f
account0recvPublickKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f
// Address derivation
keyhash = HASH160(account0recvPublicKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3
keyhash = HASH160(account0recvPublickKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3
scriptSig = <0 <keyhash>> = 0x001438971f73930f6c141d977ac4fd4a727c854935b3
addressBytes = HASH160(scriptSig) = 0x336caa13e08b96080a32b5d818d59b4ab3b36742

8
bip-0050.mediawiki
View File

@ -1,10 +1,12 @@
<pre>
BIP: 50
Title: March 2013 Chain Fork Post-Mortem
Authors: Gavin Andresen <gavinandresen@gmail.com>
Status: Deployed
Author: Gavin Andresen <gavinandresen@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0050
Status: Final
Type: Informational
Assigned: 2013-03-20
Created: 2013-03-20
License: PD
</pre>

301
bip-0052.mediawiki
View File

@ -1,301 +0,0 @@
<pre>
BIP: 52
Layer: Consensus (hard fork)
Title: Durable, Low Energy Bitcoin PoW
Authors: Michael Dubrovsky <mike+bip@powx.org>
Bogdan Penkovsky <bogdan+bip@powx.org>
Status: Closed
Type: Specification
Assigned: 2021-05-13
License: BSD-2-Clause OR OPUBL-1.0
</pre>
== Simple Summary ==
Bitcoin's energy consumption is growing with its value (see Figure below).
Although scaling PoW is necessary to maintain the security of the network,
reliance on massive energy consumption has scaling drawbacks and leads to mining
centralization. A major consequence of the central role of local electricity
cost in mining is that today, most existing and potential participants in the
Bitcoin network cannot profitably mine Bitcoin even if they have the capital to
invest in mining hardware. From a practical perspective, Bitcoin adoption by
companies like Tesla (which recently rescinded its acceptance of Bitcoin as
payment) has been hampered by its massive energy consumption and perceived
environmental impact.
<img src="bip-0052/btc_energy-small.png"></img>
Figure. Bitcoin price and estimated Bitcoin energy consumption.
Data sources: [https://cbeci.org Cambridge Bitcoin Electricity Consumption Index], [https://www.coindesk.com CoinDesk].
We propose a novel proof-of-work paradigm for Bitcoin--Optical proof-of-work. It
is designed to decouple Bitcoin mining from energy and make it feasible outside
of regions with low electricity costs. ''Optical proof-of-work'' (oPoW) is a
modification of Hashcash that is most efficiently computed using a new class of
photonic processors. Without compromising the cryptographic or game-theoretical
security of Hashcash, oPoW shifts the operating expenses of mining (OPEX), to
capital expenses (CAPEX)--i.e. electricity to hardware. oPoW makes it possible
for billions of new miners to enter the market simply by investing in a
low-energy photonic miner. Shifting to a high-CAPEX PoW has the added benefit of
making the hashrate resilient to Bitcoin's price fluctuations - once low-OPEX
hardware is operating there is no reason to shut it down even if the value of
mining rewards diminishes. oPoW is hardware-compatible with GPUs, FPGAs, and
ASICs meaning that a transitional period of optical and traditional hardware
mining in parallel on the network is feasible
More information is available here: [https://www.powx.org/opow].
== Abstract ==
As Bitcoin gained utility and value over the preceding decade, the network incentivized the purchase of billions of dollars in mining equipment and electricity. With the growth of competition, home mining became unprofitable. Even the most sophisticated special-purpose hardware (ASIC miners) doesn’t cover its energy costs unless the miner also has direct access to very cheap electricity. This heavy reliance on energy makes it difficult for new miners to enter the market and leads to hashrate instability as miners shut off their machines when the price of Bitcoin falls. Additionally as the network stores ever more value, the percentage of world energy consumption that is associated with Bitcoin continues to grow, creating the potential for scaling failure and a general backlash. To ensure that Bitcoin can continue scaling and reach its full potential as a world currency and store of value, we propose a low-energy proof-of-work paradigm for Bitcoin. ''Optical proof of work (oPoW)'' is designed to decouple Bitcoin’s security from massive energy use and make bitcoin mining feasible outside of regions with low electricity costs. ''Optical proof-of-work'' is a modification of Hashcash that is most efficiently computed using a new class of photonic processors that has emerged as a leading solution for ultra-low energy computing over the last 5 years. oPoW shifts the operating expenses of mining (OPEX), to capital expenses (CAPEX)–i.e. electricity to hardware, without compromising the cryptographic or game-theoretical security of Hashcash. We provide an example implementation of oPoW, briefly discuss its cryptographic construction as well as the working principle of photonic processors. Additionally, we outline the potential benefits of oPoW to the bitcoin network, including geographic decentralization and democratization of mining as well as hashrate resilience to price fluctuations.
== Copyright ==
This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
== Motivation ==
As Bitcoin has grown over the past decade from a small network run by hobbyists to a global currency, the underlying Proof of Work protocol has not been updated. Initially pitched as a global decentralized network (“one CPU-one vote”), Bitcoin transactions today are secured by a small group of corporate entities. In practice, it is only feasible for [http://archive.is/YeDwh entities that can secure access to abundant, inexpensive energy]. The economics of mining limit profitability to places like Iceland, Texas, or Western China. Besides the negative environmental externalities, which may be significant, mining today is performed primarily with the consent (and in many cases, partnership) of large public utilities and the governments that control them. Although this may not be a problem in the short term, in the long term it stands to erode the censorship resistance and security of Bitcoin and other public blockchains through potential regulation or [https://arxiv.org/pdf/1605.07524.pdf partitioning attacks].
Recent events, such as the [https://twitter.com/MustafaYilham/status/1384278267067203590 ~25% hashrate crash due to coal-powered grid failure in china] and Tesla’s rescinding of its acceptance of Bitcoin as a form of payment, show that there are practical real-world downsides to Proof of Works’s massive reliance on energy.
<img src="bip-0052/emusk_tweet.png"></img>
Whether or not the Bitcoin community accepts this common criticism as entirely valid, it has real-world effects which will only get worse over time. Eliminating the exponentially growing energy use currently built into Bitcoin without eliminating the security of PoW would be ideal and should not be a partisan issue.
New consensus mechanisms have been proposed as a means of securing cryptocurrencies whilst reducing energy cost, such as various forms of Proof of Stake and Proof of Space-Time. While many of these alternative mechanisms offer compelling guarantees, they generally require new security assumptions, which have not been stress-tested by live deployments at any adequate scale. Consequently, we still have relatively little empirical understanding of their safety. Completely changing the Bitcoin paradigm is likely to introduce new unforeseen problems. We believe that the major issues discussed above can be resolved by improving rather than eliminating Bitcoin’s fundamental security layer—Proof of Work. Instead of devising a new consensus architecture to fix these issues, it is sufficient to shift the economics of PoW. The financial cost imposed on miners need not be primarily composed of electricity. The situation can be significantly improved by reducing the operating expense (OPEX)—energy—as a major mining component. Then, by shifting the cost towards capital expense (CAPEX)—mining hardware—the dynamics of the mining ecosystem becomes much less dependent on electricity prices, and much less electricity is consumed as a whole.
Moreover, a reduction in energy consumption automatically leads to
geographically distributed mining, as mining becomes profitable even in regions
with expensive electricity. Additionally, lower energy consumption will
eliminate heating issues experienced by today’s mining operations, which will
further decrease operating cost as well as noise associated with fans and
cooling systems. All of this means that individuals and smaller entities would
be able to enter the mining ecosystem simply for the cost of a miner, without
first gaining access to cheap energy or a dedicated, temperature-controlled data
center. To a degree, memory-hard PoW schemes like
[https://github.com/tromp/cuckoo Cuckoo Cycle], which increase the use of SRAM
in lieu of pure computation, push the CAPEX/OPEX ratio in the right direction by
occupying ASIC chip area with memory. To maximize the CAPEX to OPEX ratio of the
Optical Proof of Work algorithm, we developed
[https://assets.pubpub.org/xi9h9rps/01581688887859.pdf ''HeavyHash''] [1].
HeavyHash is a cryptographic construction that takes the place of SHA256 in
Hashcash. Our algorithm is hardware-compatible with ultra-energy-efficient photonic co-processors that have been developed for machine learning hardware accelerators.
HeavyHash uses a proven digital hash (SHA3) packaged with a large amount of MAC (Multiply-and-Accumulate) computation into a Proof of Work puzzle. Although HeavyHash can be computed on any standard digital hardware, it becomes hardware efficient only when a small digital core is combined with a low-power photonic co-processor for performing MAC operations. oPoW mining machines will have a small digital core flip-chipped onto a large, low-power photonic chip. This core will be bottlenecked by the throughput of the digital to analog and analog to digital converters. A prototype of such analogue optical matrix multiplier can be seen in the figure below.
<img src="bip-0052/optical_chip.png"></img>
Figure. TOP: Photonic Circuit Diagram, A. Laser input (1550nm, common telecom wavelength) B. Metal pads for controlling modulators to transduce electrical data to optical C. Metal pads for tuning mesh of directional couplers D. Optical signal exits here containing the results of the computation and is output to fibers via a grating coupler the terminus of each waveguide. E. Alignment circuit for aligning fiber coupling stage. Bottom: a photograph of a bare oPoW miner prototype chip before wire and fiber bonding. On the right side of the die are test structures (F).
The ''HeavyHash'' derives its name from the fact that it is bloated or weighted with additional computation. This means that a cost comparable oPoW miner will have a much lower nominal hashrate compared to a Bitcoin ASIC (HeavyHashes/second vs. SHA256 Hashes/second in equivalent ASIC). We provide the cryptographic security argument of the HeavyHash function in Section 3 in [https://assets.pubpub.org/xi9h9rps/01581688887859.pdf Towards Optical Proof of Work] [1]. In the article, we also provide a game-theoretic security argument for CAPEX-heavy PoW. For additional information, we recommend reading [https://uncommoncore.co/wp-content/uploads/2019/10/A-model-for-Bitcoins-security-and-the-declining-block-subsidy-v1.02.pdf this article].
While traditional digital hardware relies on electrical currents, optical
computing uses light as the basis for some of or all of its operations. Building
on the development and commercialization of silicon photonic chips for telecom
and datacom applications, modern photonic co-processors are silicon chips made
using well-established and highly scalable silicon CMOS processes. However,
unlike cutting edge electronics which require ever-smaller features (e.g. 5 nm),
fabricated by exponentially more complex and expensive machinery, silicon
photonics uses old fabrication nodes (90 nm). Due to the large de Broglie
wavelength of photons, as compared to electrons, there is no benefit to using
the small feature sizes. The result is that access to silicon photonic wafer
fabrication is readily available, in contrast to the notoriously difficult
process of accessing advanced nodes. Moreover, the overall cost of entry is
lower as lithography masks for silicon photonics processes are an order of
magnitude cheaper ($500k vs. $5M). Examples of companies developing optical
processors for AI, which will be hardware-compatible with oPoW include [https://lightmatter.co/ Lightmatter], [https://www.lightelligence.ai/ Lightelligence], [https://luminous.co/ Luminous], [https://www.intel.com/content/www/us/en/architecture-and-technology/silicon-photonics/silicon-photonics-overview.html Intel], and other more recent entrants.
== Specification ==
=== HeavyHash ===
The HeavyHash is performed in three stages:
# Keccak hash
# Matrix-vector multiplication
# Keccak of the result xored with the hashed input
Note that the most efficient matrix-vector multiplication is performed on a
photonic miner. However, this linear algebra operation can be performed on any
conventional computing hardware (CPU, GPU, etc.), therefore making the HeavyHash
hardware-compatible with any digital device.
The algorithm’s pseudo-code:
<pre>// M is a Matrix 64 x 64 of Unsigned 4 values
// 256-bitVector
x1 <- keccak(input)
// Reshape the obtained bitvector
// into a 64-vector of unsigned 4-bit values
x2 <- reshape(x1, 64)
// Perform a matrix-vector multiplication.
// The result is 64-vector of 14-bit unsigned.
x3 <- vector_matrix_mult(x2, M)
// Truncate all values to 4 most significant bits.
// This is due to the specifics of analog
// computing by the photonic accelerator.
// Obtain a 64-vector of 4-bit unsigned.
x4 <- truncate_to_msb(x3, 4)
// Interpret as a 256-bitvector
x5 <- flatten(x4)
// 256-bitVector
result <- keccak(xor(x5, x1))</pre>
Which in C can be implemented as:
<pre>
static void heavyhash(const uint16_t matrix[64][64], void* pdata, size_t pdata_len, void* output)
{
uint8_t hash_first[32] __attribute__((aligned(32)));
uint8_t hash_second[32] __attribute__((aligned(32)));
uint8_t hash_xored[32] __attribute__((aligned(32)));
uint16_t vector[64] __attribute__((aligned(64)));
uint16_t product[64] __attribute__((aligned(64)));
sha3_256((uint8_t*) hash_first, 32, (const uint8_t*)pdata, pdata_len);
for (int i = 0; i < 32; ++i) {
vector[2*i] = (hash_first[i] >> 4);
vector[2*i+1] = hash_first[i] & 0xF;
}
for (int i = 0; i < 64; ++i) {
uint16_t sum = 0;
for (int j = 0; j < 64; ++j) {
sum += matrix[i][j] * vector[j];
}
product[i] = (sum >> 10);
}
for (int i = 0; i < 32; ++i) {
hash_second[i] = (product[2*i] << 4) | (product[2*i+1]);
}
for (int i = 0; i < 32; ++i) {
hash_xored[i] = hash_first[i] ^ hash_second[i];
}
sha3_256((uint8_t*)output, 32, (const uint8_t*)hash_xored, 32);
}
</pre>
=== Random matrix generation ===
The random matrix M (which is a HeavyHash parameter) is obtained in a deterministic way and is changed every block. Matrix M coefficients are generated using a pseudo-random number generation algorithm (xoshiro) from the previous block header. If the matrix is not full rank, it is repeatedly generated again.
An example code to obtain the matrix M:
<pre>
void generate_matrix(uint16_t matrix[64][64], struct xoshiro_state *state) {
do {
for (int i = 0; i < 64; ++i) {
for (int j = 0; j < 64; j += 16) {
uint64_t value = xoshiro_gen(state);
for (int shift = 0; shift < 16; ++shift) {
matrix[i][j + shift] = (value >> (4*shift)) & 0xF;
}
}
}
} while (!is_full_rank(matrix));
}
static inline uint64_t xoshiro_gen(struct xoshiro_state *state) {
const uint64_t result = rotl64(state->s[0] + state->s[3], 23) + state->s[0];
const uint64_t t = state->s[1] << 17;
state->s[2] ^= state->s[0];
state->s[3] ^= state->s[1];
state->s[1] ^= state->s[2];
state->s[0] ^= state->s[3];
state->s[2] ^= t;
state->s[3] = rotl64(state->s[3], 45);
return result;
}
</pre>
== Discussion ==
=== Geographic Distribution of Mining Relative to CAPEX-OPEX Ratio of Mining Costs ===
Below is a simple model showing several scenarios for the geographic distribution of mining activity relative to the CAPEX/OPEX ratio of the cost of operating a single piece of mining hardware. As the ratio of energy consumption to hardware cost decreases, geographic variations in energy cost cease to be a determining factor in miner distribution.
Underlying assumptions: 1. Electricity price y is fixed in time but varies geographically. 2. Every miner has access to the same hardware. 3. Each miner’s budget is limited by both the cost of mining equipment as well as the local cost of the electricity they consume
budget = a(p+ey),
where a is the number of mining machines, p is the machine price, e is the total energy consumption over machine lifetime, and y is electricity price.
Note that in locations where mining is not profitable, hashrate is zero.
<img src="bip-0052/sim1.png"></img>
<img src="bip-0052/sim2.png"></img>
<img src="bip-0052/sim3.png"></img>
An interactive version of this diagram can be found [https://www.powx.org/opow here].
=== Why does CAPEX to OPEX shift lead to lower energy consumption? ===
A common misconception about oPoW is that it makes mining “cheaper” by enabling energy-efficient hardware. There is no impact on the dollar cost of mining a block, rather the mix of energy vs. hardware investment changes from about 50/50 to 10/90 or better. We discuss this at length and rigorously in our paper[1].
=== Working Principles of Photonic Processors ===
Photonics accelerators are made by fabricating waveguides in silicon using standard lithography processes. Silicon is transparent to infrared light and can act as a tiny on-chip fiber optical cable. Silicon photonics found its first use during the 2000s in transceivers for sending and receiving optical signals via fiber and has advanced tremendously over the last decade.
By encoding a vector into optical intensities passing through a series of parallel waveguides, interfering these signals in a mesh of tunable interferometers (acting as matrix coefficients), and then detecting the output using on-chip Germanium photodetectors, a matrix-vector multiplication is achieved. A generalized discussion of matrix multiplication setups using photonics/interference can be found in [https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.73.58 Reck et al.] and [https://arxiv.org/abs/1506.06220 Russell et al.] A detailed discussion of several integrated photonic architectures for matrix multiplication and corresponding tuning algorithms can be found in [https://arxiv.org/pdf/1909.06179.pdf Pai et al.]
Below is a conceptual representation of a 3D-packaged oPoW mining chip. Note that the majority of the real estate and cost comes from the photonic die and the laser, with only a small digital SHA3 die needed (as opposed to a conventional miner of the same cost, which would have many copies of this die running in parallel).
<img src="bip-0052/optminer.png"></img>
=== Block Reward Considerations ===
Although it is out of the scope of this proposal, the authors strongly recommend the consideration of a change in the block reward schedule currently implemented in Bitcoin. There is no clear way to incentivize miners with transaction fees only, as has been successfully shown in [https://www.cs.princeton.edu/~smattw/CKWN-CCS16.pdf On the Instability of Bitcoin Without the Block Reward] and other publications, therefore looking a decade or two ahead it will be important to implement a fixed block reward or to slow the decay of the block reward to maintain the security of the network. Given that oPoW miners have low operating costs, once a large number of machines are running the reward level sufficient to keep them in operation and providing robust security can potentially be significantly smaller than in the case of the current SHA256 ASICs securing Bitcoin.
=== Implementation on the Bitcoin Network ===
A hard fork is not necessarily required for the Bitcoin network to test and eventually implement oPoW. It’s possible to add oPoW as a dual PoW to Bitcoin as a soft fork. Tuning the parameters to ensure that, for example, 99.9% of the security budget would be earned by miners via the SHA256 Hashcash PoW and 0.1% via oPoW would create sufficient incentive for oPoW to be stress-tested and to incentivize the manufacture of dedicated oPoW miners. If this test is successful, the parameters can be tuned continuously over time, e.g. oPoW share doubling at every halving, such that oPoW accounts for some target percentage (up to 100% in a complete SHA256 phase-out).
==== Reverse compatibility ====
Our understanding is that oPoW will not be reverse compatible.
=== ASICBOOST ===
Any new PoW algorithm carries the risk of hardware developers discovering and patenting an architecture with a significant speedup, as happened in the case of ASICBOOST for SHA256. HeavyHash is comprised of an SHA hash and 4-bit linear matrix-vector operations. The intent is for the matrix-vector multiplications to account for the majority of the work involved in computing a single HeavyHash operation. As we show in the Minimum Effective Hardness section of Towards Optical Proof of Work[1], there is no workaround to performing the matrix operations when computing HeavyHash, and since the SHA hashes are negligible, a true ASICBOOST-type speed up would require a speed up in linear matrix processing. Since matrix-vector multiplication is at the heart of neural networks and many other common computational workloads, it has been optimized very heavily and is generally very well understood. The acceleration of matrix-vector multiplication hardware (e.g. photonic coprocessors, memristors, etc.) is a very general problem and there are dozens of companies working on it, making it very unlikely for a single party to corner the market.
== Endnotes ==
With significant progress in optical and analog matrix-vector-multiplication chipsets over the last year, we hope to demonstrate commercial low-energy mining on our network in the next 6 months. The current generation of optical matrix processors under development is expected to have 10x better energy consumption per MAC operation than digital implementations, and we expect this to improve by another order of magnitude in future generations.
PoWx will also be publishing the designs of the current optical miner prototypes in the near term under an open-source hardware license.
== Changelog ==
* 2026-06-18:
** Updated to Closed after the proposal has not made progress for several years and [https://groups.google.com/g/bitcoindev/c/Vrh7oED9b9Q/m/TrCEKRjNAAAJ attempts to contact the authors] did not succeed.
== Acknowledgments ==
We thank all the members of the Bitcoin community who have already given us feedback over the last several years as well as others in the optical computing community and beyond that have given their input.
[1] M. Dubrovsky et al. Towards Optical Proof of Work, CES conference (2020) https://assets.pubpub.org/xi9h9rps/01581688887859.pdf
[2] https://sciencex.com/news/2020-05-powering-bitcoin-silicon-photonics-power.html
[3] KISS random number generator http://www.cse.yorku.ca/~oz/marsaglia-rng.html

BIN
bip-0052/btc_energy-small.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 60 KiB

BIN
bip-0052/btc_energy.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 91 KiB

BIN
bip-0052/emusk_tweet.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 545 KiB

BIN
bip-0052/optical_chip.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 223 KiB

BIN
bip-0052/optminer.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 62 KiB

BIN
bip-0052/sim1.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 63 KiB

BIN
bip-0052/sim2.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 67 KiB

BIN
bip-0052/sim3.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 69 KiB

159
bip-0053.mediawiki
View File

@ -1,159 +0,0 @@
<pre>
BIP: 53
Layer: Consensus (soft fork)
Title: Disallow 64-byte transactions
Authors: Chris Stewart <stewart.chris1234@gmail.com>
Status: Draft
Type: Specification
Assigned: 2025-04-11
License: BSD-3-Clause
</pre>
==Abstract==
This BIP describes the rationale for disallowing transactions that are serialized to 64 bytes without the transaction's witness.
We describe the weaknesses to the Merkle tree included in Bitcoin block headers, and various exploits for those weaknesses.
==Specification==
This BIP disallows Bitcoin transactions that are serialized to 64 bytes in length without their witness.
==Motivation==
Bitcoin block headers include a commitment to the set of transactions in a given
block, which is implemented by constructing a Merkle tree of transaction ids
(double-SHA256 hash of a transaction) and including the root of the tree in the
block header. This in turn allows for proving to a Bitcoin light client that a
given transaction is in a given block by providing a path through the tree to the
transaction. However, Bitcoin’s particular construction of the Merkle tree has
several security weaknesses, including at least two forms of block malleability
that have an impact on the consensus logic of Bitcoin Core, and an attack on
light clients, where an invalid transaction could be ”proven” to appear in a block
by doing substantially less work than a SHA256 hash collision would require.
This has been mitigated by Bitcoin Core's relay policy and the RPC interface since 2018<ref>[https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e236133a016ba7064c89bf9ab6da3 PR #11423 disallows transactions that are less than 82 bytes in size from Bitcoin Core relay and RPC interface]</ref><ref>[https://github.com/bitcoin/bitcoin/commit/8c5b3646b5afe8a61f5c66478d8e11f0d2ce5108 Reduces the minimum transaction size required for a transaction to be considered standard from 82 bytes to 65 bytes]</ref>.
=== Block malleability ===
64-byte transactions introduce block malleability. Malicious peers can construct consensus valid and invalid 64-byte
transactions that have the same serialization as the concatenation of 2 hashes in the Merkle tree.
Assume we have a valid Bitcoin block with 2 transactions in it with Txid<sub>0</sub> and Txid<sub>1</sub>.
The Merkle root for this block is H(Txid<sub>0</sub>||Txid<sub>1</sub>).
A malicious user could find a 64-byte transaction T<sub>m</sub> that serializes to Txid<sub>0</sub>||Txid<sub>1</sub>.
Next that user relays the block containing the malicious T<sub>m</sub> rather than the
valid Bitcoin transactions that correspond to Txid<sub>0</sub> and Txid<sub>1</sub>.
==== Block malleability with consensus INVALID transactions ====
The peer receiving the malicious block marks the block as invalid, as T<sub>m</sub>
is not a valid transaction according to network consensus rules.
Other peers on the network receive the valid block containing T<sub>0</sub> and T<sub>1</sub>
and add the block to their blockchain. Peers that receive the invalid block before the valid block
will never come to consensus with their peers due to the malicious user finding a collision
within the block's Merkle root. Finding this collision is approximately 22 bits worth of work.<ref>[[bip-0053/2-BitcoinMerkle.pdf|to produce a block having a Merkle root that
is a hash of a 64-byte quantity that deserializes validly, it’s enough
to just do 8 bits of work to find a workable coinbase (which will hash to the first
32 bytes), plus another ≈22 bits of work ((1/5) ∗224, so slightly less) to find
a workable second transaction that will hash to the second 32 bytes)– a very
small amount of computation.]]</ref>
This attack vector was fixed in Bitcoin Core 0.6.2<ref>[https://bitcoin.org/en/alert/2012-05-14-dos#risks CVE-2012-2459]</ref>, re-introduced in 0.13.x<ref>[https://github.com/bitcoin/bitcoin/pull/7225 #7225]</ref> and patched again in
0.14<ref>[https://github.com/bitcoin/bitcoin/pull/9765 #9765]</ref>.
==== Block malleability with consensus VALID transactions ====
Producing a valid Bitcoin transaction T<sub>m</sub> that adheres to network consensus
rules requires 224 bits of work<ref>[[bip-0053/2-BitcoinMerkle.pdf|Note that the first transaction in a block must be a coinbase, and as discussed
above, that largely constrains the first 32 bytes of the first transaction: only
the 4 version bytes are unconstrained. So it would take at least 28*8= 224 bits
of work to find the first node in a given row of the tree that would match the
first half of a coinbase, in addition to the amount of work required to grind the
second half of the transaction to something meaningful (which is much easier –
only 16 bytes or so are constrained, so approximately 128 bits of work to find a collision). Of course, any of the rows in the Merkle tree could be used, but it nevertheless seems clear that this should be computationally infeasible.]]</ref>.
This is computationally and financially expensive but theoretically possible. This can lead to a persistent chain split on the network.
=== Attack on SPV clients ===
BIP37<ref>[https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP37]</ref>provides a partial Merkle tree format<ref>[https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki#partial-merkle-branch-format Partial Merkle Tree Format]</ref>
that allows you to verify that your Bitcoin transaction is included in a Merkle root embedded in a Bitcoin block header.
Notably this format does not commit to the height of the Merkle tree.
Suppose a (valid) 64-byte transaction T is included in a block with the property that the second 32 bytes (which
are less constrained than the first 32 bytes) are constructed so that they collide
with the hash of some other fake, invalid transaction F. The attacker can fool the SPV client into believing that F
was included in a Bitcoin block rather than T with 81 bits<ref>[[bip-0053/2-BitcoinMerkle.pdf|An attacker who can do 81 bits of work (followed by another 40 bits of work, to
construct the funding transaction whose coins will be spent by this one) is able
to fool an SPV client in this way.]]</ref> of work. Disallowing 64-byte transactions reduces implementation complexity for SPV wallets<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43 The steps needed to make sure a Merkle proof for a 64-byte transaction is secure.]</ref>.
==Rationale==
===SPV clients===
Attacks on SPV clients could be mitigated by knowing the depth of the Merkle tree. Requiring SPV clients to request both the coinbase and payment transaction could mitigate this attack.
To produce a valid coinbase transaction at the same depth that our fake transaction F occurs at would require 224 bits of work.
As mentioned above, this is computationally and financially expensive, but theoretically possible. This design would increase the size
of SPV proofs by 70%.<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/29 Base proof: 80-byte header + 448-byte partial Merkle tree = 528 bytes. Proof with coinbase tx, assuming the coinbase tx is in the left half of the tree and the tx to prove is in the right half of the tree: 80-byte header + 416 bytes partial Merkle tree for coinbase tx + 416 bytes partial Merkle tree for tx = 912 bytes.]</ref>
==Backward compatibility==
There have been 5 64-byte transactions that have occurred in the Bitcoin blockchain as of this
writing <ref>[[bip-0053/64byte-tx-mainnet.txt|64-byte transactions in the Bitcoin blockchain]]</ref>
with the last transaction 7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612<ref>[https://mempool.space/tx/7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612 Last 64-byte transaction in the Bitcoin blockchain]</ref>
occurring at block height 419,606<ref>[https://mempool.space/block/000000000000000000308f1efc24419f34a3bafcc2b53c32dd57e4502865fd84 Block 419,606]</ref>.
====Pre-segwit 64-byte transactions====
Pre-segwit 64-byte transactions cannot spend a UTXO protected by a digital signature.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki After BIP66 was activated on the Bitcoin network, Bitcoin transactions cannot have a digital signature smaller than 9 bytes.]</ref>
The largest scriptSig a pre-segwit 64-byte transaction can have is 4 bytes.<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73]</ref>
There are 6<ref>[[bip-0053/non-standard-hashlock-utxos.txt|As of block `00000000000000000001194ae6be942619bf61aa70822b9643d01c1a441bf2b7` there exist 6 non-standard hashlock UTXOs that could theoretically have a 0-3 byte pre-image. None of them have a 0-3 byte pre-image.]]</ref>
non standard hashlock UTXOs in the Bitcoin blockchain. None of them have a 0-3 byte pre-image. This means they cannot be spent by a 64-byte transaction.
Pre-segwit 64-byte transactions that spend a non-standard UTXO that are inherently malleable.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#trust-free-unconfirmed-transaction-dependency-chain Details on how to malleate a pre-segwit transaction]</ref>
Policy rules such as CLEANSTACK, MINIMALDATA, PUSHONLY are not consensus rules. If a user has a way to confirm an already non-standard
64-byte transaction - they can malleate the transaction by violating policy rules to change the size of the transaction to a size other than 64 bytes.
====Segwit 64-byte transactions====
This BIP disallows single-input single-output segwit transactions that pay to a 2-byte witness program.<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73#p-4382-future-segwit-versions-10 BIP141 says witness programs can be 2 bytes in size, which makes the scriptPubKey a total of 4 bytes]</ref>
The only known use case<ref>[https://bitcoin.stackexchange.com/a/110664 Why do we have 2-byte witness programs? The original rationale for the lower end of the range of valid witness program lengths is that 2 bytes is enough to guarantee no ambiguity of how the program would be pushed (some 1-byte values can - and according to standardness, must - be pushed with OP_n, and dealing with those would have complicated the matter).]</ref>
for this type of transaction is ephemeral anchor outputs.<ref>[https://bitcoinops.org/en/topics/ephemeral-anchors/ What are ephemeral anchor outputs? This allows anyone on the network to use that output as the input to a child transaction. This allows anyone to create the fee-paying child, even if they don’t receive any of the other outputs from the parent transaction. This allows ephemeral anchors to function as fee sponsorship but without requiring any consensus changes.]</ref>
==Reference implementation==
<source lang="cpp">
/**
* We want to enforce certain rules (specifically the 64-byte transaction check)
* before we call CheckBlock to check the Merkle root. This allows us to enforce
* malleability checks which may interact with other CheckBlock checks.
* This is currently called both in AcceptBlock prior to writing the block to
* disk and in ConnectBlock.
* Note that as this function is called before merkle-tree checks, it must never return a
* non-malleable error condition.
*/
static bool ContextualBlockPreCheck(const CBlock& block, BlockValidationState& state, const ChainstateManager& chainman, const CBlockIndex* pindexPrev)
{
if (DeploymentActiveAfter(pindexPrev, chainman, Consensus::DEPLOYMENT_64BYTETX)) {
for (const auto& tx : block.vtx) {
if (::GetSerializeSize(TX_NO_WITNESS(tx)) == 64) {
return state.Invalid(BlockValidationResult::BLOCK_MUTATED, "64-byte-transaction", strprintf("size of tx %s without witness is 64 bytes", tx->GetHash().ToString()));
}
}
}
return true;
}
</source>
The sample implementation is currently open here:
https://github.com/bitcoin-inquisition/bitcoin/pull/24/files
<references />
==Copyright==
This BIP is licensed under the [https://opensource.org/license/BSD-3-Clause BSD-3-Clause License].
==Acknowledgements==
Suhas Daftuar, AJ Towns, Sergio Demian Lerner, Greg Maxwell, Matt Corallo, Antoine Poinsot, Dave Harding and Eric Voskuil

BIN
bip-0053/2-BitcoinMerkle.pdf
View File

Binary file not shown.

5
bip-0053/64byte-tx-mainnet.txt
View File

@ -1,5 +0,0 @@
892f44a49de6f5b212cdbea514d09e692d9fed5d897f37bcef14bd0eedebf193
bbf71454857438c6dfd64c0d92a7c5360a8d8d57c9202f5806449e5b0d26b848
6713d61a83e3d095582211ea8d6db452ac7561e863decba7c4046fb9f6d88aa0
7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612
5302e01dc4b7e34314a34c7c3347107e612b9524be684d388cd4d2ca35ff1ec9

6
bip-0053/non-standard-hashlock-utxos.txt
View File

@ -1,6 +0,0 @@
af32bb06f12f2ae5fdb7face7cd272be67c923e86b7a66a76ded02d954c2f94d:0
faf8989ed87c5a667a1ead813aea718727e01767c124193297eaf409ff4645e5:1
c4b46c5d88327d7af6254820562327c5f11b6ee5449da04b7cfd3710b48b6f55:0
702c36851ed202495c2bec1dd0cefb448b50fafd3a5cdd5058c18ca53fc2c3d1:0
6f8a70aac37786b1f619d40250b8bca1a1f6da487146a7e81091f611068a23ef:0
fb01987b540ec286973aac248fab643de82813af452d958056fee8de9f4535ab:0

266
bip-0054.md
View File

@ -1,266 +0,0 @@
```
BIP: 54
Layer: Consensus (soft fork)
Title: Consensus Cleanup
Authors: Antoine Poinsot <mail@antoinep.com>
Matt Corallo <bips@bluematt.me>
Status: Complete
Type: Specification
Assigned: 2025-04-11
License: CC0-1.0
```
## Abstract
This document proposes new consensus rules in order to fix the timewarp attack, reduce the worst
case block validation time, prevent Merkle tree weaknesses, and avoid duplicate transactions without
[bip-0030][BIP30] validation.
## Motivation
This proposal addresses a number of long-standing vulnerabilities and weaknesses in the Bitcoin
protocol. Bundling these fixes together amortizes the fixed cost of deploying a Bitcoin soft fork.
The [timewarp bug][SE timewarp] makes it possible for a majority-hashrate attacker to arbitrarily
lower mining difficulty, and therefore arbitrarily increase the block rate. In the worst case, an
attacker can bring down the difficulty to its minimum within 38 days of starting the attack. Besides
empowering a 51% attacker, the presence of this bug makes it harder to reason about miners'
incentives. Accelerating the block rate allows an attacker to steal block subsidy from future
miners and increases available block space. It may be in the interest of short-sighted users and
miners to exploit this vulnerability to materially increase the block rate without fatally hurting
the network.
Specially crafted blocks may be expensive to process, [taking up to][Delving worst block] several
minutes to validate even on high-end devices, and up to a few hours on lower-end devices. Long block
validation times are a nuisance to users, increasing the cost to independently fully validate the
consensus rules. In addition they can be used by miners to attack their competition, creating
perverse incentives, centralization pressures and leading to reduced network security.
In computing a block's Merkle root, a transaction with exactly 64 bytes of non-witness data can be
interpreted both as an intermediate node in the tree and as a leaf in the tree. This makes it
possible to trick an SPV verifier into accepting an inclusion proof for a transaction that is not
part of a block, by pretending a 64-byte block transaction is actually an inner node[^9]. Invalidating
64-byte transactions addresses this vulnerability without requiring users of SPV verifiers, or
any other user of Merkle proofs, to rely on one of the available workarounds[^13] or even to know one is
necessary in the first place.
Since [bip-0034][BIP34] activation, explicit [bip-0030][BIP30] validation is not necessary until
block height 1,983,702[^0]. Resuming [bip-0030][BIP30] validation would unnecessarily increase block
validation overhead and preclude alternative full node designs (such as [bip-0182][BIP182] Utreexo).
Enforcing that new coinbase transactions are different from the early [bip-0034][BIP34] violations
makes it possible to get rid of [bip-0030][BIP30] validation forever.
## Specification
For all blocks after activation the following new rules apply.
Given a block at height `N`:
- if `N % 2016` is equal to 0, the timestamp of the block must be set to a value higher than or
equal to the value of the timestamp of block at height `N-1` minus 7200 (T<sub>N</sub> &ge;
T<sub>N−1</sub> − 7200);
- if `N % 2016` is equal to 2015, the timestamp of the block must be set to a value higher than
or equal to the value of the timestamp of the block at height `N-2015` (T<sub>N</sub> &ge;
T<sub>N−2015</sub>).
A limit is set on the number of signature operations present in the scripts used to validate a
transaction. It applies to all transactions in the block except the coinbase transaction[^1]. For
each input in the transaction, count the number of `CHECKSIG` and `CHECKMULTISIG` in the input
scriptSig and previous output's scriptPubKey, including the P2SH redeemScript. If the total summed
over all transaction inputs is strictly higher than 2500, the transaction is invalid. The accounting is the
same as for [bip-0016][BIP16 specs], evaluating the scriptSig, scriptPubKey, and P2SH redeemScript
separately:
1. `CHECKSIG` and `CHECKSIGVERIFY` count as 1 signature operation, whether or not they are evaluated.
2. `CHECKMULTISIG` and `CHECKMULTISIGVERIFY` immediately preceded by `OP_1` through `OP_16` are counted as 1 to 16 signature operations, whether or not they are evaluated.
3. All other `CHECKMULTISIG` and `CHECKMULTISIGVERIFY` are counted as 20 signature operations, whether or not they are evaluated.
Transactions whose witness-stripped serialized size is exactly 64 bytes are invalid.
The coinbase transaction's `nLockTime` field must be set to the height of the block minus 1[^2]
and its `nSequence` field must not be equal to 0xffffffff.
## Rationale
The restrictions on the timestamp of the first and last blocks of a difficulty adjustment period fix
the timewarp and Murch–Zawy vulnerabilities[^3]. The latter poses mostly theoretical concerns but is
extremely low risk to fix: the duration of an adjustment period has never been, and should never be,
negative. The former is fixed by preventing the timestamp of the first block of a difficulty period
from being lower than the previous block's, with a two-hour grace period. A [previous
proposal][BIP-XXXX] to fix the timewarp attack used a ten-minute grace period instead, and this
approach has been adopted for [testnet4][BIP94 timewarp]. Out of an abundance of caution and because it only trivially worsens the
block rate increase under attack, a two-hour grace period is used here[^4].
Disabling some Script operations and functionalities was [previously proposed][BIP-XXXX] to reduce
the worst case block validation time but was met with resistance due to confiscation concerns[^5]. A
delicate balance needs to be struck between minimizing the confiscation risks of a mitigation, even
if merely theoretical, and bounding the costs one could impose on all other users of the system. To
that end, limiting potentially executed signature operations targets the exact harmful behaviour while
preserving maximal flexibility in Script usage.
Such a limit reduces the worst case block validation time by a factor of 40 and drastically
increases the preparation cost of an attack, making it uneconomical for a miner[^6]. The maximum of
2500 was chosen as the tightest value that did not make any non-pathological standard transaction
invalid[^7].
64-byte transactions can only contain a scriptPubKey that lets anyone spend the funds, or one that
burns them. They have also been non-standard since 2019 and never been used since 2016. Several
alternatives to invalidating them were previously proposed. Some believe the improvements for users
of Merkle proofs are too marginal to be worth introducing a discontinuity in the set of valid
witness-stripped transaction sizes. Others have suggested instead committing to the Merkle
tree depth in the header's version field[^8], which would make one workaround for a known
vulnerability easier to deploy. The authors believe it is preferable to address the root cause by
invalidating 64-byte transactions, fixing the vulnerability without Merkle proof users having to
rely on any workaround or even know one is necessary in the first place. See [this post][64 bytes
debate] for an attempt at summarizing the arguments for both sides of this debate.
The `nLockTime` field of transactions is a natural place to store a block height and is currently
unused in coinbase transactions. Using it to enforce that new coinbase transactions differ from
early [bip-0034][BIP34] violations also allows applications to recover the block height without
having to parse Script. Leveraging the existing timelock mechanism makes the check self-contained:
the same coinbase transaction cannot have been valid in a previous block[^11]. This simplifies both
reasoning and client implementation, since the [bip-0030][BIP30] check can be skipped entirely past
Consensus Cleanup activation, regardless of the [bip-0034][BIP34] activation status[^12]. One person
[raised the concern][miningdev nLockTime] that the `nLockTime` field would be an ideal extranonce
for ASIC controllers if such controllers ever became a bottleneck in mining operations. Others
[replied][miningdev nLockTime] that the same benefits could be achieved by using a dummy output
instead, should that ever become necessary. The authors [believe][ML remaining concerns] the
benefits of using `nLockTime` to differentiate coinbase transactions outweigh the theoretical
cost of making it unavailable for extranonce rolling by ASIC controllers.
## Backward compatibility
This proposal only tightens the block validation rules: there is no block that is valid under the
rules proposed in this BIP but not under the existing Bitcoin consensus rules. As a consequence
these changes are backward-compatible with non-upgraded node software. That said, the authors
strongly encourage node operators to upgrade in order to fully validate all consensus rules.
## Miner forward compatibility
Bitcoin Core version [29.0][Core 29.0] and later will not generate a block template that violates
the timestamp restrictions introduced in this BIP. Although it would be extremely unlikely due to
the grace period used in this proposal, miners should use the `curtime` or `mintime` field from the
`getblocktemplate` result for their block's timestamp to make sure they always create blocks valid
according to this proposal. Note this is not a new requirement: using a timestamp lower than the
`mintime` field from the `getblocktemplate` result already leads to creating an invalid block.
Bitcoin Core version [30.0][Core 30.0] and later will not generate a block template including a
transaction that violates the signature operations limit introduced in this BIP.
Bitcoin Core version [0.16.1][Core 0.16.1] and later will neither relay nor create block templates
that include transactions whose witness-stripped serialized size is exactly 64 bytes.
The coinbase transaction is usually crafted by mining pool software. To the best of the authors'
knowledge, there does not exist an open source reference broadly in use today for such software.
We encourage mining pools to update their software to craft coinbase transactions that are
forward-compatible with the changes proposed in this BIP.
## Reference implementation
An implementation of BIP54 for Bitcoin Core is available [here][Core BIP 54 implem].
## Test vectors
Documented test vectors are available [here](./bip-0054/test_vectors/) for all mitigations
introduced in this BIP.
## Acknowledgements
This document builds upon an [earlier proposal][BIP-XXXX] by Matt Corallo.
The authors would like to thank everyone involved in researching the most appropriate mitigation for
each of these bugs. We would like to thank in particular Anthony Towns and Sjors Provoost for their
direct contributions to this proposal, as well as @0xb10c and Brian Groll for providing the authors
with data to analyze the proposed mitigations. Thanks to Chris Stewart for digging up historical
violations to the new transaction size rule, which are partially reused in this BIP's test vectors.
## Copyright
This document is licensed under the Creative Commons CC0 1.0 Universal license.
## Changelog
* __1.0.0__ (2026-05-22):
* Complete planned work on the BIP.
[^0]: Block 1,983,702 is the earliest future block which could contain a duplicate coinbase
transaction while still respecting [bip-0034][BIP34]. See [this post][Delving duplicable] for a list
of all such future blocks.
[^1]: Technically this limit *cannot* apply to a coinbase transaction as the size of its sole
input's scriptSig is limited.
[^2]: The locktime validation, which is also performed for coinbase transactions, enforces that the
nLockTime value is the last block at which a transaction is invalid, not the first one at which it
is valid.
[^3]: The timewarp attack is described [here][SE timewarp] and the Murch–Zawy attack [here][Delving
Murch-Zawy].
[^4]: The testnet4 difficulty exception pushed blocks' timestamps in the future when abused,
revealing how some broken pool software may produce blocks that don't respect a 10 minutes grace
period. Some [raised concerns][Sjors grace period] similarly broken software might be used on
mainnet. Using a grace period of 2 hours instead of 10 minutes only reduces the expected block
interval time under attack by ~2.2 seconds. See [this post][grace period debate summary] for more.
[^5]: The argument is about someone having a timelocked presigned transaction using some of those
features in its output script. The transaction cannot be mined before activation. Such outputs would
not be covered by an amnesty for old UTxOs. See for instance [here][O'Connor OP_CODESEPARATOR] and
[here][O'Connor sighash type] for discussions on this topic.
[^6]: It is important to reduce the worst case block validation time as well as the ratio of
validation time imposed over preparation cost. The former is to limit the damages an externally
motivated attacker can do. The latter is to disincentivize miners slowing down their competition by
mining expensive blocks. See [this thread][ML thread validation time] for more.
[^7]: A non-pathological transaction would have a public key per signature operation and at least
one signature per input. Per standardness a single P2SH input may not have more than 15 signature
operations. Even by using 1-of-15 `CHECKMULTISIG`s a transaction would bump against the maximum
standard transaction size before running into the newly introduced limit. To run against the newly
introduced limit but not the transaction size a transaction would need to spend P2SH inputs with a
redeem script similar to `CHECKSIG DROP CHECKSIG DROP ...`. This type of redeem script serves no
purpose beyond increasing its validation cost, which is exactly what this proposal aims to mitigate.
[^8]: By Sergio Demian Lerner in a [blog post][Sergio post].
[^9]: Conversely, pretending that the inner nodes on one level of the tree are the actual block
transactions is another source of complexity for full node implementations, which previously
resulted in consensus bugs. For instance, Bitcoin Core versions between 0.13.0 and 0.13.2
implemented caching that made it vulnerable to this attack. See [this writeup][Suhas Merkle] by
Suhas Daftuar for a detailed explanation. Invalidating 64-byte transactions may avoid this risk, but
the issue is largely orthogonal to this proposal: it is fundamentally about caching validation
status for malleable blocks.
[^11]: Technically it could be argued a duplicate could in principle always be possible before block
31,001 when `nLockTime` enforcement [was originally soft-forked][Harding nLockTime]. But treating
coinbase transactions as not having duplicate past Consensus Cleanup activation would be consistent
for any implementation which enforces `nLockTime` from the genesis block, which is the behaviour
notably of Bitcoin Core but also of all other implementations the authors are aware of.
[^12]: For instance Bitcoin Core only disables [bip-0030][BIP30] validation for a specific chain
where [bip-0034][BIP34] violations have been manually inspected (see [here][Core validation.cpp
BIP34]). Without the guarantee given by enforcing the timelock on coinbase transactions, this would
have to be perpetuated for the Consensus Cleanup.
[^13]: The authors are aware of three workarounds for SPV verifiers. The first is to request a
Merkle proof for the coinbase transaction in addition to the transaction of interest, to infer the
depth of the Merkle tree. The second is to reject Merkle proofs in which any inner node is also a
valid serialisation of a Bitcoin transaction. More details about these are available [here][Sergio
post]. A third workaround is to change the Merkle proof structure by requiring inner nodes to be
provided as the single-SHA256 of their preimage, instead of the double-SHA256. See [here][Sergio
MERKLEBLOCK] for a full description.
[Delving worst block]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/93
[BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
[BIP182]: https://github.com/bitcoin/bips/pull/1923
[BIP-XXXX]: https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki
[BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
[BIP16 specs]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification
[SE timewarp]: https://bitcoin.stackexchange.com/questions/75831/what-is-time-warp-attack-and-how-does-it-work-in-general/75834#75834
[Delving Murch-Zawy]: https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062#variant-on-zawys-attack-2
[BIP94 timewarp]: https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#time-warp-fix
[Sjors grace period]: https://delvingbitcoin.org/t/timewarp-attack-600-second-grace-period/1326
[grace period debate summary]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/66
[O'Connor OP_CODESEPARATOR]: https://gnusha.org/pi/bitcoindev/CAMZUoKneArC+YZ36YFwxNTKsDtJhEz5P2cosXKxJS8Rf_3Nyuw@mail.gmail.com
[O'Connor sighash type]: https://gnusha.org/pi/bitcoindev/CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com
[ML thread validation time]: https://gnusha.org/pi/bitcoindev/VsltJ2PHqWfzG4BU9YETTXjL7fYBbJhjVXKZQyItemySIA1okvNee9kf0zAOyLMeJ4Nqv1VOrYbWns5nP4TANCWvPJYu1ew_yxQSaudizzk=@protonmail.com
[Suhas Merkle]: https://gnusha.org/pi/bitcoindev/CAFp6fsGtEm9p-ZQF_XqfqyQGzZK7BS2SNp2z680QBsJiFDraEA@mail.gmail.com
[Sergio post]: https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design
[Sergio MERKLEBLOCK]: https://bitslog.com/2018/08/21/simple-change-to-the-bitcoin-merkleblock-command-to-protect-from-leaf-node-weakness-in-transaction-merkle-tree/
[64 bytes debate]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41
[Harding nLockTime]: https://bitcoin.stackexchange.com/questions/90229/nlocktime-in-bitcoin-core
[Delving duplicable]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/4
[Core 0.16.1]: https://bitcoincore.org/en/releases/0.16.1
[Core 29.0]: https://bitcoincore.org/en/releases/29.0
[Core BIP 54 implem]: https://github.com/darosior/bitcoin/tree/bip54
[Core 30.0]: https://bitcoincore.org/en/releases/30.0
[Core validation.cpp BIP34]: https://github.com/bitcoin/bitcoin/blob/390e7d61bd531505bb3d13f38316c282b85ed1dd/src/validation.cpp#L2401-L2459
[miningdev nLockTime]: https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk
[ML remaining concerns]: https://gnusha.org/pi/bitcoindev/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com/

102
bip-0054/test_vectors/README.md
View File

@ -1,102 +0,0 @@
## BIP54 test vectors
This folder contains a set of test vectors for each mitigation introduced in the BIP. This document
presents them in more detail.
The code used to generate half of the test vectors is included with the implementation and available
[here][other-vectors]. The other half requires mining mainnet blocks and is [published
separately][bip54-miner]. In both cases it is implemented as a regular Bitcoin Core unit test, and
the test vectors are persisted as a JSON file if the `UPDATE_JSON_TESTS` preprocessor directive is
set (off by default).
To compile the [header][header-miner] and [block][block-miner] miners you may have to link to
libatomic explicitly. This can be achieved like so:
```
cmake -B atomicbuild -DAPPEND_LDFLAGS="-latomic"
cmake --build atomicbuild/ -j $(nproc)
```
[Premined headers][premined-headers] are also provided along with the header miner to allow changing
some of the last headers without having to re-generate the whole chain.
### Difficulty adjustment exploits
The [`timestamps.json`](./timestamps.json) test vectors exercise the two constraints on block header
timestamps introduced by BIP54 to mitigate the Timewarp and Murch-Zawy attacks. Each test case
features a chain of mainnet headers starting from the genesis block, and whether this header chain
is valid by BIP54 rules. Each test case also contains a comment describing why this particular chain
is (in)valid according to BIP54. All test cases are valid according to current Bitcoin consensus
rules. It is intended to be used to test a BIP54 implementation by feeding the header chain to a
Bitcoin node implementation, enforcing the BIP54 rules on this chain from genesis.
The test vector file features a JSON array of JSON objects, each corresponding to a test case. Each
JSON object features the following entries:
- `header_chain`: a JSON array of strings. An ordered list of hex-encoded mainnet block headers.
- `valid`: a JSON boolean. Whether this chain of headers is valid according to BIP54.
- `comment`: a JSON string. Description of the test case.
For the purpose of testing a Timewarp fix, a Timewarp attack was included early on in the history of
testnet3. An implementer of BIP54 may want to ensure that syncing testnet3 by enforcing BIP54 since
genesis will treat block `00000000118da1e2165a19307b86f87eba814845e8a0f99734dce279ca3fb029` as
invalid.
### Long block validation time
The [`sigops.json`](sigops.json) file contains test vectors for the limit on the number of
potentially-executed legacy signature operations in a single transaction, introduced by BIP54 in
order to mitigate long block validation times. Each test case represents a transaction and whether a
block containing it would be valid according to BIP54. The test cases feature an extensive set of
combinations of inputs and output types, ways to run into the limit, historical violations and some
pathological transactions exhibiting the specific implementation details. All test cases but those
belonging to this last category feature transactions that are valid under current Bitcoin consensus
rules. Each test case also features a comment describing why the transaction is (in)valid according
to BIP54.
The test vector file features a JSON array of JSON objects, each corresponding to a test case. Each
JSON object features the following entries:
- `spent_outputs`: a JSON array of strings. An ordered list of hex-encoded Bitcoin-serialized
transaction outputs spent by each input of this test case's transaction.
- `tx`: a JSON string. A hex-encoded Bitcoin-serialized transaction to be evaluated.
- `valid`: a JSON boolean. Whether this transaction is valid according to current consensus rules
supplemented by BIP54.
- `comment`: a JSON string. Description of the test case.
### Merkle tree malleability with 64-byte transactions
The [`txsize.json`](./txsize.json) file contains test cases exercising the new constraint on
non-witness transaction size introduced in BIP54. Each test case contains a transaction and whether
it would be valid according to BIP54, as well as a comment describing why it is (in)valid. All test
cases are otherwise valid according to current Bitcoin consensus rules.
The test vector file features a JSON array of JSON objects, each corresponding to a test case. Each
JSON object features the following entries:
- `tx`: a JSON string. A hex-encoded Bitcoin-serialized transaction to be evaluated.
- `valid`: a JSON boolean. Whether this transaction is valid according to BIP54.
- `comment`: a JSON string. Description of the test case.
### Possibility of duplicate coinbase transactions
The [`coinbases.json`](./coinbases.json) file contains test cases exercising the new restrictions on
coinbase transactions introduced in BIP54 to prevent duplicate coinbase transactions without
resorting to BIP30 validation. Each test case contains a chain of mainnet blocks (including the
genesis block), and whether this block chain is valid according to BIP54. All test cases are valid
according to current Bitcoin's consensus rules, except one that features a block containing a
coinbase transaction timelocked to a future block height.
The test vector file features a JSON array of JSON objects, each corresponding to a test case. Each
JSON object features the following entries:
- `block_chain`: a JSON array of strings. An ordered list of hex-encoded mainnet blocks.
- `valid`: a JSON boolean. Whether this block chain is valid according to current Bitcoin consensus
rules supplemented by BIP54.
- `comment`: a JSON string. Description of the test case.
[bip54-miner]: https://github.com/darosior/bitcoin/commits/bip54_miner/
[header-miner]: https://github.com/darosior/bitcoin/blob/bip54_miner/src/test/bip54_header_miner.cpp
[block-miner]: https://github.com/darosior/bitcoin/blob/bip54_miner/src/test/bip54_block_miner.cpp
[other-vectors]: https://github.com/darosior/bitcoin/blob/2509_inquisition_consensus_cleanup/src/test/bip54_tests.cpp
[premined-headers]: https://github.com/darosior/bitcoin/blob/bip54_miner/src/test/bip54_premined_headers.h

80
bip-0054/test_vectors/coinbases.json
View File

@ -1,80 +0,0 @@
[
{
"block_chain": [
"0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"010000006fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d619000000000068fcdbe419c7d12484fd7e1f7cc22c98e4afab982539e2333ca8ce9a317a592f81ad5f49ffff001d846f5e090101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff025100feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"01000000a58a17b4a4487b9c83ab80ed6a9ccbb9de25925193cc084f41872bd700000000462c6597dd11214ae6f20905dc3828c000a693c3e4b17df82469e528dd9eeab8d9af5f49ffff001dd6bbd40a0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05520360ae0afeffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac01000000",
"010000005702226e10bfe0b24a41a05f406c73046b9ad6fca09255968d3a954b00000000d72d147d9b46612e6adb7168821448e3eca3231ffce8c812a1503ab30001e3bd31b25f49ffff001d7b1408060101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05530320d613feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac02000000",
"01000000131cda7ce756b84bd95dd3ee07333f2224e286bb9a5e13ed99613746000000003e699c73b70d61674235d749cfcc240c91df1b658ab774fce2779679f6867d4189b45f49ffff001dc1adcf010101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff055403e0c810feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac15000000"
],
"valid": false,
"comment": "Block at height 4 with coinbase's nLockTime set to 21 and non-final nSequence."
},
{
"block_chain": [
"0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"010000006fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d619000000000068fcdbe419c7d12484fd7e1f7cc22c98e4afab982539e2333ca8ce9a317a592f81ad5f49ffff001d846f5e090101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff025100feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"01000000a58a17b4a4487b9c83ab80ed6a9ccbb9de25925193cc084f41872bd700000000462c6597dd11214ae6f20905dc3828c000a693c3e4b17df82469e528dd9eeab8d9af5f49ffff001dd6bbd40a0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05520360ae0afeffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac01000000",
"010000005702226e10bfe0b24a41a05f406c73046b9ad6fca09255968d3a954b00000000d72d147d9b46612e6adb7168821448e3eca3231ffce8c812a1503ab30001e3bd31b25f49ffff001d7b1408060101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05530320d613feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac02000000",
"01000000131cda7ce756b84bd95dd3ee07333f2224e286bb9a5e13ed996137460000000082cf0907a8dfb0b461f9c3f4a807cff5fb85df8e54fcc5d8b5a6208b1144fac289b45f49ffff001d094390190101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05540320d613921000000100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac04000000"
],
"valid": false,
"comment": "Block at height 4 with coinbase's nLockTime set to 4 and non-final nSequence."
},
{
"block_chain": [
"0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"010000006fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d619000000000068fcdbe419c7d12484fd7e1f7cc22c98e4afab982539e2333ca8ce9a317a592f81ad5f49ffff001d846f5e090101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff025100feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"01000000a58a17b4a4487b9c83ab80ed6a9ccbb9de25925193cc084f41872bd700000000462c6597dd11214ae6f20905dc3828c000a693c3e4b17df82469e528dd9eeab8d9af5f49ffff001dd6bbd40a0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05520360ae0afeffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac01000000",
"010000005702226e10bfe0b24a41a05f406c73046b9ad6fca09255968d3a954b00000000d72d147d9b46612e6adb7168821448e3eca3231ffce8c812a1503ab30001e3bd31b25f49ffff001d7b1408060101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05530320d613feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac02000000",
"01000000131cda7ce756b84bd95dd3ee07333f2224e286bb9a5e13ed9961374600000000da08acbf43b797bea5a20bb65f0a02871f6272cd0dbd5d192de0b8b241a285aa89b45f49ffff001d5077290a0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff055403400d03feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac02000000"
],
"valid": false,
"comment": "Block at height 4 with coinbase's nLockTime set to 2 and non-final nSequence."
},
{
"block_chain": [
"0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"010000006fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d619000000000068fcdbe419c7d12484fd7e1f7cc22c98e4afab982539e2333ca8ce9a317a592f81ad5f49ffff001d846f5e090101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff025100feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"01000000a58a17b4a4487b9c83ab80ed6a9ccbb9de25925193cc084f41872bd700000000462c6597dd11214ae6f20905dc3828c000a693c3e4b17df82469e528dd9eeab8d9af5f49ffff001dd6bbd40a0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05520360ae0afeffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac01000000",
"010000005702226e10bfe0b24a41a05f406c73046b9ad6fca09255968d3a954b00000000d72d147d9b46612e6adb7168821448e3eca3231ffce8c812a1503ab30001e3bd31b25f49ffff001d7b1408060101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05530320d613feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac02000000",
"01000000131cda7ce756b84bd95dd3ee07333f2224e286bb9a5e13ed99613746000000000035fba8f8f05b94463822ffd007213ff095c4b82e5bc166fd51c8ba01e0659189b45f49ffff001d394a4d070101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff025400fb4003000100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac03000000"
],
"valid": true,
"comment": "Block at height 4 with coinbase's nLockTime set to 3 and non-final nSequence."
},
{
"block_chain": [
"0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"010000006fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d619000000000068fcdbe419c7d12484fd7e1f7cc22c98e4afab982539e2333ca8ce9a317a592f81ad5f49ffff001d846f5e090101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff025100feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"01000000a58a17b4a4487b9c83ab80ed6a9ccbb9de25925193cc084f41872bd700000000462c6597dd11214ae6f20905dc3828c000a693c3e4b17df82469e528dd9eeab8d9af5f49ffff001dd6bbd40a0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05520360ae0afeffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac01000000",
"010000005702226e10bfe0b24a41a05f406c73046b9ad6fca09255968d3a954b00000000d72d147d9b46612e6adb7168821448e3eca3231ffce8c812a1503ab30001e3bd31b25f49ffff001d7b1408060101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05530320d613feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac02000000",
"01000000131cda7ce756b84bd95dd3ee07333f2224e286bb9a5e13ed9961374600000000e7822dba53b0868472211017555701e69bbd9c3e2ec5502347dce64e963cff0989b45f49ffff001dfb8e6e110101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05540360ae0afeffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac03000000"
],
"valid": true,
"comment": "Block at height 4 with coinbase's nLockTime set to 3 and maximum non-final nSequence."
},
{
"block_chain": [
"0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"010000006fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d619000000000068fcdbe419c7d12484fd7e1f7cc22c98e4afab982539e2333ca8ce9a317a592f81ad5f49ffff001d846f5e090101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff025100feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"01000000a58a17b4a4487b9c83ab80ed6a9ccbb9de25925193cc084f41872bd700000000462c6597dd11214ae6f20905dc3828c000a693c3e4b17df82469e528dd9eeab8d9af5f49ffff001dd6bbd40a0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05520360ae0afeffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac01000000",
"010000005702226e10bfe0b24a41a05f406c73046b9ad6fca09255968d3a954b00000000d72d147d9b46612e6adb7168821448e3eca3231ffce8c812a1503ab30001e3bd31b25f49ffff001d7b1408060101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05530320d613feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac02000000",
"01000000131cda7ce756b84bd95dd3ee07333f2224e286bb9a5e13ed9961374600000000a392d0e70a32b369e2ec509ec0b5cdfad3db5f78d594f855588d6193d7e5bef889b45f49ffff001d5ec3630c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05540320d613ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac03000000"
],
"valid": false,
"comment": "Block at height 4 with coinbase's nLockTime set to 3 and final nSequence."
},
{
"block_chain": [
"0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"010000006fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d619000000000068fcdbe419c7d12484fd7e1f7cc22c98e4afab982539e2333ca8ce9a317a592f81ad5f49ffff001d846f5e090101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff025100feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",
"01000000a58a17b4a4487b9c83ab80ed6a9ccbb9de25925193cc084f41872bd700000000462c6597dd11214ae6f20905dc3828c000a693c3e4b17df82469e528dd9eeab8d9af5f49ffff001dd6bbd40a0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05520360ae0afeffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac01000000",
"010000005702226e10bfe0b24a41a05f406c73046b9ad6fca09255968d3a954b00000000d72d147d9b46612e6adb7168821448e3eca3231ffce8c812a1503ab30001e3bd31b25f49ffff001d7b1408060101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05530320d613feffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac02000000",
"01000000131cda7ce756b84bd95dd3ee07333f2224e286bb9a5e13ed99613746000000002be83903e9da68744e4da285d3641faf33694531e1717724d415265bc987bfbb89b45f49ffff001dbfe17c1f0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff05540340420ffeffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac88b45f49"
],
"valid": false,
"comment": "Block at height 4 with coinbase's nLockTime set to block's nTime minus 1 and maximum non-final nSequence."
}
]

1621
bip-0054/test_vectors/sigops.json
View File

File diff suppressed because one or more lines are too long

4134
bip-0054/test_vectors/timestamps.json
View File

File diff suppressed because it is too large Load Diff

67
bip-0054/test_vectors/txsize.json
View File

@ -1,67 +0,0 @@
[
{
"comment": "A 63-byte legacy transaction.",
"tx": "0200000001827da3d85a6547d6b03662d2cb86982d655a6f390547285a3bf9ec9f28e0c8831500000000ffffffff0100000000000000000300515200000000",
"valid": true
},
{
"comment": "A 61-byte legacy transaction with a witness.",
"tx": "02000000000101827da3d85a6547d6b03662d2cb86982d655a6f390547285a3bf9ec9f28e0c8831500000000ffffffff01000000000000000000010000000000",
"valid": true
},
{
"comment": "A 64-byte legacy transaction (4 bytes in spk).",
"tx": "0200000001827da3d85a6547d6b03662d2cb86982d655a6f390547285a3bf9ec9f28e0c8831500000000ffffffff010000000000000000040051525400000000",
"valid": false
},
{
"comment": "A 64-byte legacy transaction (4 bytes in scriptsig).",
"tx": "0200000001827da3d85a6547d6b03662d2cb86982d655a6f390547285a3bf9ec9f28e0c883150000000403424242ffffffff010040075af07507000000000000",
"valid": false
},
{
"comment": "A 65-byte legacy transaction.",
"tx": "0200000001827da3d85a6547d6b03662d2cb86982d655a6f390547285a3bf9ec9f28e0c8831500000000ffffffff01000000000000000005005152545800000000",
"valid": true
},
{
"comment": "A 64-byte Segwit transaction.",
"tx": "02000000000101827da3d85a6547d6b03662d2cb86982d655a6f390547285a3bf9ec9f28e0c8831500000000ffffffff01000000000000000004005152540108213245576281941200000000",
"valid": false
},
{
"comment": "A 64-byte Segwit transaction (1 p2tr input, 1 p2a output).",
"tx": "02000000000101827da3d85a6547d6b03662d2cb86982d655a6f390547285a3bf9ec9f28e0c8831500000000ffffffff0100000000000000000451024e7301415a78b5a14a2527feb02c08b8124e74c3b9bcc1bd3dba1fbfa87f1c930f28a46fea2bf375105dfd835e212c9127aad4976c46ef86be02edbb681e6f38f9a9e06f0100000000",
"valid": false
},
{
"comment": "A 64-byte Segwit transaction (1 p2tr input with annex, 1 OP_RETURN output).",
"tx": "02000000000101827da3d85a6547d6b03662d2cb86982d655a6f390547285a3bf9ec9f28e0c8831500000000ffffffff010000000000000000046a02ab0102415a78b5a14a2527feb02c08b8124e74c3b9bcc1bd3dba1fbfa87f1c930f28a46fea2bf375105dfd835e212c9127aad4976c46ef86be02edbb681e6f38f9a9e06f01064242ffab212100000000",
"valid": false
},
{
"comment": "Historical 64-byte transaction 892f44a49de6f5b212cdbea514d09e692d9fed5d897f37bcef14bd0eedebf193",
"tx": "0200000001deb98691723fa71260ffca6ea0a7bc0a63b0a8a366e1b585caad47fb269a2ce401000000030251b201000000010000000000000000016a00000000",
"valid": false
},
{
"comment": "Historical 64-byte transaction bbf71454857438c6dfd64c0d92a7c5360a8d8d57c9202f5806449e5b0d26b848",
"tx": "01000000010d0afe3d74062ee60c0ec55579d691d8c8af5c04eb97b777157a21a8c5fb143d00000000035101b100000000010000000000000000016a01000000",
"valid": false
},
{
"comment": "Historical 64-byte transaction 6713d61a83e3d095582211ea8d6db452ac7561e863decba7c4046fb9f6d88aa0",
"tx": "02000000011658a33df410379bb512206659910c9fbd0e50bfb732f7be9936558ff036919401000000035101b201000000010000000000000000016a00000000",
"valid": false
},
{
"comment": "Historical 64-byte transaction 7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612",
"tx": "02000000011a7a4cf262fb7e53e2e6e0b2ef8b763f6ee97d8681ca968d1938418d56e6c38700000000035101b201000000010000000000000000016a00000000",
"valid": false
},
{
"comment": "Historical 64-byte transaction 5302e01dc4b7e34314a34c7c3347107e612b9524be684d388cd4d2ca35ff1ec9",
"tx": "01000000019222bbb054bb9f94571dfe769af5866835f2a97e883959fa757de4064bed8bca01000000035101b100000000010000000000000000016a01000000",
"valid": false
}
]

12
bip-0060.mediawiki
View File

@ -2,12 +2,12 @@
BIP: 60
Layer: Peer Services
Title: Fixed Length "version" Message (Relay-Transactions Field)
Authors: Amir Taaki <genjix@riseup.net>
Author: Amir Taaki <genjix@riseup.net>
Comments-Summary: Discouraged for implementation (one person)
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0060
Status: Closed
Type: Specification
Assigned: 2013-06-16
Status: Draft
Type: Standards Track
Created: 2013-06-16
License: PD
</pre>
@ -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 adherence 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 adherance 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 further 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 futher communication is possible until both peers have exchanged their version.
Payload:

14
bip-0061.mediawiki
View File

@ -2,12 +2,12 @@
BIP: 61
Layer: Peer Services
Title: Reject P2P message
Authors: Gavin Andresen <gavinandresen@gmail.com>
Author: Gavin Andresen <gavinandresen@gmail.com>
Comments-Summary: Controversial; some recommendation, and some discouragement
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0061
Status: Deployed
Type: Specification
Assigned: 2014-06-18
Status: Final
Type: Standards Track
Created: 2014-06-18
</pre>
==Abstract==
@ -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 anything besides diagnosing
use different strings. The string should not be shown to users or used for anthing besides diagnosing
interoperability problems.
The following reject code categories are used; in the descriptions below, "server" is the peer generating
@ -83,7 +83,7 @@ the reject message, "client" is the peer that will receive the message.
==== reject version codes ====
Codes generated during the initial connection process in response to a "version" message:
Codes generated during the intial connection process in response to a "version" message:
{|
| Code || Description
@ -149,7 +149,7 @@ The reject message is backwards-compatible; older peers that do not recognize th
== Implementation notes ==
Implementers must consider what happens if an attacker either sends them
Implementors must consider what happens if an attacker either sends them
reject messages for valid transactions/blocks or sends them random
reject messages, and should beware of possible denial-of-service attacks.
For example, notifying the user of every reject message received

12
bip-0062.mediawiki
View File

@ -4,10 +4,12 @@
BIP: 62
Layer: Consensus (soft fork)
Title: Dealing with malleability
Authors: Pieter Wuille <pieter.wuille@gmail.com>
Status: Closed
Type: Specification
Assigned: 2014-03-12
Author: Pieter Wuille <pieter.wuille@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0062
Status: Withdrawn
Type: Standards Track
Created: 2014-03-12
License: BSD-2-Clause
</pre>
@ -32,7 +34,7 @@ Several sources of malleability are known:
# '''Non-DER encoded ECDSA signatures''' Right now, the Bitcoin reference client uses OpenSSL to validate signatures. As OpenSSL accepts more than serializations that strictly adhere to the DER standard, this is a source of malleability. Since v0.8.0, non-DER signatures are no longer relayed already.
# '''Non-push operations in scriptSig''' Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.
# '''Push operations in scriptSig of non-standard size type''' The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_PUSHDATA1, OP_PUSHDATA2, OP_PUSHDATA4). As the latter ones have the same result as the former ones, they result in additional possibilities.
# '''Push operations in scriptSig of non-standard size type''' The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_PUSHDATA1, OP_PUSHDATA2, OP_PUSHDATA4). As the later ones have the same result as the former ones, they result in additional possibilities.
# '''Zero-padded number pushes''' In cases where scriptPubKey opcodes use inputs that are interpreted as numbers, they can be zero padded.
# '''Inherent ECDSA signature malleability''' ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.
# '''Superfluous scriptSig operations''' Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.

12
bip-0064.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 64
Layer: Peer Services
Title: getutxo message
Authors: Mike Hearn <hearn@vinumeris.com>
Status: Closed
Type: Specification
Assigned: 2014-06-10
Author: Mike Hearn <hearn@vinumeris.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0064
Status: Draft
Type: Standards Track
Created: 2014-06-10
</pre>
==Abstract==
@ -84,7 +86,7 @@ If the requesting client is looking up outputs for a signed transaction that the
client can partly verify the returned output by running the input scripts with it. Currently this
verifies only that the script is correct. A future version of the Bitcoin protocol is likely to also
allow the value to be checked in this way. It does not show that the output is really unspent or was
ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey
ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey
should be checked before execution to ensure the remote peer doesn't just set the script to OP_TRUE.
If the requesting client has a mapping of chain heights to block hashes in the best chain e.g.

48
bip-0065.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 65
Layer: Consensus (soft fork)
Title: OP_CHECKLOCKTIMEVERIFY
Authors: Peter Todd <pete@petertodd.org>
Status: Deployed
Type: Specification
Assigned: 2014-10-01
Author: Peter Todd <pete@petertodd.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0065
Status: Final
Type: Standards Track
Created: 2014-10-01
License: PD
</pre>
@ -92,7 +94,7 @@ There exist a number of protocols where a transaction output is created that
requires the co-operation of both parties to spend the output. To ensure the
failure of one party does not result in the funds becoming lost, refund
transactions are setup in advance using nLockTime. These refund transactions
need to be created interactively, and additionally, are currently vulnerable to
need to be created interactively, and additionaly, are currently vulnerable to
transaction malleability. CHECKLOCKTIMEVERIFY can be used in these protocols,
replacing the interactive setup with a non-interactive setup, and additionally,
making transaction malleability a non-issue.
@ -134,7 +136,7 @@ transaction is created, tx3, to ensure that should the payee vanish the payor
can get their deposit back. The process by which the refund transaction is
created is currently vulnerable to transaction malleability attacks, and
additionally, requires the payor to store the refund. Using the same
scriptPubKey form as in the Two-factor wallets example solves both these issues.
scriptPubKey from as in the Two-factor wallets example solves both these issues.
===Trustless Payments for Publishing Data===
@ -168,7 +170,7 @@ Proving the sacrifice of some limited resource is a common technique in a
variety of cryptographic protocols. Proving sacrifices of coins to mining fees
has been proposed as a ''universal public good'' to which the sacrifice could
be directed, rather than simply destroying the coins. However doing so is
non-trivial, and even the best existing technique - announce-commit sacrifices
non-trivial, and even the best existing technqiue - announce-commit sacrifices
- could encourage mining centralization. CHECKLOCKTIMEVERIFY can be used to
create outputs that are provably spendable by anyone (thus to mining fees
assuming miners behave optimally and rationally) but only at a time
@ -203,19 +205,19 @@ transaction output ''can'' be spent.
Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.
case OP_NOP2:
{
// CHECKLOCKTIMEVERIFY
//
// (nLockTime -- nLockTime )
if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY))
break; // not enabled; treat as a NOP
if (stack.size() < 1)
return false;
// Note that elsewhere numeric opcodes are limited to
// operands in the range -2**31+1 to 2**31-1, however it is
// legal for opcodes to produce results exceeding that
@ -231,13 +233,13 @@ semantics and detailed rationale for those semantics.
// to 5-byte bignums, which are good until 2**32-1, the
// same limit as the nLockTime field itself.
const CScriptNum nLockTime(stacktop(-1), 5);
// In the rare event that the argument may be < 0 due to
// some arithmetic being done first, you can always use
// 0 MAX CHECKLOCKTIMEVERIFY.
if (nLockTime < 0)
return false;
// There are two types of nLockTime: lock-by-blockheight
// and lock-by-blocktime, distinguished by whether
// nLockTime < LOCKTIME_THRESHOLD.
@ -250,12 +252,12 @@ semantics and detailed rationale for those semantics.
(txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
))
return false;
// Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one.
if (nLockTime > (int64_t)txTo.nLockTime)
return false;
// Finally the nLockTime feature can be disabled and thus
// CHECKLOCKTIMEVERIFY bypassed if every txin has been
// finalized by setting nSequence to maxint. The
@ -268,9 +270,9 @@ semantics and detailed rationale for those semantics.
// required to prove correct CHECKLOCKTIMEVERIFY execution.
if (txTo.vin[nIn].IsFinal())
return false;
break;
}
https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4
@ -310,24 +312,20 @@ time.
==References==
PayPub
PayPub - https://github.com/unsystem/paypub
* https://github.com/unsystem/paypub
Jeremy Spilman Payment Channels
* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html
Jeremy Spilman Payment Channels - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html
==Implementations==
Python / python-bitcoinlib
* https://github.com/petertodd/checklocktimeverify-demos
- https://github.com/petertodd/checklocktimeverify-demos
JavaScript / Node.js / bitcore
* https://github.com/mruddy/bip65-demos
- https://github.com/mruddy/bip65-demos
==Copyright==

19
bip-0066.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 66
Layer: Consensus (soft fork)
Title: Strict DER signatures
Authors: Pieter Wuille <pieter.wuille@gmail.com>
Status: Deployed
Type: Specification
Assigned: 2015-01-10
Author: Pieter Wuille <pieter.wuille@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0066
Status: Final
Type: Standards Track
Created: 2015-01-10
License: BSD-2-Clause
</pre>
@ -35,7 +37,7 @@ These operators all perform ECDSA verifications on pubkey/signature pairs, itera
The following code specifies the behaviour of strict DER checking. Note that this function tests a signature byte vector which includes the 1-byte sighash flag that Bitcoin adds, even though that flag falls outside of the DER specification, and is unaffected by this proposal. The function is also not called for cases where the length of sig is 0, in order to provide a simple, short and efficiently-verifiable encoding for deliberately invalid signatures.
DER is specified in https://www.itu.int/rec/T-REC-X.690/en .
DER is specified in http://www.itu.int/rec/T-REC-X.690-200811-I/en .
<pre>
bool static IsValidSignatureEncoding(const std::vector<unsigned char> &sig) {
@ -73,7 +75,7 @@ bool static IsValidSignatureEncoding(const std::vector<unsigned char> &sig) {
// Verify that the length of the signature matches the sum of the length
// of the elements.
if ((size_t)(lenR + lenS + 7) != sig.size()) return false;
// Check whether the R element is an integer.
if (sig[2] != 0x02) return false;
@ -138,8 +140,5 @@ An implementation for the reference client is available at https://github.com/bi
==Acknowledgements==
This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well.
This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well.
==Disclosures==
* Subsequent to the network-wide adoption and enforcement of this BIP, the author [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html disclosed] that strict DER signatures provided an indirect solution to a consensus bug he had previously discovered.

72
bip-0067.mediawiki
View File

@ -2,12 +2,14 @@
BIP: 67
Layer: Applications
Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting
Authors: Thomas Kerin <me@thomaskerin.io>
Jean-Pierre Rupp <root@haskoin.com>
Ruben de Vries <ruben@rubensayshi.com>
Status: Complete
Type: Specification
Assigned: 2015-02-08
Author: Thomas Kerin <me@thomaskerin.io>
Jean-Pierre Rupp <root@haskoin.com>
Ruben de Vries <ruben@rubensayshi.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0067
Status: Proposed
Type: Standards Track
Created: 2015-02-08
License: PD
</pre>
@ -17,7 +19,7 @@ This BIP describes a method to deterministically generate multi-signature pay-to
==Motivation==
Pay-to-script-hash (BIP-0011<ref>[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]</ref>) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts.
Pay-to-script-hash (BIP-0011<ref>[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]</ref>) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts.
Multi-signature pay-to-script-hash transactions are defined in BIP-0016<ref>[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP-0016]</ref>. The redeem script does not require a particular ordering or encoding for public keys. This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address. Adhering to an ordering and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address.
@ -25,36 +27,36 @@ By adopting a sorting and encoding standard, compliant wallets will always produ
While most web wallets do not presently facilitate the setup of multisignature accounts with users of a different service, conventions which ensure cross-compatibility should make it easier to achieve this.
Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions.
Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions.
This standard will help in enabling a party other than the service provider to recover the wallet without any help from the service provider.
==Specification==
For a set of public keys, ensure that they have been received in compressed form:
022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
Sort them lexicographically according to their binary representation:
Sort them lexicographically according to their binary representation:
021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
..before using the resulting list of keys in a standard multisig redeem script:
OP_2 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 OP_3 OP_CHECKMULTISIG
..before using the resulting list of keys in a standard multisig redeem script:
OP_2 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 OP_3 OP_CHECKSIG
Hash the redeem script according to BIP-0016 to get the P2SH address.
3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
==Compatibility==
* 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.
* 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.
* 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 addresses.
* Implementations which do adopt this standard will be cross-compatible when choosing multisig addressses.
* 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==
@ -73,11 +75,11 @@ Vector 1
** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z
Vector 2 (Already sorted, no action required)
* List:
* List:
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
* Sorted:
* Sorted:
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
@ -87,12 +89,12 @@ Vector 2 (Already sorted, no action required)
** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH
Vector 3:
* List:
* List:
** 030000000000000000000000000000000000004141414141414141414141414141
** 020000000000000000000000000000000000004141414141414141414141414141
** 020000000000000000000000000000000000004141414141414141414141414140
** 030000000000000000000000000000000000004141414141414141414141414140
* Sorted:
* Sorted:
** 020000000000000000000000000000000000004141414141414141414141414140
** 020000000000000000000000000000000000004141414141414141414141414141
** 030000000000000000000000000000000000004141414141414141414141414140
@ -103,11 +105,11 @@ Vector 3:
** 32V85igBri9zcfBRVupVvwK18NFtS37FuD
Vector 4: (from bitcore)
* List:
* List:
** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
* Sorted:
* Sorted:
** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
@ -117,14 +119,14 @@ Vector 4: (from bitcore)
** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
==Acknowledgements==
The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributions in the early discussions of this BIP.
The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributions in the early discussions of this BIP.
==Usage & Implementations==
* [[https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure|BIP-0045]] - Structure for Deterministic P2SH Multisignature Wallets
* [[https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541|Bitcore]]
* [[https://github.com/haskoin/haskoin-core/blob/b41b1deb0989334a7ead6fc993fb8b02f0c00810/haskoin-core/Network/Haskoin/Script/Parser.hs#L112-L122|Haskoin]] - Bitcoin implementation in Haskell
* [[https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441|Armory]]
* [[https://github.com/bitcoinj/bitcoinj/blob/f7ea0b92a619800c143b0142dc70306da33119a9/core/src/main/java/org/bitcoinj/script/ScriptBuilder.java#L331|BitcoinJ]]
==Usage & Implementations==
* [[https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure|BIP-0045]] - Structure for Deterministic P2SH Multisignature Wallets
* [[https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541|Bitcore]]
* [[https://github.com/haskoin/haskoin/blob/master/Network/Haskoin/Script/Parser.hs#L112-122|Haskoin]] Bitcoin implementation in haskell
* [[https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441|Armory]]
* [[https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/script/ScriptBuilder.java#L331|BitcoinJ]]
== References ==
<references>

30
bip-0068.mediawiki
View File

@ -2,13 +2,15 @@
BIP: 68
Layer: Consensus (soft fork)
Title: Relative lock-time using consensus-enforced sequence numbers
Authors: Mark Friedenbach <mark@friedenbach.org>
BtcDrak <btcdrak@gmail.com>
Nicolas Dorier <nicolas.dorier@gmail.com>
kinoshitajona <kinoshitajona@gmail.com>
Status: Deployed
Type: Specification
Assigned: 2015-05-28
Author: Mark Friedenbach <mark@friedenbach.org>
BtcDrak <btcdrak@gmail.com>
Nicolas Dorier <nicolas.dorier@gmail.com>
kinoshitajona <kinoshitajona@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0068
Status: Final
Type: Standards Track
Created: 2015-05-28
</pre>
==Abstract==
@ -19,7 +21,7 @@ This BIP introduces relative lock-time (RLT) consensus-enforced semantics of the
Bitcoin transactions have a sequence number field for each input. The original idea appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly implemented, it assumes miners would prefer higher sequence numbers even if the lower ones were more profitable to mine. However, a miner acting on profit motives alone would break that assumption completely. The change described by this BIP repurposes the sequence number for new use cases without breaking existing functionality. It also leaves room for future expansion and other use cases.
The transaction nLockTime is used to prevent the mining of a transaction until a certain date. nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan. This, among other uses, allows bi-directional payment channels as used in [https://github.com/ElementsProject/lightning/raw/master/doc/miscellaneous/deployable-lightning.pdf Hashed Timelock Contracts (HTLCs)] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Bidirectional_Payment_Channels BIP112].
The transaction nLockTime is used to prevent the mining of a transaction until a certain date. nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan. This, among other uses, allows bi-directional payment channels as used in [https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf Hashed Timelock Contracts (HTLCs)] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Bidirectional_Payment_Channels BIP112].
==Specification==
@ -31,7 +33,7 @@ If bit (1 << 31) of the sequence number is set, then no consensus meaning is app
If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time.
The sequence number encoding is interpreted as follows:
The sequence number encoding is interpreted as follows:
Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks.
@ -63,7 +65,7 @@ enum {
/* Interpret sequence numbers as relative lock-time constraints. */
LOCKTIME_VERIFY_SEQUENCE = (1 << 0),
};
/* Setting nSequence to this value for every input in a transaction
* disables nLockTime. */
static const uint32_t SEQUENCE_FINAL = 0xffffffff;
@ -201,7 +203,7 @@ bool CheckSequenceLocks(const CTransaction &tx, int flags)
return error("%s: Missing input", __func__);
}
if (coins.nHeight == MEMPOOL_HEIGHT) {
// Assume all mempool transactions are confirmed in the next block
// Assume all mempool transaction confirm in the next block
prevheights[txinIndex] = tip->nHeight + 1;
} else {
prevheights[txinIndex] = coins.nHeight;
@ -240,10 +242,10 @@ Additionally, this BIP specifies only 16 bits to actually encode relative lock-t
The most efficient way to calculate sequence number from relative lock-time is with bit masks and shifts:
<pre>
// 0 <= nHeight <= 65,535 blocks (1.25 years)
// 0 <= nHeight < 65,535 blocks (1.25 years)
nSequence = nHeight;
nHeight = nSequence & 0x0000ffff;
// 0 <= nTime < 33,554,431 seconds (1.06 years)
nSequence = (1 << 22) | (nTime >> 9);
nTime = (nSequence & 0x0000ffff) << 9;
@ -259,5 +261,5 @@ BIP112: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
BIP113: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
Hashed Timelock Contracts (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/miscellaneous/deployable-lightning.pdf
Hashed Timelock Contracts (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf

16
bip-0069.mediawiki
View File

@ -2,11 +2,13 @@
BIP: 69
Layer: Applications
Title: Lexicographical Indexing of Transaction Inputs and Outputs
Authors: Kristov Atlas <kristov@openbitcoinprivacyproject.org>
Author: Kristov Atlas <kristov@openbitcoinprivacyproject.org>
Editor: Daniel Cousens <bips@dcousens.com>
Status: Complete
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0069
Status: Proposed
Type: Informational
Assigned: 2015-06-12
Created: 2015-06-12
License: PD
</pre>
@ -76,7 +78,7 @@ N.B. All comparisons do not need to operate in constant time since they are not
===Transaction Inputs===
Transaction inputs are defined by the hash of a previous transaction, the output index of a UTXO from that previous transaction, the size of an unlocking script, the unlocking script, and a sequence number. [3]
Transaction inputs are defined by the hash of a previous transaction, the output index of of a UTXO from that previous transaction, the size of an unlocking script, the unlocking script, and a sequence number. [3]
For sorting inputs, the hash of the previous transaction and the output index within that transaction are sufficient for sorting purposes; each transaction hash has an extremely high probability of being unique in the blockchain — this is enforced for coinbase transactions by BIP30 — and output indices within a transaction are unique.
For the sake of efficiency, transaction hashes should be compared first before output indices, since output indices from different transactions are often equivalent, while all bytes of the transaction hash are effectively random variables.
@ -85,7 +87,7 @@ In the event of two matching transaction hashes, the respective previous output
If the previous output indices match, the inputs are considered equal.
Transaction malleability will not negatively impact the correctness of this process.
Even if a wallet client follows this process using unconfirmed UTXOs as inputs and an attacker modifies the blockchain’s record of the hash of the previous transaction, the wallet client will include the invalidated previous transaction hash in its input data, and will still correctly sort with respect to that invalidated hash.
Even if a wallet client follows this process using unconfirmed UTXOs as inputs and an attacker changes modifies the blockchain’s record of the hash of the previous transaction, the wallet client will include the invalidated previous transaction hash in its input data, and will still correctly sort with respect to that invalidated hash.
===Transaction Outputs===
@ -145,7 +147,7 @@ Outputs:
==References==
* [[https://bitcoinmagazine.com/20273/bitstamp-exchange-activity-trackable-due-multisig-wallet-implementation/|1: Bitstamp Info Leak]]
* [[https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/5a7e2e1555e91bb48edeca3aa710272777d98c2a/2015-1/criteria.md|2: OBPP Random Indexing as Countermeasure]]
* [[https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/2015-1/criteria.md|2: OBPP Random Indexing as Countermeasure]]
* [[https://github.com/aantonop/bitcoinbook/blob/develop/ch05.asciidoc|3: Mastering Bitcoin]]
* [[https://en.bitcoin.it/wiki/Script|4: Bitcoin Wiki on Script]]
* [[http://www.cplusplus.com/reference/algorithm/lexicographical_compare|5: std::lexicographical_compare]]
@ -160,7 +162,7 @@ Outputs:
* [[https://github.com/bitcoinjs/bip69/blob/master/test/fixtures.json|BitcoinJS Test Fixtures]]
* [[https://www.npmjs.com/package/bip69|NodeJS]]
* [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/transaction.js#L120-L142|Blockchain.info public beta]]
* [[https://github.com/btcsuite/btcd/blob/master/btcutil/txsort/txsort.go|Btcsuite]]
* [[https://github.com/btcsuite/btcutil/blob/master/txsort/txsort.go|Btcsuite]]
==Acknowledgements==

22
bip-0069/bip-0069_examples.py Executable file → Normal file
View File

@ -1,6 +1,4 @@
#!/usr/bin/env python3
import binascii
from functools import cmp_to_key
#returns -1 if barr1 is less, 1 if barr1 is greater, and 0 if equal
def bytearr_cmp(barr1, barr2):
@ -31,13 +29,12 @@ def input_cmp(input_tuple1, input_tuple2):
elif (input_tuple1[1] > input_tuple2[1]):
return 1
else:
raise ValueError('Matching previous transaction hash and previous transaction output index for two distinct inputs. Invalid!')
raise ValueError('Matching previous transaction hash and previous transaction output index for two disinct inputs. Invalid!')
def sort_inputs(input_tuples):
return sorted(input_tuples, key=cmp_to_key(input_cmp))
return sorted(input_tuples, cmp=input_cmp)
def print_inputs(ordered_input_tuples):
print("inputs")
index = 0
for prev_tx_hash_byte_arr_little_endian, prev_tx_output_index in ordered_input_tuples:
prev_tx_hash_hex = binascii.hexlify(bytearray(prev_tx_hash_byte_arr_little_endian))
@ -52,13 +49,12 @@ def output_cmp(output_tuple1, output_tuple2):
elif (output_tuple1[0] > output_tuple2[0]):
return 1
#tie-breaker: scriptPubKey_byte_arr
return bytearr_cmp(output_tuple1[1], output_tuple2[1])
return bytearray_cmp(output_tuple1[1], output_tuple2[1])
def sort_outputs(output_tuples):
return sorted(output_tuples, key=cmp_to_key(output_cmp))
return sorted(output_tuples, cmp=output_cmp)
def print_outputs(ordered_output_tuples):
print("outputs")
index = 0
for amount, scriptPubKey_byte_arr in ordered_output_tuples:
scriptPubKey_hex = binascii.hexlify(bytearray(scriptPubKey_byte_arr))
@ -86,7 +82,6 @@ def main():
([0x7d, 0x03, 0x7c, 0xeb, 0x2e, 0xe0, 0xdc, 0x03, 0xe8, 0x2f, 0x17, 0xbe, 0x79, 0x35, 0xd2, 0x38, 0xb3, 0x5d, 0x1d, 0xea, 0xbf, 0x95, 0x3a, 0x89, 0x2a, 0x45, 0x07, 0xbf, 0xbe, 0xeb, 0x3b, 0xa4], 1),
([0x6c, 0x1d, 0x56, 0xf3, 0x1b, 0x2d, 0xe4, 0xbf, 0xc6, 0xaa, 0xea, 0x28, 0x39, 0x6b, 0x33, 0x31, 0x02, 0xb1, 0xf6, 0x00, 0xda, 0x9c, 0x6d, 0x61, 0x49, 0xe9, 0x6c, 0xa4, 0x3f, 0x11, 0x02, 0xb1], 1),
([0xb4, 0x11, 0x2b, 0x8f, 0x90, 0x0a, 0x7c, 0xa0, 0xc8, 0xb0, 0xe7, 0xc4, 0xdf, 0xad, 0x35, 0xc6, 0xbe, 0x5f, 0x6b, 0xe4, 0x6b, 0x34, 0x58, 0x97, 0x49, 0x88, 0xe1, 0xcd, 0xb2, 0xfa, 0x61, 0xb8], 0)]
print("\ntx 0a6a357e2f7796444e02638749d9611c008b253fb55f5dc88b739b230ed0c4c3")
tx_0a6a_sorted_input_tuples = sort_inputs(tx_0a6a_input_tuples)
print_inputs(tx_0a6a_sorted_input_tuples)
@ -99,11 +94,10 @@ def main():
#reference data: https://blockchain.info/rawtx/28204cad1d7fc1d199e8ef4fa22f182de6258a3eaafe1bbe56ebdcacd3069a5f thanks @quantabytes!
tx_2820_input_tuples = [
# (prev_tx_hash_byte_arr_little_endian, prev_tx_output_index)
([0x55, 0x60, 0x5d, 0xc6, 0x5f, 0x3c, 0xcc, 0x4d, 0xb1, 0xd8, 0x56, 0x4a, 0x28, 0x04, 0x2b, 0xdb, 0x2c, 0x2b, 0xe3, 0x85, 0xea, 0xb2, 0xeb, 0xea, 0x41, 0x19, 0xee, 0x9c, 0x26, 0x8d, 0x28, 0x35], 0),
([0x55, 0x60, 0x5d, 0xc6, 0x5f, 0x3c, 0xcc, 0x4d, 0xb1, 0xd8, 0x56, 0x4a, 0x28, 0x04, 0x2b, 0xdb, 0x2c, 0x2b, 0xe3, 0x85, 0xea, 0xb2, 0xeb, 0xea, 0x41, 0x19, 0xee, 0x9c, 0x26, 0x8d, 0x28, 0x35], 1)] #duplicate prev_tx_hash
# (prev_tx_hash, prev_tx_output_index)
("35288d269cee1941eaebb2ea85e32b42cdb2b04284a56d8b14dcc3f5c65d6055", 0),
("35288d269cee1941eaebb2ea85e32b42cdb2b04284a56d8b14dcc3f5c65d6055", 1)] #duplicate prev_tx_hash
print("\ntx 28204cad1d7fc1d199e8ef4fa22f182de6258a3eaafe1bbe56ebdcacd3069a5f")
tx_2820_sorted_input_tuples = sort_inputs(tx_2820_input_tuples)
print_inputs(tx_2820_sorted_input_tuples)
@ -112,7 +106,7 @@ def main():
(100000000, [0x41, 0x04, 0x6a, 0x07, 0x65, 0xb5, 0x86, 0x56, 0x41, 0xce, 0x08, 0xdd, 0x39, 0x69, 0x0a, 0xad, 0xe2, 0x6d, 0xfb, 0xf5, 0x51, 0x14, 0x30, 0xca, 0x42, 0x8a, 0x30, 0x89, 0x26, 0x13, 0x61, 0xce, 0xf1, 0x70, 0xe3, 0x92, 0x9a, 0x68, 0xae, 0xe3, 0xd8, 0xd4, 0x84, 0x8b, 0x0c, 0x51, 0x11, 0xb0, 0xa3, 0x7b, 0x82, 0xb8, 0x6a, 0xd5, 0x59, 0xfd, 0x2a, 0x74, 0x5b, 0x44, 0xd8, 0xe8, 0xd9, 0xdf, 0xdc, 0x0c, 0xac]),
(2400000000, [0x41, 0x04, 0x4a, 0x65, 0x6f, 0x06, 0x58, 0x71, 0xa3, 0x53, 0xf2, 0x16, 0xca, 0x26, 0xce, 0xf8, 0xdd, 0xe2, 0xf0, 0x3e, 0x8c, 0x16, 0x20, 0x2d, 0x2e, 0x8a, 0xd7, 0x69, 0xf0, 0x20, 0x32, 0xcb, 0x86, 0xa5, 0xeb, 0x5e, 0x56, 0x84, 0x2e, 0x92, 0xe1, 0x91, 0x41, 0xd6, 0x0a, 0x01, 0x92, 0x8f, 0x8d, 0xd2, 0xc8, 0x75, 0xa3, 0x90, 0xf6, 0x7c, 0x1f, 0x6c, 0x94, 0xcf, 0xc6, 0x17, 0xc0, 0xea, 0x45, 0xaf, 0xac])]
tx_2820_sorted_output_tuples = sort_outputs(tx_2820_output_tuples)
print_outputs(tx_2820_sorted_output_tuples)
print_outputs(tx_2820_output_tuples)
if __name__ == "__main__":
main()

18
bip-0070.mediawiki
View File

@ -2,11 +2,13 @@
BIP: 70
Layer: Applications
Title: Payment Protocol
Authors: Gavin Andresen <gavinandresen@gmail.com>
Mike Hearn <mhearn@bitcoinfoundation.org>
Status: Deployed
Type: Specification
Assigned: 2013-07-29
Author: Gavin Andresen <gavinandresen@gmail.com>
Mike Hearn <mhearn@bitcoinfoundation.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0070
Status: Final
Type: Standards Track
Created: 2013-07-29
</pre>
==Abstract==
@ -260,7 +262,7 @@ occurs.
Trusted root certificates may be obtained from the operating system;
if validation is done on a device without an operating system, the
[https://www.mozilla.org/about/governance/policies/security-group/certs/policy/ Mozilla root store] is recommended.
[http://www.mozilla.org/projects/security/certs/included/index.html Mozilla root store] is recommended.
==Extensibility==
@ -300,7 +302,7 @@ Protocol Buffers : https://developers.google.com/protocol-buffers/
==Reference implementation==
Create Payment Request generator : https://developer.bitcoin.org/examples/payment_processing.html ([[https://github.com/gavinandresen/paymentrequest|source]])
Create Payment Request generator : https://bitcoincore.org/~gavin/createpaymentrequest.php ([[https://github.com/gavinandresen/paymentrequest|source]])
BitcoinJ : https://bitcoinj.github.io/payment-protocol#introduction
@ -312,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/sipa/1237788
sipa's payment protocol proposal: https://gist.github.com/1237788
ThomasV's "Signed Aliases" proposal : http://ecdsa.org/bitcoin_URIs.html

10
bip-0071.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 71
Layer: Applications
Title: Payment Protocol MIME types
Authors: Gavin Andresen <gavinandresen@gmail.com>
Status: Deployed
Type: Specification
Assigned: 2013-07-29
Author: Gavin Andresen <gavinandresen@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0071
Status: Final
Type: Standards Track
Created: 2013-07-29
</pre>
==Abstract==

12
bip-0072.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 72
Layer: Applications
Title: bitcoin: uri extensions for Payment Protocol
Authors: Gavin Andresen <gavinandresen@gmail.com>
Status: Deployed
Type: Specification
Assigned: 2013-07-29
Author: Gavin Andresen <gavinandresen@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0072
Status: Final
Type: Standards Track
Created: 2013-07-29
</pre>
==Abstract==
@ -67,4 +69,4 @@ bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
==References==
[[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1
[[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1

10
bip-0073.mediawiki
View File

@ -2,10 +2,12 @@
BIP: 73
Layer: Applications
Title: Use "Accept" header for response type negotiation with Payment Request URLs
Authors: Stephen Pair <stephen@bitpay.com>
Status: Deployed
Type: Specification
Assigned: 2013-08-27
Author: Stephen Pair <stephen@bitpay.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0073
Status: Final
Type: Standards Track
Created: 2013-08-27
</pre>
==Abstract==

8
bip-0074.mediawiki
View File

@ -2,12 +2,12 @@
BIP: 74
Layer: Applications
Title: Allow zero value OP_RETURN in Payment Protocol
Authors: Toby Padilla <tobypadilla@gmail.com>
Author: Toby Padilla <tobypadilla@gmail.com>
Comments-Summary: Unanimously Discourage for implementation
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0074
Status: Closed
Type: Specification
Assigned: 2016-01-29
Status: Draft
Type: Standards Track
Created: 2016-01-29
License: PD
</pre>

78
bip-0075.mediawiki
View File

@ -2,15 +2,15 @@
BIP: 75
Layer: Applications
Title: Out of Band Address Exchange using Payment Protocol Encryption
Authors: Justin Newton <justin@netki.com>
Matt David <mgd@mgddev.com>
Aaron Voisine <voisine@gmail.com>
James MacWhyte <macwhyte@gmail.com>
Author: Justin Newton <justin@netki.com>
Matt David <mgd@mgddev.com>
Aaron Voisine <voisine@gmail.com>
James MacWhyte <macwhyte@gmail.com>
Comments-Summary: Recommended for implementation (one person)
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0075
Status: Deployed
Type: Specification
Assigned: 2015-11-20
Status: Draft
Type: Standards Track
Created: 2015-11-20
License: CC-BY-4.0
</pre>
@ -18,11 +18,11 @@
This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol.
# It allows the requester (Sender) of a PaymentRequest to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with.
# It allows the requester (Sender) of a PaymentRequest to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with.
# It encrypts the PaymentRequest that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC 2119.
==Copyright==
@ -125,13 +125,13 @@ message InvoiceRequest {
|-
| memo || Human-readable description of invoice request for the receiver
|-
| notification_url || Secure (usually TLS-protected HTTP) location where an [[#encryptedprotocolmessage|EncryptedProtocolMessage]] SHOULD be sent when ready
| notification_url || Secure (usually TLS-protected HTTP) location where an [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] SHOULD be sent when ready
|-
| signature || PKI-dependent signature
|}
===ProtocolMessageType Enum===
This enum is used in the newly defined [[#protocolmessage|ProtocolMessage]] and [[#encryptedprotocolmessage|EncryptedProtocolMessage]] messages to define the serialized message type. The '''ProtocolMessageType''' enum is defined in an extensible way to allow for new message type additions to the Payment Protocol.
This enum is used in the newly defined [[#ProtocolMessage|ProtocolMessage]] and [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages to define the serialized message type. The '''ProtocolMessageType''' enum is defined in an extensible way to allow for new message type additions to the Payment Protocol.
<pre>
enum ProtocolMessageType {
UNKNOWN_MESSAGE_TYPE = 0;
@ -174,10 +174,10 @@ message ProtocolMessage {
===Versioning===
This BIP introduces version 1 of this protocol. All messages sent using these base requirements MUST use a value of 1 for the version number. Any future BIPs that modify this protocol (encryption schemes, etc) MUST each increment the version number by 1.
When initiating communication, the version field of the first message SHOULD be set to the highest version number the sender understands. All clients MUST be able to understand all version numbers less than the highest number they support. If a client receives a message with a version number higher than they understand, they MUST send the message back to the sender with a status code of 101 ("version too high") and the version field set to the highest version number the recipient understands. The sender must then resend the original message using the same version number returned by the recipient or abort.
When initiating communication, the version field of the first message SHOULD be set to the highest verison number the sender understands. All clients MUST be able to understand all version numbers less than the highest number they support. If a client receives a message with a version number higher than they understand, they MUST send the message back to the sender with a status code of 101 ("version too high") and the version field set to the highest version number the recipient understands. The sender must then resend the original message using the same version number returned by the recipient or abort.
===EncryptedProtocolMessage===
The '''EncryptedProtocolMessage''' message is an encapsulating wrapper for any Payment Protocol message. It allows two-way, authenticated and encrypted communication of Payment Protocol messages in order to keep their contents secret. The message also includes a status code and status message that is used for error communication such that the protocol does not rely on transport-layer error handling.
The '''EncryptedProtocolMessage''' message is an encapsualting wrapper for any Payment Protocol message. It allows two-way, authenticated and encrypted communication of Payment Protocol messages in order to keep their contents secret. The message also includes a status code and status message that is used for error communication such that the protocol does not rely on transport-layer error handling.
<pre>
message EncryptedProtocolMessage {
required uint64 version = 1 [default = 1];
@ -217,14 +217,14 @@ message EncryptedProtocolMessage {
|}
==Payment Protocol Process with InvoiceRequests==
The full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below.
The full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below.
<br/><br/>
All Payment Protocol messages MUST be encapsulated in either a [[#protocolmessage|ProtocolMessage]] or [[#encryptedprotocolmessage|EncryptedProtocolMessage]]. Once the process begins using [[#encryptedprotocolmessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#encryptedprotocolmessage|EncryptedProtocolMessages]].
All Payment Protocol messages MUST be encapsulated in either a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProcotolMessage|EncryptedProtocolMessage]]. Once the process begins using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#EncryptedProtocolMessage|EncryptedProtocolMessages]].
<br/><br/>
All Payment Protocol messages SHOULD be communicated using [[#encryptedprotocolmessage|EncryptedProtocolMessage]] encapsulating messages with the exception that an [[#invoicerequest|InvoiceRequest]] MAY be communicated using the [[#protocolmessage|ProtocolMessage]] if the receiver's public key is unknown.
All Payment Protocol messages SHOULD be communicated using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulating messages with the exception that an [[#InvoiceRequest|InvoiceRequest]] MAY be communicated using the [[#ProtocolMessage|ProtocolMessage]] if the receiver's public key is unknown.
<br/><br/>
The process of creating encrypted Payment Protocol messages is enumerated in [[#sending-encrypted-payment-protocol-messages-using-encryptedprotocolmessages|Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages]], and the process of decrypting encrypted messages can be found under [[#validating-and-decrypting-payment-protocol-messages-using-encryptedprotocolmessages|Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages]].
The process of creating encrypted Payment Protocol messages is enumerated in [[#Sending_Encrypted_Payment_Protocol_Messages_using_EncryptedProtocolMessages|Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages]], and the process of decrypting encrypted messages can be found under [[#Validating_and_Decrypting_Payment_Protocol_Messages_using_EncryptedProtocolMessages|Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages]].
A standard exchange from start to finish would look like the following:
@ -238,7 +238,7 @@ A standard exchange from start to finish would look like the following:
# Sender validates PaymentRequest retrieved from the EncryptedProtocolMessage
# The PaymentRequest is processed according to [[bip-0070.mediawiki|BIP70]], including optional Payment and PaymentACK messages encapsulated in EncryptedProtocolMessage messages.
'''NOTE:''' See [[#initial-public-key-retrieval-for-invoicerequest-encryption|Initial Public Key Retrieval for InvoiceRequest Encryption]] for possible options to retrieve Receiver's public key.
'''NOTE:''' See [[#Initial_Public_Key_Retrieval_for_InvoiceRequest_Encryption|Initial Public Key Retrieval for InvoiceRequest Encryption]] for possible options to retrieve Receiver's public key.
<img src="bip-0075/encrypted-invoice-request-process.png" alt="Flow diagram of Encrypted InvoiceRequest">
@ -257,14 +257,14 @@ When communicated via '''HTTP''', the listed messages MUST be transmitted via TL
===Payment Protocol Status Communication===
Every [[#protocolmessage|ProtocolMessage]] or [[#encryptedprotocolmessage|EncryptedProtocolMessage]] MUST include a status code which conveys information about the last message received, if any (for the first message sent, use a status of 1 "OK" even though there was no previous message). In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a ProtocolMessage or EncryptedProtocolMessage SHOULD be returned by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately.
Every [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MUST include a status code which conveys information about the last message received, if any (for the first message sent, use a status of 1 "OK" even though there was no previous message). In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a ProtocolMessage or EncryptedProtocolMessage SHOULD be returned by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately.
<br/><br/>
The status_message value SHOULD be set with a human readable explanation of the status code.
====Payment Protocol Status Codes====
{| class="wikitable"
! Status Code !! Description
|-
|-
| 1 || OK
|-
| 2 || Cancel
@ -301,7 +301,7 @@ The status_message value SHOULD be set with a human readable explanation of the
If a participant to a transaction would like to inform the other party that a previous message should be canceled, they can send the same message with a status code of 2 ("Cancel") and, where applicable, an updated nonce. How recipients make use of the "Cancel" message is up to developers. For example, wallet developers may want to offer users the ability to cancel payment requests they have sent to other users, and have that change reflected in the recipient's UI. Developers using the non-encrypted ProtocolMessage may want to ignore "Cancel" messages, as it may be difficult to authenticate that the message originated from the same user.
===Transport Layer Communication Errors===
Communication errors MUST be communicated to the party that initiated the communication via the communication layer's existing error messaging facilities. In the case of TLS-protected HTTP, this SHOULD be done through standard HTTP Status Code messaging ([https://tools.ietf.org/html/rfc7231 RFC 7231 Section 6]).
Communication errors MUST be communicated to the party that initiated the communication via the communication layer's existing error messaging faciltiies. In the case of TLS-protected HTTP, this SHOULD be done through standard HTTP Status Code messaging ([https://tools.ietf.org/html/rfc7231 RFC 7231 Section 6]).
==Extended Payment Protocol Process Details==
This BIP extends the Payment Protocol as defined in [[bip-0070.mediawiki|BIP70]].
@ -311,27 +311,27 @@ For the following we assume the Sender already knows the Receiver's public key,
'''nonce''' MUST be set to a non-repeating number '''and''' MUST be chosen by the encryptor. The current epoch time in microseconds SHOULD be used, unless the creating device doesn't have access to a RTC (in the case of a smart card, for example). The service receiving the message containing the '''nonce''' MAY use whatever method to make sure that the '''nonce''' is never repeated.
===InvoiceRequest Message Creation===
* Create an [[#invoicerequest|InvoiceRequest]] message
* Create an [[#InvoiceRequest|InvoiceRequest]] message
* '''sender_public_key''' MUST be set to the public key of an EC keypair
* '''amount''' is optional. If the amount is not specified by the [[#invoicerequest|InvoiceRequest]], the Receiver MAY specify the amount in the returned PaymentRequest. If an amount is specified by the [[#invoicerequest|InvoiceRequest]] and a PaymentRequest cannot be generated for that amount, the [[#invoicerequest|InvoiceRequest]] SHOULD return the same [[#invoicerequest|InvoiceRequest]] in a [[#protocolmessage|ProtocolMessage]] or [[#encryptedprotocolmessage|EncryptedProtocolMessage]] with the status_code and status_message fields set appropriately.
* '''amount''' is optional. If the amount is not specified by the [[#InvoiceRequest|InvoiceRequest]], the Receiver MAY specify the amount in the returned PaymentRequest. If an amount is specified by the [[#InvoiceRequest|InvoiceRequest]] and a PaymentRequest cannot be generated for that amount, the [[#InvoiceRequest|InvoiceRequest]] SHOULD return the same [[#InvoiceRequest|InvoiceRequest]] in a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] with the status_code and status_message fields set appropriately.
* '''memo''' is optional. This MAY be set to a human readable description of the InvoiceRequest
* Set '''notification_url''' to URL that the Receiver will submit completed PaymentRequest (encapsulated in an [[#encryptedprotocolmessage|EncryptedProtocolMessage]]) to
* Set '''notification_url''' to URL that the Receiver will submit completed PaymentRequest (encapsulated in an [[#EncryptedProtocolMessage|EncryptedProtocolMessage]]) to
* If NOT including certificate, set '''pki_type''' to "none"
* If including certificate:
** Set '''pki_type''' to "x509+sha256"
** Set '''pki_data''' as it would be set in BIP-0070 ([https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki#Certificates Certificates])
** Sign [[#invoicerequest|InvoiceRequest]] with signature = "" using the X509 Certificate's private key
** Sign [[#InvoiceRequest|InvoiceRequest]] with signature = "" using the X509 Certificate's private key
** Set '''signature''' value to the computed signature
===InvoiceRequest Validation===
* Validate '''sender_public_key''' is a valid EC public key
* Validate '''sender_public_key''' is a valid EC public key
* Validate '''notification_url''', if set, contains characters deemed valid for a URL (avoiding XSS related characters, etc).
* If '''pki_type''' is None, [[#invoicerequest|InvoiceRequest]] is VALID
* If '''pki_type''' is x509+sha256 and '''signature''' is valid for the serialized [[#invoicerequest|InvoiceRequest]] where signature is set to "", [[#invoicerequest|InvoiceRequest]] is VALID
* If '''pki_type''' is None, [[#InvoiceRequest|InvoiceRequest]] is VALID
* If '''pki_type''' is x509+sha256 and '''signature''' is valid for the serialized [[#InvoiceRequest|InvoiceRequest]] where signature is set to "", [[#InvoiceRequest|InvoiceRequest]] is VALID
===Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages===
* Encrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ecdh-point-generation-and-aes256-gcm-mode-setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]]
* Create [[#encryptedprotocolmessage|EncryptedProtocolMessage]] message
* Encrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ECDH_Point_Generation_and_AES256_GCM_Mode_Setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]]
* Create [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] message
* Set '''encrypted_message''' to be the encrypted value of the Payment Protocol message
* '''version''' SHOULD be set to the highest version number the client understands (currently 1)
* '''sender_public_key''' MUST be set to the public key of the Sender's EC keypair
@ -339,14 +339,14 @@ For the following we assume the Sender already knows the Receiver's public key,
* '''nonce''' MUST be set to the nonce used in the AES-256-GCM encryption operation
* Set '''identifier''' to the identifier value received in the originating InvoiceRequest's ProtocolMessage or EncryptedProtocolMessage wrapper message
* Set '''signature''' to ""
* Sign the serialized [[#encryptedprotocolmessage|EncryptedProtocolMessage]] message with the communicating party's EC public key
* Sign the serialized [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] message with the communicating party's EC public key
* Set '''signature''' to the result of the signature operation above
'''SIGNATURE NOTE:''' [[#encryptedprotocolmessage|EncryptedProtocolMessage]] messages are signed with the public keys of the party transmitting the message. This allows a Store & Forward server or other transmission system to prevent spam or other abuses. For those who are privacy conscious and don't want the server to track the interactions between two public keys, the Sender can generate a new public key for each interaction to keep their identity anonymous.
'''SIGNATURE NOTE:''' [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages are signed with the public keys of the party transmitting the message. This allows a Store & Forward server or other transmission system to prevent spam or other abuses. For those who are privacy conscious and don't want the server to track the interactions between two public keys, the Sender can generate a new public key for each interaction to keep their identity anonymous.
===Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages===
* The '''nonce''' MUST not be repeated. The service receiving the [[#encryptedprotocolmessage|EncryptedProtocolMessage]] MAY use whatever method to make sure that the nonce is never repeated.
* Decrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ecdh-point-generation-and-aes256-gcm-mode-setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]]
* The '''nonce''' MUST not be repeated. The service receiving the [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MAY use whatever method to make sure that the nonce is never repeated.
* Decrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ECDH_Point_Generation_and_AES256_GCM_Mode_Setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]]
* Deserialize the serialized Payment Protocol message
===ECDH Point Generation and AES-256 (GCM Mode) Setup===
@ -366,10 +366,10 @@ For the following we assume the Sender already knows the Receiver's public key,
The 16 byte authentication tag resulting from the AES-GCM encrypt operation MUST be prefixed to the returned ciphertext. The decrypt operation will use the first 16 bytes of the ciphertext as the GCM authentication tag and the remainder of the ciphertext as the ciphertext in the decrypt operation.
====AES-256 GCM Additional Authenticated Data====
When either '''status_code''' OR '''status_message''' are present, the AES-256 GCM authenticated data used in both the encrypt and decrypt operations MUST be: STRING(status_code) || status_message. Otherwise, there is no additional authenticated data. This provides that, while not encrypted, the status_code and status_message are authenticated.
When either '''status_code''' OR '''status_message''' are present, the AES-256 GCM authenticated data used in both the encrypt and decrypt operations MUST be: STRING(status_code) || status_message. Otherwise, there is no additional authenticated data. This provides that, while not encrypted, the status_code and status_message are authenticated.
===Initial Public Key Retrieval for InvoiceRequest Encryption===
Initial public key retrieval for [[#invoicerequest|InvoiceRequest]] encryption via [[#encryptedprotocolmessage|EncryptedProtocolMessage]] encapsulation can be done in a number of ways including, but not limited to, the following:
Initial public key retrieval for [[#InvoiceRequest|InvoiceRequest]] encryption via [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulation can be done in a number of ways including, but not limited to, the following:
# Wallet Name public key asset type resolution - DNSSEC-validated name resolution returns Base64 encoded DER-formatted EC public key via TXT Record [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
# Key Server lookup - Key Server lookup (similar to PGP's pgp.mit.edu) based on key server identifier (i.e., e-mail address) returns Base64 encoded DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
# QR Code - Use of QR-code to encode SEC-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
@ -387,7 +387,7 @@ Clients SHOULD keep in mind Receivers can broadcast a transaction without return
==Public Key & Signature Encoding==
* All x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded.
* All EC public keys ('''sender_public_key''', '''receiver_public_key''') in any message defined in this BIP MUST be [[SECP256k1|http://www.secg.org/sec2-v2.pdf]] ECDSA Public Key ECPoints encoded using [[SEC 2.3.3 Encoding|http://www.secg.org/sec1-v2.pdf]]. Encoding MAY be compressed.
* All EC public keys ('''sender_public_key''', '''receiver_public_key''') in any message defined in this BIP MUST be [[SECP256k1|http://www.secg.org/sec2-v2.pdf]] ECDSA Public Key ECPoints encoded using [[SEC 2.3.3 Encoding|http://www.secg.org/sec1-v2.pdf]]. Encoding MAY be compressed.
* All ECC signatures included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded.
* All OpenPGP certificates must follow [[https://tools.ietf.org/html/rfc4880|RFC4880]], sections 5.5 and 12.1.
@ -408,12 +408,12 @@ The following flowchart is borrowed from [[bip-0070.mediawiki|BIP70]] and expand
==Mobile to Mobile Examples==
===Full Payment Protocol===
The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use of an InvoiceRequest, a Store & Forward server, PaymentRequest, Payment and PaymentACK. In this case, the PaymentRequest, Payment and PaymentACK messages are encrypted using [[#encryptedprotocolmessage|EncryptedProtocolMessage]] '''and''' the Receiver submits the transaction to the Bitcoin network.
The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use of an InvoiceRequest, a Store & Forward server, PaymentRequest, Payment and PaymentACK. In this case, the PaymentRequest, Payment and PaymentACK messages are encrypted using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] '''and''' the Receiver submits the transaction to the Bitcoin network.
<img src="bip-0075/mobile-sf-ir-with-payment.png" alt="Payment Required flow diagram">
===Encrypting Initial InvoiceRequest via EncryptedProtocolMessage===
The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client using an [[#encryptedprotocolmessage|EncryptedProtocolMessage]] to transmit the InvoiceRequest using encryption, Store & Forward server, and PaymentRequest. In this case, all Payment Protocol messages are encrypting using [[#encryptedprotocolmessage|EncryptedProtocolMessage]] '''and''' the Sender submits the transaction to the Bitcoin network.
The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client using an [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] to transmit the InvoiceRequest using encryption, Store & Forward server, and PaymentRequest. In this case, all Payment Protocol messages are encrypting using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] '''and''' the Sender submits the transaction to the Bitcoin network.
<img src="bip-0075/mobile-sf-encrypted-ir-without-payment.png" alt="Encrypted InvoiceRequest without payment">

4
bip-0075/paymentrequest.proto
View File

@ -2,8 +2,8 @@
// Simple Bitcoin Payment Protocol messages
//
// Use fields 1000+ for extensions;
// to avoid conflicts, register extensions via pull request to update
// https://github.com/bitcoin/bips/blob/master/bip-0070/extensions.mediawiki
// to avoid conflicts, register extensions via pull-req at
// https://github.com/bitcoin/bips/bip-0070/extensions.mediawiki
//
package payments;

783
bip-0077.md
View File

@ -1,783 +0,0 @@
```
BIP: 77
Layer: Applications
Title: Async Payjoin
Authors: Dan Gould <d@ngould.dev>
Yuval Kogman <nothingmuch@woobling.org>
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0077
Status: Draft
Type: Specification
Assigned: 2023-08-08
License: BSD-2-Clause
Discussion: https://github.com/bitcoin/bips/pull/1483
https://gnusha.org/pi/bitcoindev/7B11AE34-27A7-46ED-95BF-66CA13BA26F3@ngould.dev/#t
https://gnusha.org/pi/bitcoindev/3C0A6E4C-444E-4E75-829C-1A21D8EE40E0@ngould.dev/#t
Version: 0.2.0
Requires: 21, 78, 173, 174
```
## Copyright
This BIP is licensed under the 2-clause BSD license.
## Abstract
Payjoin lets Bitcoin senders and receivers interact to make batched
transactions.
This document proposes a second, backwards-compatible, asynchronous version of
the Payjoin protocol ("Version 2") relative to and described in [BIP 78](bip-0078.mediawiki) ("Version 1"). An untrusted
third-party "directory server" replaces the requirement
for a receiver to host a secure public endpoint for interactions. HTTP clients
access the directory server using an asynchronous protocol and authenticated,
encrypted payloads. The design preserves complete Payjoin receiver
functionality, including payment
output substitution. Authenticated encryption depends only on cryptographic
primitives available in Bitcoin Core. Requests use [Oblivious
HTTP](https://www.ietf.org/rfc/rfc9458.html) (OHTTP) to
prevent the directory and other Payjoin clients from linking requests to client
IP addresses.
## Motivation
Satoshi Nakamoto pointed out one specific privacy risk in the
[whitepaper](https://bitcoin.org/en/bitcoin-paper),
that transactions with multiple inputs "necessarily reveal that
their inputs were owned by the same owner."
Payjoin addresses that risk, the _common-input-ownership heuristic_,
by making it practical to spend inputs owned by multiple parties
in one transaction.
While addressing Bitcoin's primal privacy risk, Payjoin *input* batching
also improves on the widespread non-interactive *output* batching practice
deployed by exchanges. When combined, the same movement of funds can use
less block weight and save fees.
A natural application of Payjoin would be to combine
getting paid with consolidating UTXOs into one transaction. But Payjoin
can also secure [transaction
cut-through](https://bitcointalk.org/index.php?topic=281848.0),
allowing a sender to transfer funds to a receiver who also transfers
funds to a third party in the same transaction. For example, deposits to an
exchange may "cut through" in a single transaction that also satisfies
withdrawals instead of with a second transaction that spends the deposited
funds. Payjoin enables more blockspace-efficient transactions that
reduce fees while addressing privacy risks.
However, BIP 78's requirements for Payjoin Version 1 have proven to be an
obstacle to adoption. Version 1 receivers must host a secured
public-facing HTTP server. Mobile and web environments limit the ability
to fulfil such a requirement. Version 1 also requires synchronous
communication. Both sender and receiver must be online simultaneously.
Wallet developers [
regard](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018358.html)
these requirements as barriers to Payjoin adoption.
To address these limitations, our goal is to specify a practical
coordination mechanism suitable for widespread implementation. This proposal
leverages mature solutions to common problems, building on established web
standards and proven Bitcoin primitives.
## Overview
A Payjoin *sender* and *receiver* interact so that they may both contribute to a
transaction. In this proposal, they exchange asynchronous end-to-end
encrypted messages by relaying them to a store-and-forward *directory* server
using OHTTP.
Before initiating the protocol, the receiver must secure communications with
the directory by [bootstrapping](#ohttp-bootstrapping).
- The receiver [initiates a Payjoin Session](#session-initiation)
by sharing a [Payjoin URI](#payjoin-uri) that includes the URL of an
ephemeral mailbox hosted on the directory, where it can receive a message
from the sender.
- The sender [posts a message](#sender-original-psbt-messaging)
containing a fully signed fallback transaction, known as the *Original PSBT*,
to the mailbox.
- The receiver gets this message and
[posts a message containing a *Proposal
PSBT*](#receiver-proposal-psbt-messaging)
to the sender's ephemeral mailbox, by updating the Original PSBT with
appropriate inputs and/or outputs.
- The sender gets the Proposal PSBT, [checks it, signs, and
broadcasts](#sender-signing-and-broadcast) the final transaction.
At any point, either party may choose to broadcast the
fallback transaction described by the Original PSBT instead of proceeding.
Because the Original PSBT and Proposal PSBT spend the same input(s) they are
mutually exclusive and only one can be confirmed.
Messages are buffered in the directory, allowing both parties to tolerate
temporary disconnections and resume communication by polling.
### Async Payjoin Directory Mediated Sequence Diagram
```text
+----------+ +------------+ +----------+ +----------+
| Receiver | | Directory | | Sender | | Network |
+----+-----+ +-----+------+ +----+-----+ +----+-----+
| | | |
| Payjoin URI (BIP21), out-of-band | |
+------------------------------------------------>| |
| | | |
| Poll GET: original PSBT (repeat until available) |
+- - - - - - - - - - - ->+ | |
| # POST: original PSBT | |
| #<-----------------------+ |
| 200 OK: original PSBT # | |
|<-----------------------+ | |
| | | |
| | Poll GET: proposal PSBT (repeat until available)
| +<- - - - - - - - - - - -+ |
| POST: proposal PSBT # | |
+-----------------------># | |
| # 200 OK: proposal PSBT | |
| +----------------------->| |
| | | |
| | | Broadcast payjoin |
| | +---------------------->|
| | | |
```
## Specification
### OHTTP Bootstrapping
Before initiating a Payjoin Session a receiver must first discover the
directory's
[OHTTP Key Configuration](https://www.ietf.org/rfc/rfc9458.html#section-3.1),
via an authenticated
bootstrap mechanism. The key configuration contains information to establish
[Hybrid Public Key Encryption](#secp256k1-hybrid-public-key-encryption) (HPKE) in order to secure communications between the client and the directory in
lieu of TLS.
The bootstrap mechanism may vary by implementation but must
follow [OHTTP Consistency
Requirements](https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-key-consistency-01)
and should not reveal a receiver IP address to the directory. Some
examples of suitable mechanisms include getting a key configuration
from a Payjoin URI, a trusted application binary, or fetching using https-in-http
CONNECT method, https-in-WebSocket, Tor, or a VPN.
Directory OHTTP Gateways MUST support [RFC 9540 Key Configuration
Fetching](https://www.rfc-editor.org/rfc/rfc9540.html#name-key-configuration-fetching)
via GET request. RFC 9540 defines the
gateway location as `/.well-known/ohttp-gateway`.
### Session Initiation
A receiver initiates a session by sharing a Payjoin URI. Because a URI
contains sensitive information, such as a receiver address, it should be shared
over a confidential channel.
#### Payjoin URI
Bitcoin URIs ([BIP
21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki)
or [BIP
321](https://github.com/bitcoin/bips/blob/master/bip-0321.mediawiki))
are a standard way to request bitcoin.
A Payjoin URI is a Bitcoin URI that contains a `pj` parameter. The `pj`
parameter value is a URL in both BIP 78 and BIP 77.
Senders that understand Bitcoin URI but don't support Payjoin will just
ignore the `pj` parameter and proceed to typical address-based
transaction flows.
A `req-pj` parameter may be used as a [BIP 21 forwards compatibility `reqparam`](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki#forward-compatibility) instead of
`pj` to signal that Payjoin is required.
The parameter value must be [uppercased and the parameter should be placed last in the URI](#uppercase-url).
Since BIP 78 payloads are neither encrypted nor authenticated,
a directory used for backwards-compatible payloads is known
as an ["unsecured payjoin server" in BIP 78
parlance](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#unsecured-payjoin-server).
Backwards-compatible receivers MUST disable output substitution
by setting `pjos=0` to prevent modification by a malicious directory.
##### Mailbox endpoint
In this proposal the URL in the `pj` parameter value is the mailbox
endpoint URL. Mailboxes are shared HTTP resources hosted by the
directory and serve as OHTTP Target Resources. Clients use these endpoints
to relay encrypted messages. They `POST` messages to and `GET` messages from
mailbox endpoints via OHTTP.
Senders that support BIP 78 but not this proposal may POST messages directly to
mailbox endpoints for [backwards compatibility](#backwards-compatibility).
###### Short ID
A Short ID identifies a mailbox based on its associated public key. The Short
ID is the path component of the mailbox endpoint. One is derived by hashing the
33-byte compressed public key encoding with SHA-256, truncating it to
[8 bytes (64 bits)](#64-bit-short-id-length), and encoding it in
[uppercase](#uppercase-url) using the bech32 character set (like a bech32 string without the HRP, separator and checksum).
##### Receiver fragment parameters
This proposal introduces session-specific parameters which the
receiver shares encoded in the URI.
Instead of defining new Bitcoin URI parameters, the session-specific
parameters are encoded in the [
fragment](https://datatracker.ietf.org/doc/html/rfc3986#section-3.5)
of the mailbox endpoint URL.
The `#` fragment separator character must be [RFC 3986
percent-encoded](https://datatracker.ietf.org/doc/html/rfc3986#section-2.1)
as `%23`, because it separates the
fragment of the mailbox endpoint URL included in the `pj` parameter, not the
fragment of the Bitcoin URI.
These session-specific parameters use a bech32-inspired encoding.
The HRP is used as the parameter key, followed by the '1' separator,
followed by the parameter value encoded using the bech32 character set in
[uppercase](#uppercase-url). No checksum is used. Parameters are separated
by a `-` character.
The following parameters are defined, and must be provided in lexicographical
order:
- `EX`: specifies a [session
expiration](#session-expiration) in [unix
time](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16).
- `OH`: encodes an alternate format of the OHTTP Key Configuration of
the directory. It consists of a 33-byte compressed public key of the
directory's OHTTP Gateway, prefixed by the 2-byte Key Identifier. A [
RFC 9458 Key
Configuration](https://www.ietf.org/rfc/rfc9458.html#section-3.1)
is reconstructed by assuming the HPKE KEM ID and Symmetric Algorithms
are [fixed](#secp256k1-hybrid-public-key-encryption).
- `RK`: encodes the *receiver key* as a 33-byte compressed public key.
Senders will initiate HPKE with the receiver using this key.
For example, a properly encoded endpoint Bitcoin URI looks like this
`bitcoin:tb1q6q6de88mj8qkg0q5lupmpfexwnqjsr4d2gvx2p?amount=0.00666666&pjos=0&pj=HTTPS://PAYJO.IN/TXJCGKTKXLUUZ%23EX1WKV8CEC-OH1QYPM59NK2LXXS4890SUAXXYT25Z2VAPHP0X7YEYCJXGWAG6UG9ZU6NQ-RK1Q0DJS3VVDXWQQTLQ8022QGXSX7ML9PHZ6EDSF6AKEWQG758JPS2EV`
Until 2026 implementations SHOULD also accept `+` as a fragment parameter
separator and not enforce parameter ordering requirements, for compatibility
with the [previous version of this document](#changelog).
### Sender Original PSBT Messaging
The sender constructs the fallback transaction, a typical transaction
spending funds to the receiver's address specified in the Payjoin URI.
This transaction is serialized as a BIP 174 PSBTv0, satisfying
[the receiver checklist](#receivers-original-psbt-checklist).
The Original PSBT MUST:
- Include complete UTXO data.
- Be fully signed.
- Exclude unnecessary fields such as global xpubs or keypath
information.
- Be broadcastable.
The Original PSBT MAY:
- Include outputs unrelated to the sender-receiver transfer for batching
purposes.
This *Original PSBT* is encoded as base64, followed by the query
parameter string on a new line containing [optional sender
parameters](#optional-sender-parameters).
The sender generates an ephemeral mailbox key. The corresponding public key is
known as the *reply key*, and it is prepended to the base64 plaintext string,
serialized in compressed form as 33 bytes.
This plaintext string is encrypted to the receiver key according to [HPKE Base
mode](https://www.rfc-editor.org/rfc/rfc9180.html#name-encryption-to-a-public-key).
The HPKE `info` string, used for domain separation, is `PjV2MsgA`. The
ciphertext ensures message secrecy and integrity when passed to the receiver
using the mailbox endpoint. The 16-byte authentication tag is appended to the
ciphertext.
RFC 9180 [does not
specify](https://www.rfc-editor.org/rfc/rfc9180.html#section-10) the wire format
encoding of HPKE messages. To construct an HPKE payload, the secp256k1 public
key from the DHKEM is encoded using ElligatorSwift in 64 bytes. Note that
ElligatorSwift is only the wire format; when deriving shared secrets, the curve
point is re-serialized in uncompressed form.
```
PjV2MsgA Byte Representation (7168 bytes total)
+---------------------------------------------------------------------------------------+
| ElligatorSwift | Ciphertext |
| (64 bytes) | (7104 bytes) |
| +-----------------------+---------------------------------+------------+
| | Reply Key | Padded Plaintext | AEAD Tag |
| | (33 bytes) | (7055 bytes = 7168-64-33-16) | (16 bytes) |
+---------------------------------------------------------------------------------------+
```
The resulting HPKE payload is the body of a POST request to the
receiver's mailbox. This request is then [
encapsulated](#clientdirectory-interactions) according to
Oblivious HTTP to the directory's OHTTP Gateway. OHTTP serializes the
inner request as BHTTP, and provides another layer of HPKE encryption,
between the client and directory.
Upon receipt, the directory's OHTTP Gateway decapsulates the OHTTP
request and handles the inner POST request at the receiver's mailbox
endpoint, which stores the HPKE encrypted payload to be forwarded to the
receiver.
The sender then polls OHTTP encapsulated GET requests to the sender's
mailbox endpoint until it receives a response from the directory
containing the receiver's *Proposal PSBT*, and proceeds to
[sign and broadcast](#sender-signing-and-broadcast).
It stops polling after expiration.
#### Optional sender parameters
[BIP 78's optional sender parameters](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#optional-parameters)
may be used in this proposal, but must be included in
the body as part of the ciphertext rather than as a query string.
HPKE binds ciphertexts to application-specific `info` strings. Because
of this domain separation, BIP 78's `v` parameter is redundant and
should be omitted for this proposal.
### Receiver Proposal PSBT Messaging
After sharing the Payjoin URI with the sender, the receiver polls via
OHTTP encapsulated GET requests to the receiver's mailbox endpoint. So
long as the mailbox contains no message, the directory responds with
status 202 ACCEPTED. Once a mailbox contains a message, the directory
returns it in the response body with status 200 OK.
Upon receiving an encapsulated 200 OK response, the receiver decrypts
the payload and checks the *Original PSBT* therein according to the
[receiver checklist](#receivers-original-psbt-checklist).
The receiver then updates the *Original PSBT* to include new signed
inputs and outputs, invalidating the sender's signature(s). The receiver
may also adjust the transaction fee. The result, called the *Proposal
PSBT*, must satisfy the [sender checklist](#senders-proposal-psbt-checklist)
The Proposal PSBT MUST:
- Include complete UTXO data.
- Include all inputs from the Original PSBT.
- Include all outputs which do not belong to the receiver from the
Original PSBT.
- Use a random index if additional inputs or outputs are added.
The Proposal PSBT sender MAY:
- Add inputs at random indices.
- Add outputs at random indices.
- Remove or modify Original PSBT outputs under the control of the
receiver (i.e. not sender change).
The Proposal PSBT MUST NOT:
- Shuffle the order of inputs or outputs contained in the Original PSBT.
- Decrease the absolute fee of the Original PSBT.
The receiver encrypts the *Proposal PSBT* to the sender's reply key according to
[HPKE Auth
mode](https://www.rfc-editor.org/rfc/rfc9180.html#name-authentication-using-an-asy),
using the receiver's key for authentication. The HPKE `info` string is
`PjV2MsgB`. The HPKE wire format is the same as in the [sender's
message](#sender-original-psbt-messaging).
```
PjV2MsgB Byte Representation (7168 bytes total)
+---------------------------------------------------------------------------------------+
| ElligatorSwift | Ciphertext |
| (64 bytes) | (7104 bytes) |
| +---------------------------------------------------------+------------+
| | Padded Plaintext | AEAD Tag |
| | (7088 bytes = 7168-64-16) | (16 bytes) |
+---------------------------------------------------------------------------------------+
```
The receiver makes the resulting HPKE payload the body of a POST request to the
sender's mailbox whose Short ID is derived from the sender's reply key. This request is then [
encapsulated](#clientdirectory-interactions) according to
Oblivious HTTP to the directory's OHTTP Gateway. OHTTP serializes the
inner request as BHTTP, and provides another layer of HPKE encryption,
between the client and directory.
The above describes the receiver's reply path when the sender used
Version 2. When the sender used the BIP 78 backwards-compatible path
(the Original PSBT was a BIP 78 cleartext payload rather than an
HPKE-encrypted v2 message), the receiver's response MUST instead follow
[Backwards compatibility](#backwards-compatibility): the *Proposal PSBT*
is not HPKE-encrypted and the request method is `PUT`.
Once the receiver makes this request, they wait for either transaction from the
Original PSBT or Proposal PSBT to be broadcast to the Bitcoin network.
#### Receiver's Original PSBT checklist
The receiver checklist is the same as [the BIP 78 receiver
checklist](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-original-psbt-checklist).
### Sender signing and broadcast
The sender validates the *Proposal PSBT* it receives against a
checklist. If the checks pass, it may sign and broadcast the resulting
Payjoin transaction.
#### Sender's Proposal PSBT checklist
This proposal's sender checklist is the same as [the BIP 78 sender
checklist](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#senders-payjoin-proposal-checklist).
### Client/Directory interactions
The Payjoin Directory provides a rendezvous point for senders and
receivers to exchange messages. The directory stores Payjoin payloads to
support asynchronous communication. Async Payjoin requests must be
submitted as encapsulated messages to the directory's OHTTP Gateway.
The wire format OHTTP request is specified in [RFC
9458](https://www.ietf.org/rfc/rfc9458.html#name-hpke-encapsulation). HPKE
requires the directory's OHTTP key configuration. The plaintext is a binary
encoded HTTP request ([RFC 9292](https://www.rfc-editor.org/rfc/rfc9292.html))
intended for the OHTTP target resource, usually a mailbox endpoint, padded to
8104 bytes with [random data](#random-padding).
```
OHTTP Encapsulated Request Byte Representation (8192 bytes total)
+--------------+-------------------------+------------------------------------------+
| OHTTP Header | HPKE KEM | Ciphertext |
| (7 bytes) | Uncompressed Public Key | (8120 bytes = 8192-65-7) +
| | (65 bytes) +-----------------------------+------------+
| | | Padded BHTTP Request | AEAD Tag |
| | | (8104 bytes = 8192-65-16-7) | (16 bytes) |
+--------------+-------------------------+------------------------------------------+
```
Response encryption uses the Export functionality of the request HPKE context to
establish a shared secret, and therefore consists of a 32 byte nonce followed by
the AEAD ciphertext and tag.
```
OHTTP Encapsulated Response Byte Representation (8192 bytes total)
+---------------------+------------------------------------------+
| Nonce | Ciphertext |
| (32 bytes) | (8160 bytes = 8192-32) +
| +-----------------------------+------------+
| | Padded BHTTP Response | AEAD Tag |
| | (8144 bytes = 8192-32-16) | (16 bytes) |
+---------------------+------------------------------------------+
```
GET requests on an empty mailbox should block until a message is posted
or a timeout occurs. The timeout should be 30 seconds because that will
not exceed the default timeout for most HTTP clients.
The directory may optionally accept HTTP/1.1 POST requests without OHTTP
to mailbox endpoint URLs for backwards compatibility with BIP 78 senders.
#### OHTTP Sequence Diagram
```text
.-------------------------------------------.
| Payjoin Directory |
+--------+ +-----------+ | +-------------+ +--------------+ |
| Client | | OHTTP | | | OHTTP | | HTTP | |
| | | Relay | | | Gateway | | Resource | |
+---+----+ +------+----+ | +-----+-------+ +------+-------+ |
| | `--------|-----------------------|----------'
| Relay Request | | |
| [ + Encapsulated | | |
| Request ] | | |
+------------------->| Gateway Request | |
| | [ + Encapsulated | |
| | Request ] | |
| +------------------->| Request |
| | +---------------------->|
| | | |
| | | Response |
| | Gateway |<----------------------+
| | Response | |
| | [ + Encapsulated | |
| | Response ] | |
| Relay |<-------------------+ |
| Response | | |
| [ + Encapsulated | | |
| Response ] | | |
|<-------------------+ | |
| | | |
```
### Relay/Directory interactions
RFC 9458 requires each OHTTP Relay to be configured to forward requests
to exactly one OHTTP Gateway. This requirement prevents receivers from
being able to choose any directory, and senders from choosing relays
independently. Without addressing this limitation, senders would have to
know which relays are appropriate to use for each directory, creating a
tendency for one directory and its affiliated relays to monopolize the
protocol.
In order to allow OHTTP Relays to be used with any directory, a
directory's OHTTP Gateway may advertise this allowed purpose. This
advertisement prevents OHTTP Relays from acting as open internet proxies,
which would otherwise allow anonymized access to arbitrary resources and
expose them to denial-of-service attacks, as well as other forms of abuse.
When the directory receives a GET request to the `/.well-known/ohttp-gateway`
path with an `allowed_purposes` query parameter, its response body
should contain a magic string in the same format as a TLS ALPN protocol
list (a U16BE length encoded list of U8 length encoded strings). The
magic string is `BIP77 454403bb-9f7b-4385-b31f-acd2dae20b7e`, offering
an unambiguous signal to relays that this OHTTP Gateway will accept
requests associated with this purpose from any relay.
By supporting this `allowed_purposes` parameter, the directory signals
to OHTTP Relays that it is willing to handle requests related to BIP 77,
removing the RFC 9458's requirement that relays and
Gateways be configured in a one-to-one relationship.
## Rationale
### Uppercase URL
In order to simplify parsing and allow QR encoders to use [Alphanumeric
QR
mode](https://www.rfc-editor.org/rfc/rfc9285.html#name-the-alphabet-used-in-base45),
which is more compact than Byte mode, the mailbox endpoint URL,
including the fragment parameters, is encoded in uppercase.
Unlike Bitcoin URI parameters, which require switching back to Byte
mode, the use of the URL fragment for session-specific parameters makes
it possible to stay in Alphanumeric mode.
### Parameter Ordering
The order of fragment parameters, Bitcoin URI parameters, as well as in the
sender's optional parameters have no defined meaning.
In the BIP 21 URI, the `pj` parameter mailbox endpoint URL SHOULD be the last
parameter to avoid QR mode switching.
Since variations might create a fingerprint for particular wallet software,
this document requires that fragment parameters MUST appear in reverse
lexicographical order.
### Session Expiration
The directory may hold a message for an offline Payjoin client until that
client comes online. However, the BIP 78 spec [
recommends](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receiver-does-not-need-to-be-a-full-node)
broadcasting Original PSBTs in the case of an offline counterparty.
Doing so exposes a naïve, surveillance-vulnerable transaction, which
Payjoin intends to avoid.
Because BIP 78 is a synchronous protocol without a standard expiration
mechanism, and automated receivers are vulnerable to probing attacks,
BIP 78 encourages receivers to broadcast the Original PSBT after some
undefined expiration time.
Because BIP 77 is an asynchronous protocol, it requires an explicit [
session-specific fragment
parameter](#receiver-fragment-parameters), `EX`, to
communicate this expiration time to the sender.
There is no way for a sender to prevent a receiver from broadcasting the
fallback transaction extracted from the Original PSBT before the
receiver-specified expiration time.
### 64-bit Short ID Length
64 bits are sufficient to make the probability of experiencing a random
collision negligible. As of writing, the UTXO set has ~2^28 elements.
This is a very loose upper bound for the number of concurrent (non-spam)
sessions, for which the probability of a random collision will be less
than 1%. The actual number of sessions will of course be (orders of
magnitudes) lower given that sessions are short-lived. With ~2^21
sessions (a loose bound on number of transactions that can be confirmed
in 24 hours) the probability is less than 1e-6. These figures bound the
probability of a collision existing anywhere in the entire set, whereas
the probability for an individual session to experience a collision is
\<\< 1e-10 in either case.
### Complete UTXO Data
Complete UTXO data is required because this information is required for
signing and calculating fees for some input types.
### HTTP
HTTP is ubiquitous. Using simple HTTP polling allows even Bitcoin Core
to consider an implementation. Unlike a WebSockets protocol, plain HTTP
can benefit from metadata protection by using Oblivious HTTP.
### Oblivious HTTP
OHTTP protects sender and receiver IP addresses both from one another
and from the directory. This makes it more difficult for a directory to
correlate many Payjoin transactions with specific IP addresses.
OHTTP relays can be run as basic HTTP proxies from wallet providers or
third parties.
### Uniform Payloads
Encapsulated OHTTP payloads seen by the relay and directory, and
encrypted messages seen by the directory, are constructed to be uniform
so that these third-party services are unable to distinguish between
them.
Encapsulated OHTTP messages are 8192 bytes long, and begin with a
cleartext OHTTP header and an uncompressed key which is distinguishable
from random bytes but uniform across different encapsulated requests.
End-to-end encrypted messages are 7168 bytes long, and should be
indistinguishable from uniformly random bytes.
[ElligatorSwift as defined in BIP 324](https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki#elligatorswift-encoding-of-curve-x-coordinates)
is used to encode encapsulated HPKE public keys prepended to the HPKE ciphertext
so that the directory can't distinguish between key material, the
ciphertext, and randomness. This ensures the two different protocol
messages are indistinguishable from each other as well as any protocol
extensions.
These padded sizes are sufficient for most PSBTs without exceeding the [
8KB
limit](https://www.geekersdigest.com/max-http-request-header-size-server-comparison/)
of many HTTP/1.1 web servers. 8KB is also too small for image sharing,
making misuse of the directory impractical.
#### Random Padding
The typical [zero padding recommended by the BHTTP
specification](https://www.rfc-editor.org/rfc/rfc9292.html#name-padding-and-truncation)
would make future use of [multi-hop OHTTP inspired by the Sphinx mix
format](https://github.com/orgs/payjoin/discussions/582) detectable from the
point of view of the directory. Random padding is allowed so long as the BHTTP
encoded request is not truncated.
By randomly padding OHTTP messages, any future use of such techniques would be
indistinguishable from clients that only implement standardized OHTTP. Since
this would limit a malicious directory's ability to censor any such requests in
the future, and such requests significantly bolster the privacy threat model
against malicious OHTTP relays or traffic analysis by a global passive
adversary, it is desirable to do so for standard OHTTP requests as well.
### Secp256k1 Hybrid Public Key Encryption
[RFC 9180 Hybrid Public Key
Encryption](https://www.rfc-editor.org/rfc/rfc9180.html)
(HPKE) is a modern IETF standard for secure
message exchange without TLS, since TLS is not available in Bitcoin Core.
This proposal uses `DHKEM(Secp256k1, HKDF-SHA256)` and
`ChaCha20Poly1305` AEAD for both OHTTP encapsulation and for end-to-end
encryption between the sender and receiver.
The receiver transmits its receiver key in [receiver fragment
parameters](#receiver-fragment-parameters). The sender shares
its reply key along with the Original PSBT. These keys are ephemeral and
must only be used for a single Payjoin Session.
#### Secp256k1-based DHKEM
[Secp256k1-based DHKEM for
HPKE](https://www.ietf.org/archive/id/draft-wahby-cfrg-hpke-kem-secp256k1-01.html)
is most appropriate because of secp256k1's availability in bitcoin
contexts.
#### ChaCha20Poly1305 AEAD
This authenticated encryption with additional data [
algorithm](https://en.wikipedia.org/wiki/ChaCha20-Poly1305)
is standardized in [RFC
8439](https://www.rfc-editor.org/rfc/rfc8439) and has high
performance. ChaCha20Poly1305 AEAD has been implemented [in Bitcoin
Core](https://github.com/bitcoin/bitcoin/pull/15649) for [
BIP 324 Encrypted
Transport](https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki)
as well. This has widespread support in browsers and common
cryptographic libraries. AES-GCM is more widespread but slower without
hardware support and not typically already a dependency in bitcoin software.
#### HKDF-SHA256
SHA-256 is necessarily available in bitcoin contexts.
## Attack vectors
In addition to the attack vectors and mitigations in
[BIP 78](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#attack-vectors),
this proposal has the following attack vectors.
### Directory Denial of Service
Since each mailbox stores arbitrary encrypted payloads, directories are
vulnerable to flooding. To mitigate such denial of service attacks,
directory operators may respond with `401` unauthorized unless an
authorization token is provided. Authorization tokens must be unlinkable
to preserve client privacy. A specific unlinkable authorization token
mechanism is out of the scope of this proposal.
### Network privacy
Oblivious HTTP must be used to protect the IP addresses of both sender
and receiver from the directory. This requires an OHTTP Key
Configuration to be shared in the Payjoin URI and for the directory to
support Oblivious HTTP.
Unlike BIP 78 implementations, sender and receiver clients will only see
the IP address of the directory and not that of the client they are
interacting with.
Senders that submit requests directly to the directory, without using
an OHTTP Relay, may reveal their IP address to the receiver since that
receiver also specifies the directory.
## Backwards compatibility
Senders not supporting Payjoin will just ignore the `pj` parameter and
proceed to typical address-based transaction flows.
All Payjoin versions use [Bitcoin URIs](#payjoin-uri).
Receivers may choose to accept BIP 78 payloads at their discretion.
A BIP 78 sender posts their request to the directory, which stores
and forwards it to the BIP 77 receiver. A backwards-compatible
receiver proceeds with the BIP 78 checks if the encapsulated response
body is UTF-8 plaintext, signifying BIP 78. In order to service the
request, a BIP 78 response must be returned to the sender within 30
seconds or else the directory should respond with an `unavailable` JSON
error code as [defined in BIP
78](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-well-known-errors).
When responding to a BIP 78 sender, the receiver MUST NOT HPKE-encrypt
the *Proposal PSBT*. The receiver MUST send the *Proposal PSBT* as the
body of a PUT request, with the body being the base64-encoded PSBT,
encoded as ASCII bytes. The target mailbox endpoint MUST be the
receiver's own mailbox (the same mailbox at which the sender posted the
*Original PSBT*), because a BIP 78 sender provides no reply key from which
a sender-side reply mailbox could be derived. The PUT request is then
OHTTP-encapsulated to the directory's OHTTP Gateway as for any other
Payjoin Directory interaction.
## Reference implementation
A production reference implementation client can be found at
<https://crates.io/crates/payjoin-cli>. Source code for the clients, the
directory, and development kit may be found here:
<https://github.com/payjoin/rust-payjoin>. Source code for an Oblivious
HTTP relay implementation may be found here:
<https://github.com/payjoin/ohttp-relay>.
## Changelog
- 0.2.0 2025-07-08
- Change fragment parameter delimiter from `+` to `-` to improve
compatibility with generic URI parsing libraries, and order them
lexicographically. `+` can cause issues due to a common convention (not
specified in RFC 3986, but in RFC 1866, in relation to HTML form
submission and query parameters) of interpreting `+` as ` ` when decoding
URIs.
- 0.1.0 2025-05-28
- First merged Draft version of BIP 77

647
bip-0078.mediawiki
View File

@ -1,647 +0,0 @@
<pre>
BIP: 78
Layer: Applications
Title: A Simple Payjoin Proposal
Authors: Nicolas Dorier <nicolas.dorier@gmail.com>
Status: Deployed
Type: Specification
Assigned: 2019-05-01
License: BSD-2-Clause
Replaces: 79
</pre>
==Introduction==
===Abstract===
This document proposes a protocol for two parties
to negotiate a coinjoin transaction during a payment between them.
===Copyright===
This BIP is licensed under the 2-clause BSD license.
===Motivation===
When two parties (later referred to as sender and receiver) want to transact,
most of the time, the sender creates a transaction spending their own Unspent Transaction Outputs (UTXOs), signs
it and broadcasts it on the network.
This simple model gave birth to several heuristics impacting the privacy of the parties and of the network as a whole.
* Common input ownership heuristic: In most transactions, all the inputs belong to the same party.
* Change identification from scriptPubKey type: If all inputs are spending UTXOs of a certain scriptPubKey type, then the change output is likely to have the same scriptPubKey type, too.
* Change identification from round amount: If an output in the transaction has a round amount, it is likely an output belonging to the receiver.
We will designate these three heuristics as <code>common-input</code>, <code>change-scriptpubkey</code>, <code>change-round-amount</code>.
The problems we aim to solve are:
* For the receiver, there is a missed opportunity to consolidate their own UTXOs or making payment in the sender's transaction.
* For the sender, there are privacy leaks regarding their wallet that happen when someone applies the heuristics detailed above to their transaction.
Our proposal gives an opportunity for the receiver to consolidate their UTXOs while also batching their own payments, without creating a new transaction. (Saving fees in the process)
For the sender, it allows them to invalidate the three heuristics above. With the receiver's involvement, the heuristics can even be poisoned. (ie, using the heuristics to intentionally mislead blockchain analysis)
Note that the existence of this proposal is also improving the privacy of parties who are not using it by making the three heuristics unreliable to the network as a whole.
=== Relation to BIP79 (Bustapay) ===
Another implementation proposal has been written: [[https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki|BIP79 Bustapay]].
We decided to deviate from it for several reasons:
* It was not using PSBT, so if the receiver wanted to bump the fee, they would need the full UTXO set.
* Inability to change the payment output to match scriptPubKey type.
* Lack of basic versioning negotiation if the protocol evolves.
* No standardization of error condition for proper feedback to the sender.
Other than that, our proposal is very similar.
==Specification==
===Protocol===
In a payjoin payment, the following steps happen:
* The receiver of the payment, presents a [[bip-0021.mediawiki|BIP 21 URI]] to the sender with a parameter <code>pj=</code> describing a payjoin endpoint.
* The sender creates a signed, finalized PSBT with witness UTXO or previous transactions of the inputs. We call this PSBT the <code>original</code>.
* The receiver replies back with a signed PSBT containing his own signed inputs/outputs and those of the sender. We call this PSBT <code>Payjoin proposal</code>.
* The sender verifies the proposal, re-signs his inputs and broadcasts the transaction to the Bitcoin network. We call this transaction <code>Payjoin transaction</code>.
<pre>
+----------+ +--------+ +-----------------+
| Receiver | | Sender | | Bitcoin Network |
+----+-----+ +---+----+ +-------+---------+
| +-----------------+ | |
+-------+ BIP21 with ?pj= +------->+ |
| +-----------------+ | |
| | |
| +---------------+ | |
+<-------+ Original PSBT +---------+ |
| +---------------+ | |
| | |
| +------------------+ | |
| | Payjoin Proposal | | |
+-------+ PSBT +------>+ |
| +------------------+ | |
| | +--------------+ |
| |---+ Payjoin | |
| | | transaction +-->+
| | +--------------+ |
+ + +
</pre>
The original PSBT is sent in the HTTP POST request body, base64 serialized, with <code>text/plain</code> in the <code>Content-Type</code> HTTP header and <code>Content-Length</code> set correctly.
The payjoin proposal PSBT is sent in the HTTP response body, base64 serialized with HTTP code 200.
To ensure compatibility with web-wallets and browser-based-tools, all responses (including errors) must contain the HTTP header <code>Access-Control-Allow-Origin: *</code>.
The sender must ensure that the URL refers to a scheme or protocol using authenticated encryption, for example TLS with certificate validation, or a .onion link to a hidden service whose public key identifier has already been communicated via a TLS connection. Senders SHOULD NOT accept a URL representing an unencrypted or unauthenticated connection.
The original PSBT MUST:
* Have all the <code>witnessUTXO</code> or <code>nonWitnessUTXO</code> information filled in.
* Be finalized.
* Not include fields unneeded for the receiver such as global xpubs or keypath information.
* Be broadcastable.
The original PSBT MAY:
* Have outputs unrelated to the payment for batching purpose.
The original PSBT SHOULD NOT:
* Include mixed input types until September 2024. Mixed inputs were previously completely disallowed so this gives some grace period for receivers to update.
The payjoin proposal MUST:
* Use all the inputs from the original PSBT.
* Use all the outputs which do not belong to the receiver from the original PSBT.
* Only finalize the inputs added by the receiver. (Referred later as <code>additional inputs</code>)
* Only fill the <code>witnessUTXO</code> or <code>nonWitnessUTXO</code> for the additional inputs.
The payjoin proposal MAY:
* Add, or replace the outputs belonging to the receiver unless output substitution is disabled.
The payjoin proposal SHOULD NOT:
* Include mixed input types until September 2024. Mixed inputs were previously completely disallowed so this gives some grace period for senders to update.
The payjoin proposal MUST NOT:
* Shuffle the order of inputs or outputs, the additional outputs or additional inputs must be inserted at a random index.
* Decrease the absolute fee of the original transaction.
===BIP21 payjoin parameters===
This proposal is defining the following new [[bip-0021.mediawiki|BIP 21 URI]] parameters:
* <code>pj=</code>: Represents an http(s) endpoint which the sender can POST the original PSBT.
* <code>pjos=0</code>: Signal to the sender that they MUST disallow [[#output-substitution|payment output substitution]]. (See [[#unsecured-payjoin|Unsecured payjoin server]])
Note: the <code>amount</code> parameter is *not* required.
===<span id="optional-params"></span>Optional parameters===
When the payjoin sender posts the original PSBT to the receiver, he can optionally specify the following HTTP query string parameters:
* <code>v=</code>, the version number of the payjoin protocol that the sender is using. The current version is <code>1</code>.
This can be used in the future so the receiver can reject a payjoin if the sender is using a version which is not supported via an error HTTP 400, <code>version-unsupported</code>.
If not specified, the receiver will assume the sender is <code>v=1</code>.
If the receiver does not support the version of the sender, they should send an error with the list of supported versions:
<pre>
{
"errorCode": "version-unsupported",
"supported" : [ 2, 3, 4 ],
"message": "The version is not supported anymore"
}
</pre>
* <code>additionalfeeoutputindex=</code>, if the sender is willing to pay for increased fee, this indicate output can have its value subtracted to pay for it.
If the <code>additionalfeeoutputindex</code> 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.
* <code>maxadditionalfeecontribution=</code>, if the sender is willing to pay for increased fee, an integer defining the maximum amount in satoshis that the sender is willing to contribute towards fees for the additional inputs. <code>maxadditionalfeecontribution</code> must be ignored if set to less than zero. See [[#fee-output|fee output]] for more information.
Note that both <code>maxadditionalfeecontribution=</code> and <code>additionalfeeoutputindex=</code> must be specified and valid for the receiver to be allowed to decrease an output belonging to the sender.
This fee contribution can't be used to pay for anything else than additional input's weight.
* <code>minfeerate=</code>, a decimal in satoshi per vbyte that the sender can use to constraint the receiver to not drop the minimum fee rate too much.
* <code>disableoutputsubstitution=</code>, a boolean indicating if the sender forbids the receiver to substitute the receiver's output, see [[#output-substitution|payment output substitution]]. (default to <code>false</code>)
===Receiver's well known errors===
If for some reason the receiver is unable to create a payjoin proposal, it will reply with a HTTP code different than 200.
The receiver is not constrained to specific set of errors, some are specified in this proposal.
The errors have the following format:
<pre>
{
"errorCode": "leaking-data",
"message": "Key path information or GlobalXPubs should not be included in the original PSBT."
}
</pre>
The well-known error codes are:
{| class="wikitable"
!Error code
!Meaning
|-
|unavailable
|The payjoin endpoint is not available for now.
|-
|not-enough-money
|The receiver added some inputs but could not bump the fee of the payjoin proposal.
|-
|version-unsupported
|This version of payjoin is not supported.
|-
|original-psbt-rejected
|The receiver rejected the original PSBT.
|}
The receiver is allowed to return implementation-specific errors which may assist the sender to diagnose any issue.
However, it is important that error codes that are not well-known and that the message do not appear on the sender's software user interface.
Such error codes or messages could be used maliciously to phish a non-technical user.
Instead those errors or messages can only appear in debug logs.
It is advised to hard code the description of the well known error codes into the sender's software.
===<span id="fee-output"></span>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]] <code>additionalfeeoutputindex=</code> and <code>maxadditionalfeecontribution=</code> to indicate which output and how much the receiver can subtract fee.
There are several cases where a fee output is useful:
* The sender's original transaction's fee rate is at the minimum accepted by the network, aka <code>minimum relay transaction fee rate</code>, which is typically 1 satoshi per vbyte.
In such case, the receiver will need to increase the fee of the transaction after adding his own inputs to not drop below the minimum relay transaction fee rate.
* The sender's wallet software is using round fee rate.
If the sender's fee rate is always round, then a blockchain analyst can easily spot the transactions of the sender involving payjoin by checking if, when removing a single input to the suspected payjoin transaction, the resulting fee rate is round.
To prevent this, the sender can agree to pay more fee so the receiver make sure that the payjoin transaction fee is also round.
* The sender's transaction is time sensitive.
When a sender picks a specific fee rate, the sender expects the transaction to be confirmed after a specific amount of time. But if the receiver adds an input without bumping the fee of the transaction, the payjoin transaction fee rate will be lower, and thus, longer to confirm.
Our recommendation for <code>maxadditionalfeecontribution=</code> is <code>originalPSBTFeeRate * 110</code>.
===Receiver's original PSBT checklist===
The receiver needs to do some check on the original PSBT before proceeding:
* Non-interactive receivers (like a payment processor) need to check that the original PSBT is broadcastable. <code>*</code>
* If the sender included inputs in the original PSBT owned by the receiver, the receiver must either return error <code>original-psbt-rejected</code> or make sure they do not sign those inputs in the payjoin proposal.
* Make sure that the inputs included in the original transaction have never been seen before.
** This prevents [[#probing-attack|probing attacks]].
** This prevents reentrant payjoin, where a sender attempts to use payjoin transaction as a new original transaction for a new payjoin.
<code>*</code>: Interactive receivers are not required to validate the original PSBT because they are not exposed to [[#probing-attack|probing attacks]].
===Sender's payjoin proposal checklist===
The sender should check the payjoin proposal before signing it to prevent a malicious receiver from stealing money.
* Verify that the absolute fee of the payjoin proposal is equals or higher than the original PSBT.
* If the receiver's BIP21 signalled <code>pjos=0</code>, disable payment output substitution.
* Verify that the transaction version, and the nLockTime are unchanged.
* Check that the sender's inputs' sequence numbers are unchanged.
* For each input in the proposal:
** Verify that no keypaths are in the PSBT input
** Verify that no partial signature has been filled
** If it is one of the sender's inputs:
*** Verify that input's sequence is unchanged.
*** Verify the PSBT input is not finalized
** If it is one of the receiver's inputs:
*** Verify the PSBT input is finalized
*** Verify that <code>non_witness_utxo</code> or <code>witness_utxo</code> are filled in.
** Verify that the payjoin proposal inputs all specify the same sequence value.
** Verify that all of sender's inputs from the original PSBT are in the proposal.
* For each output in the proposal:
** Verify that no keypaths are in the PSBT output
** If the output is the [[#fee-output|fee output]]:
*** The amount that was subtracted from the output's value is less than or equal to <code>maxadditionalfeecontribution</code>. Let's call this amount <code>actual contribution</code>.
*** Make sure the actual contribution is only going towards fees: The <code>actual contribution</code> is less than or equals to the difference of absolute fee between the payjoin proposal and the original PSBT.
*** Make sure the actual contribution is only paying for fees incurred by additional inputs: <code>actual contribution</code> is less than or equal to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs))</code>. (see [[#fee-output|Fee output]] section)
** If the output is the payment output and payment output substitution is allowed,
*** Do not make any check
** Else
*** Make sure the output's value did not decrease.
** Verify that all sender's outputs (ie, all outputs except the output actually paid to the receiver) from the original PSBT are in the proposal.
* Once the proposal is signed, if <code>minfeerate</code> was specified, check that the fee rate of the payjoin transaction is not less than this value.
The sender must be careful to only sign the inputs that were present in the original PSBT and nothing else.
Note:
* The sender must allow the receiver to add/remove or modify the receiver's own outputs. (if payment output substitution is disabled, the receiver's outputs must not be removed or decreased in value)
* The sender should allow the receiver to not add any inputs. This is useful for the receiver to change the payment output scriptPubKey type.
* If the receiver added no inputs, the sender's wallet implementation should accept the payjoin proposal, but not mark the transaction as an actual payjoin in the user interface.
Our method of checking the fee allows the receiver and the sender to batch payments in the payjoin transaction.
It also allows the receiver to pay the fee for batching adding his own outputs.
==Rationale==
There are several consequences of our proposal:
* The receiver can bump the fee of the original transaction.
* The receiver can modify the outputs of the original PSBT.
* The sender must provide the UTXO information (Witness or previous transaction) in the PSBT.
===Respecting the minimum relay fee policy===
To be properly relayed, a Bitcoin transaction needs to pay at least 1 satoshi per virtual byte.
When blocks are not full, the original transaction might already at the minimum relay fee rate (currently 1 satoshi per virtual byte), so if the receiver adds their own input, they need to make sure the fee is increased such that the rate does not drop below the minimum relay fee rate.
In such case, the sender must set both <code>maxadditionalfeecontribution=</code> and <code>additionalfeeoutputindex=</code>.
See the [[#fee-output|Fee output]] section for more information.
We also recommend the sender to set <code>minfeerate=</code>, as the sender's node policy might be different from the receiver's policy.
===Defeating heuristics based on the fee calculation===
Most wallets are creating a round fee rate (like 2 sat/b).
If the payjoin transaction's fee was not increased by the added size, then those payjoin transactions could easily be identifiable on the blockchain.
Not only would those transactions stand out by not having a round fee (like 1.87 sat/b), but any suspicion of payjoin could be confirmed by checking if removing one input would create a round fee rate.
In such case, the sender must set both <code>maxadditionalfeecontribution=</code> and <code>additionalfeeoutputindex=</code>.
The recommended value <code>maxadditionalfeecontribution=</code> is explained in the [[#fee-output|Fee output]] section.
We also recommend the sender to set <code>minfeerate=</code>, as the sender's node policy might be different from the receiver's policy.
===Receiver does not need to be a full node===
Because the receiver needs to bump the fee to keep the same fee rate as the original PSBT, it needs the input's UTXO information to know what is the original fee rate. Without PSBT, light wallets like Wasabi Wallet would not be able to receive a payjoin transaction.
The validation (policy and consensus) of the original transaction is optional: a receiver without a full node can decide to create the payjoin transaction and automatically broadcast the original transaction after a timeout of 1 minute, and only verify that it has been propagated in the network.
However, non-interactive receivers (like a payment processor) need to verify the transaction to prevent UTXO probing attacks.
This is not a concern for interactive receivers like Wasabi Wallet, because those receivers can just limit the number of original PSBT proposals of a specific address to one. With such wallets, the attacker has no way to generate new deposit addresses to probe the UTXOs.
===<span id="spare-change"></span>Spare change donation===
Small change inside wallets are detrimental to privacy. Mixers like Wasabi wallet, because of its protocol, eventually generate such [[https://docs.wasabiwallet.io/using-wasabi/ChangeCoins.html#first-round-coinjoin-change|small change]].
A common way to protect your privacy is to donate those spare changes, to deposit them in an exchange or on your favorite merchant's store account. Those kind of transactions can easily be spotted on the blockchain: There is only one output.
However, if you donate via payjoin, it will look like a normal transaction.
On top of this the receiver can poison analysis by randomly faking a round amount of satoshi for the additional output.
===<span id="output-substitution"></span>Payment output substitution===
Unless disallowed by the sender explicitly via <code>disableoutputsubstitution=true</code> or by the BIP21 URL via the query parameter <code>pjos=0</code>, the receiver is free to decrease the amount or change the scriptPubKey output paying to himself.
Note that if payment output substitution is disallowed, the receiver 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.
===<span id="unsecured-payjoin"></span>Unsecured payjoin server===
A receiver might run the payment server (generating the BIP21 invoice) on a different server than the payjoin server, which could be less trusted than the payment server.
In such case, the payment server can signal to the sender, via the BIP21 parameter <code>pjos=0</code>, that they MUST disallow [[#output-substitution|payment output substitution]].
A compromised payjoin server could steal the hot wallet outputs of the receiver, but would not be able to re-route payment to himself.
===Impacted heuristics===
Our proposal of payjoin breaks the following blockchain heuristics:
* Common inputs heuristics.
Because payjoin is mixing the inputs of the sender and receiver, this heuristic becomes unreliable.
* Change identification from scriptPubKey type heuristics
When Alice pays Bob, if Alice is using P2SH but Bob's deposit address is P2WPKH, the heuristic would assume that the P2SH output is the change address of Alice.
This is now however a broken assumption, as the payjoin receiver has the freedom to mislead analytics by purposefully changing the invoice's address in the payjoin transaction.
See [[#output-substitution|payment output substitution]].
* Change identification from round change amount
If Alice pays Bob, she might be tempted to pay him a round amount, like <code>1.23000000 BTC</code>. When this happens, blockchain analysis often identifies the output without the round amount as the change of the transaction.
For this reason, during a [[#spare-change|spare change]] case, the receiver may add an output with a rounded amount randomly.
==Attack vectors==
===<span id="probing-attack"></span>On the receiver side: UTXO probing attack===
When the receiver creates a payjoin proposal, they expose one or more inputs belonging to them.
An attacker could create multiple original transactions in order to learn the UTXOs of the receiver, while not broadcasting the payjoin proposal.
While we cannot prevent this type of attack entirely, we implemented the following mitigations:
* When the receiver detects an original transaction being broadcast, or if the receiver detects that the original transaction has been double spent, then they will reuse the UTXO that was exposed for the next payjoin.
* While the exposed UTXO will be reused in priority to not leak other UTXOs, there is no strong guarantee about it. This prevents the attacker from detecting with certainty the next payjoin of the merchant to another peer.
Note that probing attacks are only a problem for automated payment systems such as BTCPay Server. End-user wallets with payjoin capabilities are not affected, as the attacker can't create multiple invoices to force the receiver to expose their UTXOs.
===On the sender side: Double payment risk for hardware wallets===
For a successful payjoin to happen, the sender needs to sign two transactions double spending each other: The original transaction and the payjoin proposal.
The sender's software wallet can verify that the payjoin proposal is legitimate by the sender's checklist.
However, a hardware wallet can't verify that this is indeed the case. This means that the security guarantee of the hardware wallet is decreased. If the sender's software is compromised, the hardware wallet would sign two valid transactions, thus sending two payments.
Without payjoin, the maximum amount of money that could be lost by a compromised software is equal to one payment (via [[#output-substitution|payment output substitution]]).
Note that the sender can disallow [[#output-substitution|payment output substitution]] by using the optional parameter <code>disableoutputsubstitution=true</code>.
With payjoin, the maximum amount of money that can be lost is equal to two payments.
==<span id="reference-impl"></span>Reference sender's implementation==
Here is pseudo code of a sender implementation.
<code>RequestPayjoin</code> takes the BIP21 URI of the payment, the wallet and the <code>signedPSBT</code>.
The <code>signedPSBT</code> represents a PSBT which has been fully signed, but not yet finalized.
We then prepare <code>originalPSBT</code> from the <code>signedPSBT</code> via the <code>CreateOriginalPSBT</code> function and get back the <code>proposal</code>.
While we verify the <code>proposal</code>, we also import into it information about our own inputs and outputs from the <code>signedPSBT</code>.
At the end of this <code>RequestPayjoin</code>, 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]].
<pre>
public async Task<PSBT> RequestPayjoin(
BIP21Uri bip21,
Wallet wallet,
PSBT signedPSBT,
PayjoinClientParameters optionalParameters)
{
Log("Unfinalized signed PSBT" + signedPSBT);
// Extracting the pj link.
var endpoint = bip21.ExtractPayjointEndpoint();
if (signedPSBT.IsAllFinalized())
throw new InvalidOperationException("The original PSBT should not be finalized.");
PSBTOutput feePSBTOutput = null;
bool allowOutputSubstitution = !optionalParameters.DisableOutputSubstitution;
if (bip21.Parameters.Contains("pjos") && bip21.Parameters["pjos"] == "0")
allowOutputSubstitution = false;
if (optionalParameters.AdditionalFeeOutputIndex != null && optionalParameters.MaxAdditionalFeeContribution != null)
feePSBTOutput = signedPSBT.Outputs[optionalParameters.AdditionalFeeOutputIndex];
Script paymentScriptPubKey = bip21.Address == null ? null : bip21.Address.ScriptPubKey;
decimal originalFee = signedPSBT.GetFee();
PSBT originalPSBT = CreateOriginalPSBT(signedPSBT);
Transaction originalGlobalTx = signedPSBT.GetGlobalTransaction();
TxOut feeOutput = feePSBTOutput == null ? null : originalGlobalTx.Outputs[feePSBTOutput.Index];
var originalInputs = new Queue<(TxIn OriginalTxIn, PSBTInput SignedPSBTInput)>();
for (int i = 0; i < originalGlobalTx.Inputs.Count; i++)
{
originalInputs.Enqueue((originalGlobalTx.Inputs[i], signedPSBT.Inputs[i]));
}
var originalOutputs = new Queue<(TxOut OriginalTxOut, PSBTOutput SignedPSBTOutput)>();
for (int i = 0; i < originalGlobalTx.Outputs.Count; i++)
{
originalOutputs.Enqueue((originalGlobalTx.Outputs[i], signedPSBT.Outputs[i]));
}
// Add the client side query string parameters
endpoint = ApplyOptionalParameters(endpoint, optionalParameters);
Log("original PSBT" + originalPSBT);
PSBT proposal = await SendOriginalTransaction(endpoint, originalPSBT, cancellationToken);
Log("payjoin proposal" + proposal);
// Checking that the PSBT of the receiver is clean
if (proposal.GlobalXPubs.Any())
{
throw new PayjoinSenderException("GlobalXPubs should not be included in the receiver's PSBT");
}
////////////
if (proposal.CheckSanity() is List<PSBTError> errors && errors.Count > 0)
throw new PayjoinSenderException($"The proposal PSBT is not sane ({errors[0]})");
var proposalGlobalTx = proposal.GetGlobalTransaction();
// Verify that the transaction version, and nLockTime are unchanged.
if (proposalGlobalTx.Version != originalGlobalTx.Version)
throw new PayjoinSenderException($"The proposal PSBT changed the transaction version");
if (proposalGlobalTx.LockTime != originalGlobalTx.LockTime)
throw new PayjoinSenderException($"The proposal PSBT changed the nLocktime");
HashSet<Sequence> sequences = new HashSet<Sequence>();
// For each inputs in the proposal:
foreach (PSBTInput proposedPSBTInput in proposal.Inputs)
{
if (proposedPSBTInput.HDKeyPaths.Count != 0)
throw new PayjoinSenderException("The receiver added keypaths to an input");
if (proposedPSBTInput.PartialSigs.Count != 0)
throw new PayjoinSenderException("The receiver added partial signatures to an input");
PSBTInput proposedTxIn = proposalGlobalTx.Inputs.FindIndexedInput(proposedPSBTInput.PrevOut).TxIn;
bool isOurInput = originalInputs.Count > 0 && originalInputs.Peek().OriginalTxIn.PrevOut == proposedPSBTInput.PrevOut;
// If it is one of our input
if (isOurInput)
{
OutPoint inputPrevout = ourPrevouts.Dequeue();
TxIn originalTxin = originalGlobalTx.Inputs.FromOutpoint(inputPrevout);
PSBTInput originalPSBTInput = originalPSBT.Inputs.FromOutpoint(inputPrevout);
// Verify that sequence is unchanged.
if (input.OriginalTxIn.Sequence != proposedTxIn.Sequence)
throw new PayjoinSenderException("The proposedTxIn modified the sequence of one of our inputs")
// Verify the PSBT input is not finalized
if (proposedPSBTInput.IsFinalized())
throw new PayjoinSenderException("The receiver finalized one of our inputs");
sequences.Add(proposedTxIn.Sequence);
// Fill up the info from the original PSBT input so we can sign and get fees.
proposedPSBTInput.NonWitnessUtxo = input.SignedPSBTInput.NonWitnessUtxo;
proposedPSBTInput.WitnessUtxo = input.SignedPSBTInput.WitnessUtxo;
// We fill up information we had on the signed PSBT, so we can sign it.
foreach (var hdKey in input.SignedPSBTInput.HDKeyPaths)
proposedPSBTInput.HDKeyPaths.Add(hdKey.Key, hdKey.Value);
proposedPSBTInput.RedeemScript = signedPSBTInput.RedeemScript;
proposedPSBTInput.RedeemScript = input.SignedPSBTInput.RedeemScript;
}
else
{
// Verify the PSBT input is finalized
if (!proposedPSBTInput.IsFinalized())
throw new PayjoinSenderException("The receiver did not finalized one of their input");
// Verify that non_witness_utxo or witness_utxo are filled in.
if (proposedPSBTInput.NonWitnessUtxo == null && proposedPSBTInput.WitnessUtxo == null)
throw new PayjoinSenderException("The receiver did not specify non_witness_utxo or witness_utxo for one of their inputs");
sequences.Add(proposedTxIn.Sequence);
}
}
// Verify that all of sender's inputs from the original PSBT are in the proposal.
if (originalInputs.Count != 0)
throw new PayjoinSenderException("Some of our inputs are not included in the proposal");
// Verify that the payjoin proposal did not introduced mixed inputs' sequence.
if (sequences.Count != 1)
throw new PayjoinSenderException("Mixed sequence detected in the proposal");
decimal newFee = proposal.GetFee();
decimal additionalFee = newFee - originalFee;
if (additionalFee < 0)
throw new PayjoinSenderException("The receiver decreased absolute fee");
// For each outputs in the proposal:
foreach (PSBTOutput proposedPSBTOutput in proposal.Outputs)
{
// Verify that no keypaths is in the PSBT output
if (proposedPSBTOutput.HDKeyPaths.Count != 0)
throw new PayjoinSenderException("The receiver added keypaths to an output");
if (originalOutputs.Count == 0)
continue;
var originalOutput = originalOutputs.Peek();
bool isOriginalOutput = originalOutput.OriginalTxOut.ScriptPubKey == proposedPSBTOutput.ScriptPubKey;
bool substitutedOutput = !isOriginalOutput &&
allowOutputSubstitution &&
originalOutput.OriginalTxOut.ScriptPubKey == paymentScriptPubKey;
if (isOriginalOutput || substitutedOutput)
{
originalOutputs.Dequeue();
if (originalOutput.OriginalTxOut == feeOutput)
{
var actualContribution = feeOutput.Value - proposedPSBTOutput.Value;
// 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
if (actualContribution > additionalFee)
throw new PayjoinSenderException("The actual contribution is not only paying fee");
// Make sure the actual contribution is only paying for fee incurred by additional inputs
// This assumes an additional input can be up to 110 bytes.
int additionalInputsCount = proposalGlobalTx.Inputs.Count - originalGlobalTx.Inputs.Count;
if (actualContribution > originalFeeRate * 110 * additionalInputsCount)
throw new PayjoinSenderException("The actual contribution is not only paying for additional inputs");
}
else if (allowOutputSubstitution && output.OriginalTxOut.ScriptPubKey == paymentScriptPubKey)
{
// That's the payment output, the receiver may have changed it.
}
else
{
if (originalOutput.OriginalTxOut.Value > proposedPSBTOutput.Value)
throw new PayjoinSenderException("The receiver decreased the value of one of the outputs");
}
// We fill up information we had on the signed PSBT, so we can sign it.
foreach (var hdKey in output.SignedPSBTOutput.HDKeyPaths)
proposedPSBTOutput.HDKeyPaths.Add(hdKey.Key, hdKey.Value);
proposedPSBTOutput.RedeemScript = output.SignedPSBTOutput.RedeemScript;
}
}
// Verify that all of sender's outputs from the original PSBT are in the proposal.
if (originalOutputs.Count != 0)
{
// The payment output may have been substituted
if (!allowOutputSubstitution ||
originalOutputs.Count != 1 ||
originalOutputs.Dequeue().OriginalTxOut.ScriptPubKey != paymentScriptPubKey)
{
throw new PayjoinSenderException("Some of our outputs are not included in the proposal");
}
}
// After signing this proposal, we should check if minfeerate is respected.
Log("payjoin proposal filled with sender's information" + proposal);
return proposal;
}
// Finalize the signedPSBT and remove confidential information
PSBT CreateOriginalPSBT(PSBT signedPSBT)
{
var original = signedPSBT.Clone();
original = original.Finalize();
foreach (var input in original.Inputs)
{
input.HDKeyPaths.Clear();
input.PartialSigs.Clear();
input.Unknown.Clear();
}
foreach (var output in original.Outputs)
{
output.Unknown.Clear();
output.HDKeyPaths.Clear();
}
original.GlobalXPubs.Clear();
return original;
}
</pre>
==<span id="test-vectors"></span>Test vectors==
A successful exchange with:
{| class="wikitable"
!InputScriptType
!Original PSBT Fee rate
!maxadditionalfeecontribution
!additionalfeeoutputindex
|-
|P2SH-P2WPKH
|2 sat/vbyte
|0.00000182
|0
|}
<code>Unfinalized signed PSBT</code>
<pre>cHNidP8BAHMCAAAAAY8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////AtyVuAUAAAAAF6kUHehJ8GnSdBUOOv6ujXLrWmsJRDCHgIQeAAAAAAAXqRR3QJbbz0hnQ8IvQ0fptGn+votneofTAAAAAAEBIKgb1wUAAAAAF6kU3k4ekGHKWRNbA1rV5tR5kEVDVNCHAQQWABTHikVyU1WCjVZYB03VJg1fy2mFMCICAxWawBqg1YdUxLTYt9NJ7R7fzws2K09rVRBnI6KFj4UWRzBEAiB8Q+A6dep+Rz92vhy26lT0AjZn4PRLi8Bf9qoB/CMk0wIgP/Rj2PWZ3gEjUkTlhDRNAQ0gXwTO7t9n+V14pZ6oljUBIgYDFZrAGqDVh1TEtNi300ntHt/PCzYrT2tVEGcjooWPhRYYSFzWUDEAAIABAACAAAAAgAEAAAAAAAAAAAEAFgAURvYaK7pzgo7lhbSl/DeUan2MxRQiAgLKC8FYHmmul/HrXLUcMDCjfuRg/dhEkG8CO26cEC6vfBhIXNZQMQAAgAEAAIAAAACAAQAAAAEAAAAAAA==</pre>
<code>Original PSBT</code>
<pre>cHNidP8BAHMCAAAAAY8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////AtyVuAUAAAAAF6kUHehJ8GnSdBUOOv6ujXLrWmsJRDCHgIQeAAAAAAAXqRR3QJbbz0hnQ8IvQ0fptGn+votneofTAAAAAAEBIKgb1wUAAAAAF6kU3k4ekGHKWRNbA1rV5tR5kEVDVNCHAQcXFgAUx4pFclNVgo1WWAdN1SYNX8tphTABCGsCRzBEAiB8Q+A6dep+Rz92vhy26lT0AjZn4PRLi8Bf9qoB/CMk0wIgP/Rj2PWZ3gEjUkTlhDRNAQ0gXwTO7t9n+V14pZ6oljUBIQMVmsAaoNWHVMS02LfTSe0e388LNitPa1UQZyOihY+FFgABABYAFEb2Giu6c4KO5YW0pfw3lGp9jMUUAAA=</pre>
<code>payjoin proposal</code>
<pre>cHNidP8BAJwCAAAAAo8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////jye60aAl3JgZdaIERvjkeh72VYZuTGH/ps2I4l0IO4MBAAAAAP7///8CJpW4BQAAAAAXqRQd6EnwadJ0FQ46/q6NcutaawlEMIcACT0AAAAAABepFHdAltvPSGdDwi9DR+m0af6+i2d6h9MAAAAAAQEgqBvXBQAAAAAXqRTeTh6QYcpZE1sDWtXm1HmQRUNU0IcAAQEggIQeAAAAAAAXqRTI8sv5ymFHLIjkZNRrNXSEXZHY1YcBBxcWABRfgGZV5ZJMkgTC1RvlOU9L+e2iEAEIawJHMEQCIGe7e0DfJaVPRYEKWxddL2Pr0G37BoKz0lyNa02O2/tWAiB7ZVgBoF4s8MHocYWWmo4Q1cyV2wl7MX0azlqa8NBENAEhAmXWPPW0G3yE3HajBOb7gO7iKzHSmZ0o0w0iONowcV+tAAAA</pre>
<code>payjoin proposal filled with sender's information</code>
<pre>cHNidP8BAJwCAAAAAo8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////jye60aAl3JgZdaIERvjkeh72VYZuTGH/ps2I4l0IO4MBAAAAAP7///8CJpW4BQAAAAAXqRQd6EnwadJ0FQ46/q6NcutaawlEMIcACT0AAAAAABepFHdAltvPSGdDwi9DR+m0af6+i2d6h9MAAAAAAQEgqBvXBQAAAAAXqRTeTh6QYcpZE1sDWtXm1HmQRUNU0IcBBBYAFMeKRXJTVYKNVlgHTdUmDV/LaYUwIgYDFZrAGqDVh1TEtNi300ntHt/PCzYrT2tVEGcjooWPhRYYSFzWUDEAAIABAACAAAAAgAEAAAAAAAAAAAEBIICEHgAAAAAAF6kUyPLL+cphRyyI5GTUazV0hF2R2NWHAQcXFgAUX4BmVeWSTJIEwtUb5TlPS/ntohABCGsCRzBEAiBnu3tA3yWlT0WBClsXXS9j69Bt+waCs9JcjWtNjtv7VgIge2VYAaBeLPDB6HGFlpqOENXMldsJezF9Gs5amvDQRDQBIQJl1jz1tBt8hNx2owTm+4Du4isx0pmdKNMNIjjaMHFfrQABABYAFEb2Giu6c4KO5YW0pfw3lGp9jMUUIgICygvBWB5prpfx61y1HDAwo37kYP3YRJBvAjtunBAur3wYSFzWUDEAAIABAACAAAAAgAEAAAABAAAAAAA=</pre>
==Implementations==
* [[https://github.com/BlueWallet/BlueWallet|BlueWallet]] is in the process of implementing the protocol.
* [[https://github.com/btcpayserver/btcpayserver|BTCPay Server]] has implemented sender and receiver side of this protocol.
* [[https://github.com/zkSNACKs/WalletWasabi/|Wasabi Wallet]] has merged sender's support.
* [[https://github.com/JoinMarket-Org/joinmarket-clientserver|Join Market]] has implemented sender and receiver side of this protocol.
* [[https://github.com/bitcoinjs/payjoin-client|JavaScript sender implementation]].
==Backward compatibility==
The receivers advertise payjoin capabilities through [[bip-0021.mediawiki|BIP21's URI Scheme]].
Senders not supporting payjoin will just ignore the <code>pj</code> variable and thus, will proceed to normal payment.
==Special thanks==
Special thanks to Kukks for developing the initial support to BTCPay Server, to junderw, AdamISZ, lukechilds, ncoelho, nopara73, lontivero, yahiheb, SomberNight, andrewkozlik, instagibbs, RHavar for all the feedback we received since our first implementation.
Thanks again to RHavar who wrote the [[bip-0079.mediawiki|BIP79 Bustapay]] proposal, this gave a good starting point for our proposal.

123
bip-0079.mediawiki
View File

@ -1,123 +0,0 @@
<pre>
BIP: 79
Layer: Applications
Title: Bustapay :: a practical coinjoin protocol
Authors: Ryan Havar <rhavar@protonmail.com>
Status: Closed
Type: Informational
Assigned: 2018-10-05
License: CC0-1.0
Proposed-Replacement: 78
</pre>
==Abstract==
The way bitcoin transactions are normally created leaks more information than desirable, and as a result has been exploited by unreasonably effective blockchain analysis techniques to jeopardize important properties that are expected of a useful currency.
Bustapay is a simple and practical protocol for the sender and receiver of a payment to collaboratively sign a bitcoin transaction in such a way that busts some analysis assumptions to the immediate benefit of the sender and receiver. Furthermore it does so in such a way that gives a significant amount of control to the receiver to help manage their utxo set size, a constant problem for bitcoin merchants.
==Copyright==
This document is licensed under the Creative Commons CC0 1.0 Universal license.
==Motivation==
One of the most powerful blockchain analysis heuristics has been to assume all inputs of a transaction are controlled by a single party unless otherwise known (such as by the distinctive structure of a traditional coinjoin, or multisig spends that are validated onchain). Combined with other techniques (notably change-output guessing) this has lead to unexpectedly accurate tracking that has exposed bitcoin participants to unacceptable personal, business and financial risks -- undermining bitcoin's utility and fungibility -- and ultimately jeopardizing its ability to function as useful money.
We however can bust these assumptions with a sender-receiver coinjoin. To prevent costless spy/DoS attacks, we require the sending party to provide a fully-valid ready-to-propagate transaction to initiate the process, that the receiver can broadcast if the sender never completes the coinjoin thus tying the cost to that of spending a utxo. Most promisingly, bustapay transactions do not have an identifiable structure so any network analysis will be not able to tell if a given transaction is a bustapay transaction or not which erodes the confidence of their entire models, providing positive externalities for the entire bitcoin ecosystem.
Bustapay transactions also do not grow the receiver's count of unspent transaction outputs, and in fact gives the receiver an opportunity to better manage their utxo set, something normally only done when sending payments. Large utxo sets are often problematic and expensive, and frequently requiring privacy-destroying consolidation. Besides busting clustering assumptions, bustapay also provides a layer of obfuscation of send amounts.
It is worth noting that this specification has eschewed complexity and potentially useful extensions on the assumption that simplicity is of the most important to encourage adoption.
==Overview==
A bustapay payment is made from a sender to a receiver.
====Step 1. Sender creates a bitcoin transaction paying the receiver====
This transaction must use segwit for all inputs, and be fully valid and signed. The transaction must be eligible for propagation on the network (but not done so at this stage)
====Step 2. Sender gives the "template transaction" to the receiver====
This is done via an HTTP POST request, sent to a "bustapay url"
====Step 3. Receiver processes the transaction and returns a partially signed coinjoin====
The receiver validates the transaction, and pays himself. The receiver then adds one or more of his own inputs (known as the ''contributed inputs'') and (optionally) increases the output that pays himself (generally by the sum of the ''contributed inputs''). Doing so creates a ''partial transaction'', which the receiver returns to the sender. It is called such as it requires the sender to re-sign his own inputs.
====Step 4. Sender validates, re-signs, and propagates on the bitcoin network====
The sender MUST validate the ''partial transaction'' was changed correctly and non-maliciously (to allow using potentially untrusted communication channels), re-sign its original inputs and propagate the final transaction over the bitcoin network.
====Step 5. Receiver observes the finalized transaction on the bitcoin network====
Once the receiver has seen the finalized transactions on the network (and has enough confirmations) it can process it like a normal payment for the sent amount (as opposed to the amount that it looks like on the network). If the receiver does not see the finalized transaction after a timeout, they will propagate the original "template transaction", which ensures the payment happens and functions a strong anti-DoS mechanism.
== Specification ==
The standard way of letting a sender know where to send a bustapay transaction is done via a bip21 encoded address. The key value "bpu" (short for "BustaPayUrl") should be used. An example of such address would be bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bpu=https://bp.bustabit.com/submit It is highly encouraged that urls are kept short.
When the sender is creating a "template transaction" it is done almost identically to creating a normal send, with the exception that *only* segwit inputs may be used. The sender is also encouraged to use a slightly more aggressive feerate than usual as well as BIP125 (Opt-in Full Replace-by-Fee Signaling), but neither is strictly required.
The template transaction should be sent to the receiver via an HTTP POST to the bustapay url, with a binary encoded body.
The receiver is then responsible for validating the template transaction. If there is a problem with the transaction, or the receiver is generally unhappy with the transaction (e.g. fees are too small) the HTTP response code of 422 should be used and a human-readable string containing information on why which can be directly given to the user.
Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the sender to be aware that the receiver *could* at any time (regardless of which error was given) send this transaction. The client should therefore assume the receiver will, and act accordingly (either retry with adjustments or just propagate the transaction). It is imperative that the sender never finds themselves in a situation where two payments to the sender could be valid.
=== Contributed Input Choice ===
The receiver must add at least one input to the transaction (the "contributed inputs"). If the receiver has no inputs, it should use a 500 internal server error, so the client can send the transaction as per normal (or try again later). Its generally advised to only add a single contributed input, however they are circumstances where adding more than a single input can be useful.
To prevent an attack where a receiver is continually sent variations of the same transaction to enumerate the receiver's utxo set, it is essential that the receiver always returns the same contributed inputs when it's seen the same inputs.
It is strongly preferable that the receiver makes an effort to pick a contributed input of the same type as the other transaction inputs if possible.
=== Output Adjustment ===
After adding inputs to the transaction, the receiver generally will want to adjust the output that pays himself by increasing it by the sum of the contributed input amounts (minus any fees he wants to contribute). However the only strict requirement is that the receiver *must never* remove inputs, and *must not* ever decrease any output amount.
=== Returning the partial transaction ===
The receiver must sign all contributed inputs in the partial transaction. The partial transaction should also remove all witnesses from the original template transaction as they are no longer valid, and need to be recalculated by the sender. The receiver returns the partial transaction as a binary-encoded HTTP response with a status code of 200. To ensure compatibility with web-wallets and browser-based-tools, all responses (including errors) must contain the HTTP header "Access-Control-Allow-Origin: *"
=== Sender Validation ===
The sender *must* do important validation on the partial transaction. They *must* verify:
* All template transaction inputs are in the partial transaction (but perhaps different order) and have the same sequence numbers.
* The partial transaction contains at least one new (and signed) segwit input (owned by the receiver)
* All outputs from the template transaction exist in the partial transaction, except they are allowed to be reordered and have their amounts increased (but *never* decreased)
=== Creating Final Transaction ===
After validating the partial transaction, the sender signs all its inputs to create what is now the final transaction. It is important that the sender is careful to not be tricked by the receiver into signing other inputs it owns. The sender must only sign inputs that existed in the template transaction. If the sender is not careful the receiver may "contribute" inputs that are actually owned by the sender, with the hope the sender blindly signs everything.
=== Transaction Publishing ===
Once the final transaction is created, the sender should publish it directly onto the bitcoin network. If the sender does not do this after a reasonable time (e.g. 1 minute), the receiver should publish the template transaction as an important anti-spy/anti-DoS tactic . The sender may also choose to publish the template transaction instead of the final transaction if they believe the receiver to have unreasonably lowered the feerate of the transaction (i.e. increased the size of the transaction, but not the feerate enough). And both parties can consider publishing the template transaction even after the finalized transaction is on the network (taking advantage of replace-by-fee) if the final transaction is not confirming and the template transaction has more fees.
=== Implementation Notes ===
For anyone wanting to implement bustapay payments, here are some notes for receivers:
* A transaction can easily be checked if it's suitable for the mempool with testmempoolaccept in bitcoin core 0.17+
* Tracking transactions by txid is precarious. To keep your sanity make sure all inputs are segwit. But remember segwit does not prevent txid malleability unless you validate the transaction. So really make sure you're using testmempoolaccept at the very least
* Bustapay could be abused by a malicious party to query if you own a deposit address or not. So never accept a bustapay transaction that pays an already used deposit address
* You will need to keep a mapping of which utxos people have showed you and which you revealed. So if you see them again, you can reveal the same one of your own
* Check if the transaction was already sorted according to BIP69, if so ensure the result stays that way. Otherwise probably just shuffle the inputs/outputs
* A reference implementation is maintained at https://github.com/rhavar/bustapay which functions as a wrapper around some RPC calls to bitcoin core's wallet.
* The sender must be careful of an attack where the receiver tries to add additional inputs that are controlled by the sender, with the hope that the sender blindly signs it.
== Backwards Compatibility ==
Bustapay is an optional payment protocol and therefore has no backwards compatibility concerns. It in fact can only be supported in addition to normal transaction processing, as falling back to a normal bitcoin transaction is a required behavior.
== Credits ==
The idea is obviously based upon Dr. Maxwell's seminal CoinJoin proposal, and reduced scope inspired by a simplification of the "pay 2 endpoint" blog post by blockstream.

Some files were not shown because too many files have changed in this diff Show More