docs: design and specify direct wallet transaction submission - #906
docs: design and specify direct wallet transaction submission#906czarcas7ic wants to merge 9 commits into
Conversation
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4851a6450e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Each participating node can expose the same `GetInfo` and `Submit` operations | ||
| over HTTPS. The adapter calls the same source-aware admission operation and | ||
| shares the native service's limits and result codes. |
There was a problem hiding this comment.
The native admission path can use the authenticated Zakura peer ID for its per-peer accounting, but an HTTPS request through Tor has no equivalent client identity: a clearnet endpoint sees a shared exit address, while an onion-service adapter generally sees the local Tor service, and a client-supplied identifier is freely rotatable. Therefore the HTTP adapter cannot simply call the same source-aware operation and preserve the promised per-peer/source-group fairness; it will either throttle unrelated Tor users together or let attackers reset their limits. Specify the HTTP source model and which limits apply before requiring shared admission semantics.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Lets save this for later
czarcas7ic
changed the title
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
1 participant
Motivation
Wallet submission depends on a small set of lightwalletd providers, concentrating submission metadata and availability with those operators.
Solution
Add the design and specification for direct wallet submission through discovered Zakura P2P v2 nodes, using the existing mempool and gossip pipeline. The spec defines the wire contract, admission results, and initial wallet defaults while retaining lightwalletd fallback.
Regulation integration and node budgets remain pending the GetBlocks work. Tor continues through lightwalletd until the separate HTTP follow-on is available.
Testing
Markdown lint, codespell, document reference checks, wire size/vector checks, and staged whitespace checks passed. Cursor reports no errors or warnings. Runtime tests were not run because this PR changes documentation only.
Changelog
Not required for a documentation-only change.