-
Notifications
You must be signed in to change notification settings - Fork 38.6k
doc: update interface, --stdin flag, signtx (#31005)
#33765
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code Coverage & BenchmarksFor details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33765. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please copy-paste ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. LLM Linter (✨ experimental)Possible typos and grammar issues:
No other typographic or grammatical errors that impact comprehension were found. 2025-12-10 |
Sjors
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea to update these docs.
Yes ... I was inspired by a certain #31005 (comment) |
2b7c47c to
e1d431c
Compare
signtx (#31005)
|
Please use unique, descriptive commit message, or squash your commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits. Also, there are a few LLM linter comments. Not sure if they all apply, but the missing |
58dc933 to
94a26e8
Compare
94a26e8 to
8f6f147
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks mostly good, but some text seems off or needlessly verbose.
I expected that someone would squash upon integrating the work.
Maintainers don't touch the original commits, which is especially nice if you GPG sign them.
Whenever you push an update, just squash the changes right away, reviewers will figure out how to view the diff.
| ``` | ||
|
|
||
| ## Signer API | ||
|
|
||
| In order to be compatible with Bitcoin Core any signer command should conform to the specification below. This specification is subject to change. Ideally a BIP should propose a standard so that other wallets can also make use of it. | ||
| More recent versions of Bitcoin, around v29 and later, have made significant improvements. It is recommended to use more recent versions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the goal here is to specify the minimum Bitcoin Core version that's compatible with the API described here. If so, let's say that specifically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope. I do not have sufficient knowledge of Bitcoin Core to state this. Do you have an idea? My goal is to emphasize that older versions behaved differently and less refined, such that there is benefit to start using external-signers with recent Bitcoin versions.
Maybe we should just leave it out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, let's leave it out.
doc/external-signer.md
Outdated
|
|
||
| The `psbt` SHOULD include bip32 derivations. The command SHOULD fail if none of the bip32 derivations match a key owned by the device. | ||
| The command reads the request from stdin and MUST return a JSON object. On success, it MUST contain `{"psbt": "<base64_psbt>"}` updated to include any new signatures. On failure, it SHOULD contain `{"error": "<message>"}`. A key `error` with value `null` is ignored, therefore interpreted as not an error. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The command reads the request from stdin
You already cover this in the general section about stdin.
and MUST return a JSON object
All commands do.
On success, it MUST contain ... as not an err
This seems needlessly verbose.
A key
errorwith valuenullis ignored,
Is this a known HWI bug? Otherwise it doesn't seem worth bringing up and client software shouldn't do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not so. Not all commands are expected to interact via stdin. signtx does interact via stdin. I removed another sections, but left on the "On success ..". Based on what is it verbose, because I am not otherwise familiar with Bitcoin Core RPC and I find it useful to have these bits of behavior made explicit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My involvement is not through HWI. I want to emphasize that presence of error in a successful result is not an issue if "error": null.
| The `psbt` SHOULD include bip32 derivations. The command SHOULD fail if none of the bip32 derivations match a key owned by the device. | ||
| The command reads the request from stdin and MUST return a JSON object. On success, it MUST contain `{"psbt": "<base64_psbt>"}` updated to include any new signatures. On failure, it SHOULD contain `{"error": "<message>"}`. A key `error` with value `null` is ignored, therefore interpreted as not an error. | ||
|
|
||
| PSBT-content SHOULD include BIP32-derivations. The command SHOULD fail if none of the BIP32-derivations match a key owned by the device. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any hardware wallet that can sign without BIP32 derivations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not all of the text is by my own judgement. However, you might leave out BIP-32 derivations for keys not under own management. Technically, those would never be expected to be signed with this call to external-signer.
8f6f147 to
9ca7a84
Compare
…ntx, contains updates from bitcoin#33947
9ca7a84 to
15da876
Compare
That is a fair point. I could sign, but it feels like unnecessarily blowing up the size of a minor contribution. update I did a second push that rebases PR to current master. |
|
@cobratbq there's certainly no need to sign commits, but when people do sign, it's nice that we don't break the signature. |
Sjors
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 15da876
|
|
||
| Bitcoin Core can be launched with `-signer=<cmd>` where `<cmd>` is an external tool which can sign transactions and perform other functions. For example, it can be used to communicate with a hardware wallet. | ||
|
|
||
| Interaction with external signer is built upon a specialized construct [Partially Signed Bitcoin Transaction (PSBT)](psbt.md). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"is built upon a specialized construct" -> "uses"?
| ``` | ||
|
|
||
| ## Signer API | ||
|
|
||
| In order to be compatible with Bitcoin Core any signer command should conform to the specification below. This specification is subject to change. Ideally a BIP should propose a standard so that other wallets can also make use of it. | ||
| More recent versions of Bitcoin, around v29 and later, have made significant improvements. It is recommended to use more recent versions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, let's leave it out.
|
|
||
| ### Flag `--chain <name>` (required) | ||
|
|
||
| With `<name>` one of `main`, `test`, `signet`, `regtest`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add testnet4
Updates to documentation for External Signer.
signtransactioncommand is no longer primary mechanism.--stdinflag followed with stdin-content.signtxcommand followed by Base64-encoded PSBT.Best to squash commits when ready to merge.