* Formosa as BIP
Mnemonic *sentences* instead of words proposed as forwards- and backwards-compatible expansion to BIP39, itself as Bitcoin Improvement Proposal.
* Update bip.mediawiki
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
* Update bip.mediawiki
Satisfying requirement of title in fewer than 50 characters.
* Formosa: address PR #2108 review feedback
Restructure the draft to follow BIP-3 conventions and resolve the issues
raised by reviewers in https://github.com/bitcoin/bips/pull/2108:
- Introduce explicit Specification section with a Terminology subsection
that distinguishes 'word', 'category', 'theme', 'sentence' and
'mnemonic' / 'mnemonic story', removing the ambiguity of using
'sentence' at two different scales.
- Replace the unclear 'if the category is led by another category'
wording with an explicit LED_BY field description and a step-by-step
algorithm that covers both the leaderless and led cases.
- Reflow the theme-property list (previously a/b/c/d/e split by an
intervening paragraph) into a single numbered list so it renders as a
list rather than as code blocks.
- Add a dedicated Rationale section covering the 33-bit sentence size,
themed sentences, free-form theme schema, the LED_BY mechanism, the
re-encoding-through-BIP-39 design, and why custom themes are
discouraged.
- Add a dedicated Backwards Compatibility section describing
compatibility at the mnemonic, entropy, and seed levels.
- Add a worked Example section showing a 128-bit entropy being encoded
into a 4-sentence mnemonic story under a small illustrative theme,
including bit splitting, FILLING_ORDER vs NATURAL_ORDER, and the
LED_BY lookup.
- Tighten the Abstract and Motivation; clarify that BIP-39 is itself a
Formosa theme.
* Formosa: spell out abbreviated table labels
Reviewer on PR #2108 asked for no abbreviations in table labels. Replace:
- ENT / CS / S / MS column headers with 'Initial entropy bits',
'Checksum bits', 'Total bits', 'Number of sentences', 'Mnemonic
words (6-word theme)' and 'Mnemonic words (BIP-0039)'.
- 'List size / Bits / Chars to identify / Density (bits/char)' with
'Wordlist size / Bits per word / Characters to identify / Density
(bits per character)'.
- ADJ. with ADJECTIVE in the example bit-assignment diagram, and the
surrounding narrative ENT/MS uses with the spelled-out forms.
The accompanying formulas now use the expanded names too, so the
algorithm description and the table column headers stay consistent.
* Formosa: rebuild Example on the real medieval_fantasy theme
Replace the previous hypothetical 5-category example with one that
mirrors the medieval_fantasy theme actually shipped at
https://github.com/Yuri-SVB/formosa/tree/master/src/mnemonic/themes,
including:
- the real 6 categories with their actual BIT_LENGTHs
(VERB=5, SUBJECT=6, OBJECT=6, ADJECTIVE=5, WILDCARD=6, PLACE=5,
summing to 33);
- the real FILLING_ORDER and NATURAL_ORDER;
- the real lead tree (VERB → SUBJECT; SUBJECT → OBJECT and WILDCARD;
OBJECT → ADJECTIVE; WILDCARD → PLACE), showing that a single
leader can have several dependent categories;
- a 33-bit block whose decoded indices (28, 32, 63, 27, 46, 29)
pick existing words and existing sub-list entries: VERB[28]
=unveil, SUBJECT_under_unveil[32]=king, OBJECT_under_king[63]
=wine, ADJECTIVE_under_wine[27]=sweet, WILDCARD_under_king[46]
=queen, PLACE_under_queen[29]=throne_room, yielding the sentence
'king unveil sweet wine queen throne_room'.
This keeps the worked example faithful to the reference
implementation rather than to a fabricated theme, so that anyone can
reproduce the encoding by parsing medieval_fantasy.json.
* Formosa: explain LED_BY as a primitive next-word predictor
Add a paragraph to the LED_BY rationale clarifying that a Formosa theme
behaves as a primitive language model (next-word predictor): each LED_BY relation
skews the conditional distribution over the next word so that probability
mass falls only on the 2^BIT_LENGTH words compatible with the already-
chosen leader, and zero elsewhere. The theme designer plays the role of
training data, hand-curating which combinations are semantically coherent.
This framing makes explicit why themes produce sentences that 'sound right'
while still covering all 2^33 bit patterns of a sentence.
* Cite the companion project Mooncake (https://github.com/T3-Infosec/mooncake)
which builds on this property by rendering each Formosa category as an
on-screen table whose rows and columns are permuted per input session.
Combined with the randomized-indexation property,
an attacker watching only the screen still learns nothing without also
recovering the press sequence.
Add a Rationale paragraph explaining a further benefit of splitting the
vocabulary into several short wordlists (32-128 entries each): such tables
fit on a mobile-device screen and admit input via on-screen lookup, which
a single 2048-word list does not.
The randomized indexation:
- defeats pure key-logging (keystrokes alone don't reveal words; the
attacker also needs the session permutation),
- raises the bar for shoulder surfing (same as key-logging: only keys
AND session's permutation suffice. Either alone is uniformative).
This gives an operational, security-focused argument for the
many-small-lists design that complements the existing memorization and
information-density arguments.
Formosa: document Mooncake's volume-key input on mobile
Add a paragraph to the Mooncake rationale describing the proposed mobile
input mechanism: reuse of the volume-up / volume-down keys as a two-button
binary selector. Because every Formosa category is sized 2^BIT_LENGTH and
the on-screen table is laid out in rows, sub-rows and columns whose counts
are powers of two, narrowing to a single cell takes exactly BIT_LENGTH
presses (5 for a 32-entry category, 6 for 64, 7 for 128). The per-category
press count is invariant therefore uninformative, and equal to the bits of
entropy encoded, and the 'one bit per press' bound matches the existing
side-channel argument.
Add three concrete reasons why volume-key input on mobile resists visual
shoulder surfing better than an on-screen keyboard:
- Subtler input motions: a single finger pressing a side rocker, much
harder to read from a distance than multi-finger taps on a glass
keyboard.
- Easy occlusion with the second hand: both volume keys are on one edge
of the device, so the free hand (or the holding hand's thumb) can
cover them without obscuring the screen for the user.
- Pocket input via headphone volume buttons: because the protocol is
purely binary, headphone volume controls are sufficient, letting the
user keep the buttons in a pocket while operating it by feel and
removing the input motion from the observer's field of view entirely.
* Update bip.mediawiki
Fixed typo from "dektop" to "desktop"
Fixed agreement of number from "Those of a mobile device" to "Those of mobile devices"
* Update bip.mediawiki
Substituted triple hyphen for —
Co-authored-by: Murch <murch@murch.one>
* Update bip.mediawiki
Updated title to mention Formosa and be more self-explanatory.
Co-authored-by: Murch <murch@murch.one>
* renamed bip.mediawiki to bip-0450.mediawiki
added 450 to BIP number in preamble
added assigned date to 2023-05-02 (date of first mention in email group) in preamble
added correspondent entry on README.md table
* fixed assignment dated
shortened title
* BIP-450: fix CI lint failures (field order + README filename)
Two issues caused Build-Table-Checks and Diff-Checks to fail on PR #2108:
1. Preamble field order: scripts/buildtable.pl enforces @FieldOrder
(...License, Discussion, ..., Requires...). The preamble had Requires
before Discussion, causing buildtable.pl to die "Field order is
incorrect", which fails Build-Table-Checks and cascades into
Diff-Checks. Moved the Discussion block above Requires.
2. README table row referenced bip-0450.md, but the file is
bip-0450.mediawiki. buildtable.pl emits the .mediawiki name, so the
README row never matched the generated table and Diff-Checks failed.
Corrected the link target to bip-0450.mediawiki.
Verified locally: buildtable.pl exits 0, diffcheck.sh reports "README
table matches expected table from BIP files", link-format-chk.sh passes.
* bip450: Add dates to discussion header
* Add draft BIP for dust utxo disposal protocol
* Assign number 451, update preamble, rename BIP file, and add entry to README table
* Small edits
* Change title, abstract, motivation to focus on dust attack UTXOs
* Simpify dust selection section
* Add batching to address consolidation rules
* Fix core version in privacy preservation
* Fix table units
* Add confirmed utxo rationale
* Revert title back to original
* Change output to always be OP_RETURN ash
* Varops: Two BIPs for Script Restoration: varops calculations and tapleaf version (0xc2).
Special thanks to Murch for teaching me mediawiki, and so much great
formatting and clarity advice.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* script restoration: fix MUL cost to account to round up B to word boundary.
Julian points out that the implementation does this, which improves accuracy
for the case of small B (since the term is multiplied: for normal OP_ADD etc
we don't bother, since the difference is very bounded).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BIP 440, 441: official numbers, into README.mediawiki and renamed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---------
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* Add sp() output descriptor format for BIP352 Silent Payments
* Update headers and remove space after comma in descriptors
* Add label ranges with examples
* Update with assigned number and adjust preamble for BIP3
* BIP392: Add table entry to README
* Add two argument key expression form and remove birthday and label arguments
* Add BIP392 sp() descriptor to BIP380 script expressions table
* Add sp() descriptor to BIP390 allowed expressions and add musig() example to BIP392
* Add changelog and version header to BIP390
* new bip: timelock recovery storage format
* Comparison with Script-Based Wallets
* Type is Specification
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
* Change Authors to a single Author
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
* Replace OP_VAULT mention with OP_CHECKCONTRACTVERIFY
* Only the Alert Transaction needs to be non-malleable
* Adding discussion link
* limiting the transactions weight
This is important in order to prevent users from creating
recovery-plans that are hard to propagate.
* Explain anchor-addresses
* fix typo
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
* add surname initial to author name
* Explain unintentional initiation of rrecovery-plan.
* limit alert_inputs length to 2439
* updating bip number to 128
* rename to bip-0128.mediawiki
* BIP 128: Timelock-Recovery storage format
* fix field order, change title to uppercase
* Making plugin_version optional
Relevant only in wallets where
the feature is implemented
via a plugin.
* Removing mainnet
Irrelevant. Obviously a monitoring
service for mainnet should
verify that the addresses
are on mainnet.
* Add Chaincode Delegation BIP
* Update license to BSD-3-Clause and expand blinded signing documentation
* Address initial PR comments
* Update with BIP number assignment
* Fix delegator_sign test vector
* Upgrade secp256k1lab and add license file
- Upgrade vendored secp256k1lab to commit a265da1 (adds type annotations)
- Add COPYING file to satisfy MIT license requirements
- Document secp256k1lab commit reference in BIP text
* Fix type checker and linter issues in reference implementation
- Fix TweakContext to use Scalar types for gacc/tacc
- Replace HashFunction enum with Callable type alias
- Fix bytearray to bytes conversion in blind_sign
- Move imports to top of file
- Fix boolean comparison style (use 'not' instead of '== False')
- Add proper type annotations and casts for dict handling
- Remove unused imports and type ignore comments
* Address PR review comments on terminology and clarity
- Add intro explaining delegation naming (chain code is delegated, not
signing authority)
- Reorder terminology to list Delegator before Delegatee
- Replace "quorum" with clearer "can co-sign for UTXOs" language
- Clarify derivation constraints in terms of delegatee's extended key
- Rename "Delegatee Signing" section to "Signing Modes"
- Fix "delegatee can apply" to "delegator can produce" (line 112)
- Replace undefined "caller" with "delegatee" (line 173)
- Clarify "Change outputs" to "Tweaks for change outputs" (line 98)
- Add note that message is separate from CCD bundle
- Add note on application-specific verification (addresses, amounts)
- Add transition sentence clarifying non-concurrent protocol scope
* Add changelog entry for 0.1.3
* Fix header: use Authors (plural) for multiple authors
* Fix BIP header format for CI compliance
- Change Type from 'Standards Track' to 'Specification' (valid type)
- Change 'Created' to 'Assigned' (correct field name per BIP format)
- Change 'Post-History' to 'Discussion' (recognized field in buildtable.pl)
* Apply suggestion from @murchandamus
---------
Co-authored-by: Jesse Posner <jesse.posner@gmail.com>
```
sed -z -i 's/Type: Standards Track/Type: Specification/' bip-0*.md
sed -z -i 's/Type: Standards Track/Type: Specification/' bip-0*.mediawiki
```
After the scripted changes, the changes to BIP-40, BIP-41, and BIP-63
were undone, because it breaks CI.
These three BIPs only exist conceptually and their proposal documents
are missing which causes changes to them ot break the CI. I defer the
changes to these BIPs to a separate pull request to get CI to pass.
Amend CI script to new statuses and update existing status field values
in table and BIPs.
```
sed -z -i 's/Status: Proposed/Status: Complete/' bip-0*.md
sed -z -i 's/Status: Proposed/Status: Complete/' bip-0*.mediawiki
sed -i 's/| Proposed/| Complete/' README.mediawiki
```
BIP155 was deployed in Bitcoin Core version v0.21.0, and has been in use for
almost 5 years.
New networks may be added to the reserved network IDs table when they're
needed, either in this BIP or in a new one.
If BIP3 is activated, I think BIP155 would become Deployed.
Co-authored-by: Murch <murch@murch.one>
Co-authored-by: laanwj <126646+laanwj@users.noreply.github.com>
* Draft payjoin v2 BIP
* Include mailing list feedback
* Include TABConf feedback
* Include padding
* Include production reference implementation
* Adopt BIP-77 for payjoin v2
* Distinguish payjoin directory from OHTTP Relay
* Detail OHTTP Key Configuration mechanism
* Fix punctuation
* Make base64URL references consistent
* Reference standardized Secp256k1 DHKEM for HPKE
* Add Comments-URI
* fixup: Format and spell check
Co-authored-by: spacebear <144076611+grizznaut@users.noreply.github.com>
* Add BIP 77 to README
* Add Payjoin V2 overview diagram
* Add Oblivious HTTP Sequence Diagram
* Correct links and spelling
Co-authored-by: thebrandonlucas <38222767+thebrandonlucas@users.noreply.github.com>
* Wrap <code> blocks
* Fix basic scheme actors
* Fix dead samourai links
* Orient motivation around a problem
* fix links
* Keyconfig s/should/must/ be provided
* Fix typos
Co-authored-by: thebrandonlucas <38222767+thebrandonlucas@users.noreply.github.com>
* s/pubkey/public key
* Incorporate jonatack's suggestions
* Incorporate more jonatack suggestions
* Incorporate satsie's suggesetions
* Rename "Async Payjoin"
* Replace BIP21 params with fragment params
* Revise document to describe Payjoin Sessions
Enrollment was a less clear than sessions
* Revise Sequence Diagram
* Spell initialize
* Update the bip to represent the stable protocol
* Spell according to Type Checks's job
* Mention the format of the ohttp fragment
* Reference BIP 78 attack vectors
* Remove straggling text
* Specify authorization mechanism
The specifics of a credential issuance are left out, however
* Use implicit session initialization
* Specify cryptographic handshake based on Noise IK
Co-authored-by: Yuval Kogman <nothingmuch@woobling.org>
* Add Spacebear's clarifications
Co-authored-by: spacebear <git@spacebear.dev>
* Document subdirectory Short IDs
* Require uppercase URL
bech32 fragment prefixes are case sensitive, and
alphanumeric mode only works on capital letters.
* Specify bech32 fragment parameter definitions
* Uppercase URL specifically only after subdirectory
* Note payload uniformity via padding and ellswift
* Include Message Byte Representations
This is the most straightforward way to explain the various padding
requirements.
* Document HPKE `info` strings
* Truncate lines to 120 characters
* Receiver's Original PSBT, not proposal
* Specify no mixed [output script]
* Remove extraneous pipe character
* Require BIPS 21, 78, 174
* Update checklist MUST/MUST NOT sections
MUST NOT contained MUST details. Move them to MUST.
* inputs ⇒ input
* Clarify BIP 78 payjoin version 1 connection
* Fix backwards compat language
* Payjoin version 2 URIs
* Reference Binary HTTP RFC
* Payjoin version 1 Proposal PSBTs
* Oblivous -> Oblivious
* Rm reference to 'production relays'
* Repeat the active agent by name
* Add Post-History
* Title 'Async Payjoin'
* Check spelling
* directory -> mailbox
* Move ohttp= fragment param to link to frag spec
* Mention URI keys as bootstrap mechanism
* Mailbox Discovery
* Remove superfluous word
* Clarify motivation
* Revise backwards compatiblity section for clarity
* Remove related protocol details
* Mv copyright out of flow
* Fix grammar (should be plural)
* Weaken language around addressing CIOH
"solves" implies this is the end of the story. Clarify that the problem
is the sole *explicit* problem mentioned in the paper.
* Simplify overview
- describe happy path protocol sequence
- introduce non-obvious key terms inherited from BIP 78
- no need for technical details that are clarified in the specification
* Describe optionality in overview
* Nitpicky sequence diagram fixes
* Clarify receiver's initial message in sequence diagram
* Simplify Basic Scheme section
* Mention OHTTP abbreviation on first mention
* Move sequence diagram up
* fragment parameter encoding corrections
- base64url was replaced by bech32
- formatting fixes
- some clarifications
* Use SHA-256 at independent mentions for consistency
* bootstrap grammar fix & correction
bootstrap would use a tor exit node, not a hidden service
* clarify proposal PSBT encryption layers
clarify which key is used for which layer of encryption (payjoin v2 e2ee vs.
OHTTP)
the message is not "authenticated" by the sender, rather it is tagged, it can be
authenticated during decryption.
* format original/proposal PSBT terms using italic, not <code>
* HRP of short ID is an implementation detail
it doesn't matter what is used since it's stripped after encoding
* Clarify checklist requirements
* "by intersection" unclear and unnecessary
* the fragment doesn't follow the pj param, it's part of it
* fix message diagram line intersections
* Correct encapsulated OHTTP diagram
The binary HTTP request is encrypted, and the AEAD tag is at the end, not the
beginning
* Clarifications for HPKE keys
Remove noise protocol framework mention. The IK pattern is not accurate, the
closest patterns are N or possibl NN, but neither is a perfect fit (N defines the
key as static, which it isn't, and NN is an interactive pattern)
* Remove note about forward secrecy
This is inaccurate, forward secrecy is defined with respect to long term
sessions, so the definition doesn't really extend to the request and response
messages, each of which is encrypted with ephemeral keys.
* Clarify OHTTP-relay bypassing by use of tor hidden service
* Update HPKE mode used for sender's message
Previously the reply key was included before the HPKE ciphertext, and the Auth
mode was used using this key. Since they are delivered together that only proves
the key was usable by the sender, not that the ciphertext is authentic. With the
key included as part of the encrypted plaintext, the HPKE mode was changed to
the base encryption to a public key mode with no authentication key.
* keep mailbox, but rename mailroom back to directory
Partly reverts a4d4065fa6f736f058e9173aa852e4fd12e75650, this change is hardly
more than a find & replace of mailroom to directory, and does not revert grammar
changes etc in addition to not reverting the subdirectory -> mailbox rename
which was the main point of confusion.
* Clarify allowed_purposes mechanism
First explain RFC 9540, then explain the extension mechanism.
Make roles in the interaction more explicit by changing the heading, "Directory
Discovery" sort of implies that clients discover these, when it describes relay
to directory interaction.
Clarify centralization pressure, that is alleviated by making senders' and
receivers' choices independent of each other.
* Correct payload uniformity section
We forgot about the OHTTP header which is 7 bytes of cleartext that also
specifies the DHKEM algoritm.
Additional clarifications and some restructuring to describe the details two
classes of messages each in its own self contained paragraph.
* rewrap paragraph to fix broken link
* fix bullet list formatting
- unindent to avoid <pre>
- fix broken URLs
- fix bullet items split into paragraphs
* rewrap section to fix broken links
* rewrap more paragraphs to fix broken links
* make attack vectors level 2 heading
as level 3 heading it was displayed under rationale in the table of contents
* Grammar/style fixes
* Order Requires
* Describe 'what' in the first sentence of the abstract.
* Be more specific about motivation.
* Make goal more explicit and consise
* Standardize "Common-input-ownership heuristic"
bitcoin wiki uses this.
* Replace Request expiration with Session Expiration
* Specify BIP 78 `v` parameter as redundant.
* Separate Short ID length rationale from spec
* Clairfy key nomeclature
- mailbox key
- reply key
- receiver key
as well as ephemerality and session nomeclature.
* Place byte diagrams with there respective message description.
* Include bitcoin URI subsection
* Top half reorg
* Add Yuval Kogman as Co-author
* NO mak typo
* Fix heirarchy
* Convert mediawiki to markdown
nix shell nixpkgs#pandoc --command bash -lc '
pandoc -f mediawiki -t gfm bip-0077.mediawiki -o bip-0077.md'
rm bip-0077.mediawiki
reference bip-0077.md in README
surround bip-0077.md preamble in ``` to satisfy CI
* Strip link titles from mediawiki -> md conversion
sed -i.bak -E 's/\]\(([^ )]+) "[^"]*"\)/](\1)/g' bip-0077.md
* Strip leading/trailing spaces from inside links
sed -i.bak -E 's/\[[[:space:]]+/[/g; s/[[:space:]]+\]/]/g' bip-0077.md
* Fix spacing around inline code
* Take bitcoin URI example out of md link syntax
* Fence byte diagrams in backtics
* Replace sequence diagrams with mermaid
Better rendering and semantic source
* Collapse overview, basic scheme, and protocol sequence
These were all inconsitent levels of detail for the same thing. Leave the overview
the highest level and link to the specifics.
* Consistent short id singularity
* Remove straggling whitespace
* Link whitepaper
* Fix motivation flow
* Clarify abstract
* Clarify motivation
* Clarify overview
* Clarify bootstrapping
* Use singular to describe Payjoin URI
* Clarify mailbox endpoint
Specify that v2 mailboxes are OHTTP Targets.
Mention backwards compatibility.
* Clarify Receiver Fragment Parameters
* Revise messaging for clarity
* Add rationale for allowed_purposes
* Define ElligatorSwift according to BIP 324
* Clarify attacks, backwards compatibility
* Fix Receiver Proposal PSBT messaging header
for link.
* Add activation to sequence
* Correct #64-bit-short-id-length link
Co-authored-by: Yuval Kogman <nothingmuch@woobling.org>
* Clarify why not AES-GCM rationale
* Specify serialization of reply key in plaintext
* Specify the wire format for ChaCha20-Poly1305 ciphertext and tag
* Specify details of HPKE message wire format
Also clarifies that HPKE auth mode is used with the receiver's key,
authenticating the receiver as the sender of the encrypted Proposal PSBT.
* Correct diagram for OHTTP encapsulation
The order according to RFC 9458 and the code is is header, followed by
encapsulated key, followed by the ciphertext.
* OHTTP message encoding according to RFC 9458
* Rephrase abstract in active voice
* Deduplicate motivation word choice
- 'suitable for widespread implementation' vs appropriate, it's stronger
- 'mature solutions' to express that we chose those already based on iteration
- 'proven bitcoin primitives' to reflect the use of those battle tested like
ElligatorSwift
* Simplify output batching motivation
* Reduce verbosity of linking exemplar conclusion
* Use PSBT 'update' verb in overview
Say 'appropriate intputs and/or outputs' because outputs might be merely
replaced, not necessarily added.
* Mention mutual exclusivity of Original and Proposal PSBTs
* Capitalize Uri -> URI
* Clarify URI parameter key/value distinction
* Backwards-compatible receivers *disable* pjos
* Use bech32 character set, not bech32
* Clarify session-specific parameter encoding
* Say 33-byte compressed public key
* Clarify v2 optional sender parameters application
* Clarify receiver session initiation overview
Co-authored-by: nothingmuch <nothingmuch@woobling.org>
* Mention sender's ephemeral mailbox in overview
Co-authored-by: nothingmuch <nothingmuch@woobling.org>
* Clarify cut-through optimization
* Replace mention of v1/v2 payjoin
Instead use 'This proposal', 'BIP 78', 'BIP 77', or omit the mention.
* Mention BIP 174 for PSBTv0
* Mention sender's *corresponding* public key
* Hyphenate '16-byte'
* Clarify who can post messagese direct to mailbox
* liu -> lieu
* Simplify cut through overview sentence structure
* Replace 'Payjoin exemplar' with 'A natural application..'
* Make motivation CIOH mention easier to read
Use language from sataoshi and don't mention input batching since the next
sentence already does.
* Specify Proposal PSBT MUST/MAY input/output inclusion rules
* remove duplicate 'and'
* Remove duplicate 'preserve'
Co-authored-by: Brandon Lucas <thebrandonlucas@gmail.com>
* The HRP is used as the parameter key
Co-authored-by: Yuval Kogman <nothingmuch@woobling.org>
* Add rationale for random padding in OHTTP
* Use "zero" instead of "0"
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
* epehmeral -> ephemeral
Co-authored-by: Brandon Lucas <thebrandonlucas@gmail.com>
* subject match tense
Co-authored-by: Brandon Lucas <thebrandonlucas@gmail.com>
* Capitalize Payjoin for protocol
Co-authored-by: Brandon Lucas <thebrandonlucas@gmail.com>
* Capitalize Payjoin for protocol
Co-authored-by: Brandon Lucas <thebrandonlucas@gmail.com>
* Capitalize Payjoin for protocol
Co-authored-by: Brandon Lucas <thebrandonlucas@gmail.com>
* Capitalize Payjoin for protocol
Co-authored-by: Brandon Lucas <thebrandonlucas@gmail.com>
* Capitalize Payjoin for protocol
Co-authored-by: Brandon Lucas <thebrandonlucas@gmail.com>
* ("Version 2") relative to and described in ("Version 1")
Co-authored-by: Jon Atack <jon@atack.com>
* BIP78's requirements for Payjoin Version 1
Co-authored-by: Jon Atack <jon@atack.com>
* Include missing period
Co-authored-by: Jon Atack <jon@atack.com>
* which -> that
Co-authored-by: Jon Atack <jon@atack.com>
* Separate independent clauses with a semicolon
Co-authored-by: Jon Atack <jon@atack.com>
* Remove duplicate "at"
Co-authored-by: Jon Atack <jon@atack.com>
* Hyphenate "short-lived"
Co-authored-by: Jon Atack <jon@atack.com>
* Fix Attack Vectors URL
Co-authored-by: Jon Atack <jon@atack.com>
* which -> that
Co-authored-by: Jon Atack <jon@atack.com>
* Include colon to reference Oblivious HTTP Relay impl
Co-authored-by: Jon Atack <jon@atack.com>
* consist -> consists
Co-authored-by: Jon Atack <jon@atack.com>
* Remove double "the"
Co-authored-by: Jon Atack <jon@atack.com>
* Remove double "the"
Co-authored-by: Jon Atack <jon@atack.com>
* Correct Padded BHTTP Response length
144 bytes not 104
See: 87042266d1/payjoin-directory/src/lib.rs (L30-L31)
* which -> , which
* Note TLS is not available in Bitcoin Core
* Link to BIP21 forwards compatibility `reqparam`
* Require rev. lexicographical frag. param. order
A specific order might create a fingerprint for a specific wallet, imposing a privacy
risk. It seems impossible to impose an order on BIP21 parameters, but BIP 77 clients
may error on out-of-order fragment parameters to at least avoid some fingerprint there.
Reverse lecicographical ordering was chosen because that is how the existing implmentation
serializes the parameters already, so that no breaking change needs to be made.
Co-authored-by: nothingmuch <nothingmuch@woobling.org>
---------
Co-authored-by: spacebear <144076611+grizznaut@users.noreply.github.com>
Co-authored-by: thebrandonlucas <38222767+thebrandonlucas@users.noreply.github.com>
Co-authored-by: Yuval Kogman <nothingmuch@woobling.org>
Co-authored-by: spacebear <git@spacebear.dev>
Co-authored-by: spacebear <144076611+spacebear21@users.noreply.github.com>
Co-authored-by: Brandon Lucas <thebrandonlucas@gmail.com>
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
Co-authored-by: Jon Atack <jon@atack.com>
