Skip to content

Conversation

@cobratbq
Copy link

@cobratbq cobratbq commented Nov 2, 2025

Updates to documentation for External Signer.

  • Added mention that signtransaction command is no longer primary mechanism.
  • Document inter-process communication via --stdin flag followed with stdin-content.
  • Document signtx command followed by Base64-encoded PSBT.

Best to squash commits when ready to merge.

@DrahtBot DrahtBot added the Docs label Nov 2, 2025
@DrahtBot
Copy link
Contributor

DrahtBot commented Nov 2, 2025

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33765.

Reviews

See the guideline for information on the review process.

Type Reviewers
ACK Sjors

If your review is incorrectly listed, please copy-paste <!--meta-tag:bot-skip--> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #33112 (wallet: relax external_signer flag constraints by Sjors)
  • #30354 (doc: external-signer, example 'createwallet' RPC call requires eight argument by cobratbq)

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:

  • "being written to external-signer process directly through stdin" -> "being written to the external-signer process directly through stdin" [missing definite article "the" makes the phrase slightly ungrammatical]
  • "This command reads request signtx <base64-encoded psbt> from stdin" -> "This command reads a request signtx <base64-encoded psbt> from stdin" [missing article "a" before "request" makes the sentence ungrammatical]

No other typographic or grammatical errors that impact comprehension were found.

2025-12-10

Copy link
Member

@Sjors Sjors left a 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.

@cobratbq
Copy link
Author

Good idea to update these docs.

Yes ... I was inspired by a certain #31005 (comment)

@cobratbq cobratbq force-pushed the external-signer-docs branch from 2b7c47c to e1d431c Compare November 11, 2025 22:19
@cobratbq cobratbq changed the title doc: update interface, --stdin flag, IPC-command signtx (#31005) doc: update interface, --stdin flag, signtx (#31005) Nov 17, 2025
@maflcko
Copy link
Member

maflcko commented Nov 26, 2025

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 a article makes sense.

@cobratbq cobratbq force-pushed the external-signer-docs branch from 58dc933 to 94a26e8 Compare November 26, 2025 19:12
@cobratbq
Copy link
Author

@maflcko I expected that someone would squash upon integrating the work. Now squashed.
I included some of the changes from #33947, though not verbatim. It may be worth checking the changes again, as a whole.

Copy link
Member

@Sjors Sjors left a 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.
Copy link
Member

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.

Copy link
Author

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?

Copy link
Member

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.


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.
Copy link
Member

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 error with value null is ignored,

Is this a known HWI bug? Otherwise it doesn't seem worth bringing up and client software shouldn't do this.

Copy link
Author

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.

Copy link
Author

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.
Copy link
Member

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?

Copy link
Author

@cobratbq cobratbq Dec 10, 2025

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.

@cobratbq cobratbq force-pushed the external-signer-docs branch from 8f6f147 to 9ca7a84 Compare December 10, 2025 17:35
@cobratbq cobratbq force-pushed the external-signer-docs branch from 9ca7a84 to 15da876 Compare December 10, 2025 18:22
@cobratbq
Copy link
Author

cobratbq commented Dec 10, 2025

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.

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.

@Sjors
Copy link
Member

Sjors commented Dec 12, 2025

@cobratbq there's certainly no need to sign commits, but when people do sign, it's nice that we don't break the signature.

Copy link
Member

@Sjors Sjors left a 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).
Copy link
Member

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.
Copy link
Member

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`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add testnet4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants