docs: add BIP-445 research methodology dossier

.gitignore

@@ -4,3 +4,7 @@ bip-0174/coinjoin-workflow.pdf
 bip-0174/multisig-workflow.aux
 bip-0174/multisig-workflow.log
 bip-0174/multisig-workflow.pdf
+
+# BIP-445 research materials sanitation
+# Ignore local/generated copies of the internal research dossier.
+docs/bip445-research/

docs/bip445-research/BIP445-SOURCE-RESEARCH-REPORT.md

@@ -0,0 +1,169 @@
+# BIP-445 Source-Evidence Research Report
+
+**Status:** READ-ONLY RESEARCH ARTIFACT — NOT A PUBLIC COMMENT
+
+This document records findings from a read-only inspection of `bitcoin/bips` PR #2070 and related sources. It corrects earlier hypotheses and identifies which technical surfaces are supported by current source.
+
+---
+
+## 1. Scope
+
+- Primary PR: `bitcoin/bips#2070`
+- PR head: `siv2r:bip-frost-signing`
+- PR head SHA: `f7de4568f2497b40bd85bb8fb40da32c05b68d72`
+- Fork private dossier: `vitrixLab/bips#1`
+- No upstream writes, comments, or PRs were performed.
+
+---
+
+## 2. Methodology
+
+LLM-generated hypotheses were used only as starting points. Each hypothesis was independently verified against normative BIP text, reference implementation, test-vector architecture, and related BIPs/RFCs before being recorded as a finding.
+
+Evidence states used:
+
+- `VERIFIED` — direct source evidence found and checked
+- `SUPPORTED` — strong documentary support, not fully independently reproduced
+- `UNVERIFIED` — plausible but insufficient evidence
+- `UNKNOWN` — evidence insufficient to determine
+- `CONFLICT` — sources disagree or source does not support prior claim
+- `WITHDRAWN` — prior public/private claim removed after negative evidence
+
+---
+
+## 3. Key Verified Findings
+
+### 3.1 Nonce coefficient `b` is signer-set bound via count prefix
+
+Specification and implementation use:
+
+```text
+hash_BIP0445/noncecoef(
+  bytes(4, u) ||
+  ser_ids ||
+  aggnonce ||
+  xbytes(Q) ||
+  m
+)
+```
+
+Changelog `0.8.0` explicitly records adding the signer-count prefix to prevent ambiguous `(ids, aggnonce, Q, m)` concatenation.
+
+**Status:** `VERIFIED`
+
+---
+
+### 3.2 Deterministic signing binds `my_id` and signer identifiers
+
+Deterministic nonce includes:
+
+```text
+secshare_
+my_id
+len(ids)
+serialize_ids(ids)
+aggothernonce
+...
+```
+
+Changelog `0.4.2` records binding `my_id` and signer IDs.
+
+**Status:** `VERIFIED`
+
+---
+
+### 3.3 Error/blame boundary is explicit
+
+- `ValueError` — malformed setup/config input, such as invalid `SignersContext`.
+- `InvalidContributionError` — malicious runtime protocol contributions by signer or coordinator.
+
+**Status:** `VERIFIED`
+
+---
+
+### 3.4 Arbitrary tweaks are explicitly an open security question
+
+Specification distinguishes Bitcoin-derived tweaks from arbitrary adversarial tweaks and states that accepting arbitrary tweaks may negatively affect security. The authors explicitly identify this as an open question.
+
+**Status:** `VERIFIED` as a normative statement. It is not evidence of an actual exploit.
+
+---
+
+### 3.5 BIP-340 challenge is inherited
+
+Challenge uses:
+
+```text
+BIP0340/challenge(R.x-only || Q.x-only || msg)
+```
+
+This preserves Taproot/BIP340 compatibility.
+
+**Status:** `VERIFIED`
+
+---
+
+### 3.6 ChillDKG interoperability is already tracked
+
+`BlockstreamResearch/bip-frost-dkg#157` explicitly tracks aligning `DKGOutput` with BIP-445 expected input.
+
+**Status:** `VERIFIED` as an existing issue. It is not a novel research discovery.
+
+---
+
+## 4. Withdrawn / Rejected Claims
+
+### 4.1 Absent vs zero-length message semantics
+
+Earlier hypothesis that BIP-445 must distinguish an absent message from a zero-length message is not supported.
+
+Maintainer response: "The message is a mandatory argument and thus always present."
+
+Current source confirms `m` is a mandatory byte-array session parameter. `NonceGen`'s optional `msg` is a separate defense-in-depth input.
+
+**Status:** `WITHDRAWN` / `CONFLICT` with earlier claim.
+
+---
+
+## 5. Evidence Table
+
+| Claim | Source | Status |
+|---|---|---|
+| Nonce coefficient includes signer count prefix | `bip-0445.md`, implementation | `VERIFIED` |
+| Deterministic nonce binds signer subset | implementation, changelog 0.4.2 | `VERIFIED` |
+| Serialization ambiguity addressed | changelog 0.8.0 | `VERIFIED` |
+| Error/blame semantics specified | implementation | `VERIFIED` |
+| Arbitrary tweak security open | spec tweaking section | `VERIFIED` |
+| BIP340 challenge inherited | spec + BIP340 | `VERIFIED` |
+| ChillDKG alignment tracked | issue #157 | `VERIFIED` / non-novel |
+| Absent vs empty message defect | spec + maintainer | `WITHDRAWN` |
+| Exact test vector count (68 → 250) | vectors summary | `UNKNOWN` without independent count |
+| Coordinator can cause abort | spec | `VERIFIED` |
+| Coordinator can forge | spec normative claim | `VERIFIED` as claim |
+| BIP327 tweak context reused | spec | `VERIFIED` |
+
+---
+
+## 6. Source Paths Used
+
+```text
+bip-0445.md
+bip-0445/python/frost_ref/signing.py
+bip-0445/python/gen_vectors.py
+bip-0445/python/vectors/*
+bip-0340.mediawiki
+bip-0327.mediawiki
+RFC 9591
+```
+
+---
+
+## 7. Repository Safety
+
+- `bitcoin/bips`: no writes
+- PR #2070: no comments/reviews
+- `vitrixLab/bips`: only dossier files updated
+- No merge
+- No upstream contribution
+
+This report is private research, not a public BIP comment.

docs/bip445-research/FUTURE-RESEARCH-ROADMAP.md

@@ -0,0 +1,76 @@
+# Future BIP-445 Research Roadmap
+
+## Phase A — Security hardening
+
+### A1. Formal coordinator/threat-model section
+
+Document the coordinator's capabilities, honest-but-curious versus malicious behavior, participant assumptions, identifiable-abort conditions, and the security consequences of coordinator manipulation.
+
+### A2. Signer-subset/session-binding regression vectors
+
+Create permanent regression vectors covering signer-set changes, session separation, deterministic nonce derivation, and cross-session transcript binding. The objective is to make the signer-subset invariant executable rather than merely descriptive.
+
+### A3. Serialization/domain-separation table
+
+Build a table for every hash input and transcript component showing its fields, ordering, framing, length/count encoding, and domain-separation purpose. Use it to detect ambiguous concatenations systematically.
+
+### A4. Explicit arbitrary-tweak security boundary
+
+State exactly which tweak classes are covered by the construction and which attacker-supplied or arbitrary tweak scenarios require separate analysis. Avoid claims broader than the demonstrated model.
+
+### A5. Formal identifiable-abort assumptions
+
+Specify when an abort is attributable to the coordinator, a signer, malformed input, or an unavoidable protocol condition, and what participants can actually identify from the available evidence.
+
+## Phase B — Interoperability
+
+### B1. Cross-implementation test harness
+
+Build a harness that compares independent implementations over identical transcripts, signer subsets, messages, tweaks, failures, and serialization boundaries.
+
+### B2. Canonical conformance vectors
+
+Define a canonical set of positive, negative, boundary, and adversarial vectors. Coverage should be organized by protocol property rather than only total vector count.
+
+### B3. C/Rust/C++ API mapping guidance
+
+Map the specification's conceptual objects and operations onto representative C, Rust, and C++ APIs, documenting ownership, serialization, error handling, and type-boundary assumptions.
+
+### B4. Error/blame semantics specification
+
+Develop explicit guidance separating setup/configuration failures from malicious or invalid runtime contributions, including how an implementation should expose or suppress blame information.
+
+### B5. Reference implementation ↔ pseudocode consistency checks
+
+Systematically compare pseudocode, normative prose, reference implementation, and tests so that semantic drift is detected before it becomes an interoperability issue.
+
+## Phase C — Ecosystem architecture
+
+### C1. Reusable tweak-context abstraction
+
+Research whether Bitcoin signing BIPs can share a common tweak-context abstraction that preserves explicit domain separation, signer/session binding, and clearly scoped threat assumptions.
+
+### C2. Arbitrary/agnostic tweaking research
+
+Investigate broader arbitrary or agnostic tweaking models without assuming that results from one construction transfer automatically to another.
+
+### C3. Expanded ROAST/FROST integration guidance
+
+Map the relevant interaction points among BIP-445, FROST, ROAST, DKG outputs, and signing-session state. Focus on concrete interface and transcript compatibility rather than conceptual similarity alone.
+
+### C4. Additional implementations and independent audits
+
+Seek independent implementations and audit perspectives before making strong ecosystem-level security or interoperability claims.
+
+## Research gate for all phases
+
+Each completed phase should produce evidence that can survive the same public-comment gate:
+
+- exact specification reference;
+- implementation/API reference;
+- reproducible trace, vector, or test;
+- prior-art/tracking check;
+- explicit falsification attempt; and
+- clear evidence state.
+
+The roadmap therefore treats documentation quality and verification discipline as part of the technical work, not as a separate editorial step.

docs/bip445-research/LESSONS-LEARNED.md

@@ -0,0 +1,45 @@
+# Lessons Learned
+
+## 1. LLM output is a hypothesis generator, not protocol evidence
+
+LLM-assisted review is useful for finding candidate questions, edge cases, and relationships across documents. It is not sufficient evidence for a public protocol criticism. Every candidate claim requires independent verification against the normative specification, implementation/API behavior, and a concrete reproducible trace or vector.
+
+## 2. Review volume does not substitute for technical depth
+
+A large number of comments can create noise without increasing review quality. Future review should prioritize a few technically substantial findings over broad issue enumeration.
+
+## 3. Withdrawn claims should not be defended
+
+Once a claim is contradicted by the actual interface or implementation, the correct action is to withdraw it and record why it failed. Continuing to defend a falsified hypothesis weakens both the review and the evidence process.
+
+## 4. A non-novel point is not necessarily a wrong point
+
+The ChillDKG interoperability observation was valid as an interoperability concern, but it was already tracked in `BlockstreamResearch/bip-frost-dkg#157`. Future review must distinguish **incorrect**, **already tracked**, **already fixed**, and **newly demonstrated**.
+
+## 5. Verify exact API semantics before semantic critique
+
+The absent-versus-empty-message proposal failed because the message argument is mandatory and always present. Before constructing a semantic distinction, identify the precise function signature, normative argument requirements, and implementation path.
+
+## 6. Future public participation should clear a higher evidence bar
+
+A future public comment should be grounded in one extremely hard-to-dismiss technical point: exact specification text, exact implementation behavior, a minimal reproduction or vector, and an explanation of why existing tracking or documentation does not already resolve it.
+
+## 7. Research state must remain explicit
+
+The dossier uses evidence states so that an interesting hypothesis cannot silently become a finding. `UNVERIFIED`, `UNKNOWN`, and `CONFLICT` are legitimate research states and should remain visible until the evidence changes.
+
+## 8. The practical operating model
+
+The resulting working model is:
+
+```text
+Generate broadly with LLM assistance
+        ↓
+Narrow aggressively through falsification
+        ↓
+Verify specification + implementation + trace
+        ↓
+Check prior art / existing tracking
+        ↓
+Publish only durable findings
+```

docs/bip445-research/MAINTAINER-FEEDBACK.md

@@ -0,0 +1,34 @@
+# Maintainer Feedback
+
+This record preserves the significant maintainer feedback that changed the research process. Quotes below are recorded from the review discussion as supplied for this dossier; they are retained for methodological analysis, not to imply endorsement of this document.
+
+## Admin 1
+
+> “The message is a mandatory argument and thus always present.”
+
+**Classification:** Technical correction.
+
+The response invalidates the proposed absent-versus-zero-length message distinction because the interface requires the message argument to be present. The lesson is that an intuitive semantic distinction cannot be treated as a protocol issue without first checking the exact API contract and normative argument requirements.
+
+The same review history also identified the ChillDKG interoperability point as an already-tracked matter rather than a new issue. That makes the contribution non-novel on that point, not necessarily technically wrong.
+
+## Admin 2
+
+> “the contributions from @vitrixLab read like low-quality slop to me.”
+
+> “Please either step up the quality of your contributions or cease posting in this repository.”
+
+**Classification:** Process/credibility warning.
+
+The practical response is to pause public participation and raise the verification threshold. The warning is treated as feedback on contribution quality and review process, not as evidence that every substantive research point was incorrect.
+
+## Methodological response
+
+The appropriate response to this feedback is not to defend withdrawn claims. Instead:
+
+1. preserve the correction in the evidence record;
+2. distinguish invalid claims from valid but non-novel observations;
+3. verify future claims against normative text and implementation before publication; and
+4. return to public review only with a small number of technically hard-to-dismiss points.
+
+No maintainer endorsement of this dossier is claimed or implied.