A BIP 174 PSBT may contain an extended key for deriving input and output addresses. This document proposes an additional field for PSBTs to represent arbitrary BIP 380 output script descriptors.
To support transfer of output descriptors outside signing flows, the proposal makes the unsigned transaction optional.
I don't think PSBT is the right way to be doing this. Descriptors are not necessary in PSBT, and relaxing the invariant that a PSBT represents a transaction (by allowing a PSBT to include no transaction data) would break many parsers and also just is antithetical to PSBT. It's not a general purpose format for sending data around - you could use protobuf if you wanted that.
If the goal is to have a machine parsable representation of descriptors, then by all means, do that. But it doesn't need to (nor do I think it should) interact with PSBT, other than having a different header that identifies it.
It's also unnecessary to have a descriptor in a PSBT. A PSBT can contain all of the data to derive it from the scriptPubKey at a later time. If an updater has the descriptor in order to put it in the PSBT, then it can also put the rest of the data in the PSBT so that the descriptor can be inferred. I just don't see how this proposal is at all useful.
Also, descriptors are a textual format, and encoding text in binary is just not very efficient. There are better ways to do that if you really wanted to.
I don't think PSBT is the right way to be doing this. Descriptors are not necessary in PSBT, and relaxing the invariant that a PSBT represents a transaction (by allowing a PSBT to include no transaction data) would break many parsers and also just is antithetical to PSBT. It's not a general purpose format for sending data around - you could use protobuf if you wanted that.
If the goal is to have a machine parsable representation of descriptors, then by all means, do that. But it doesn't need to (nor do I think it should) interact with PSBT, other than having a different header that identifies it.
FWIW, the first draft was indeed PSBT with a different header: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022184.html. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022186.html suggested we add descriptors to PSBT proper, which seemed like a good idea.
Would you support an alternative BIP that changed the header to make it intentionally different from PSBT files?
It's also unnecessary to have a descriptor in a PSBT. A PSBT can contain all of the data to derive it from the scriptPubKey at a later time. If an updater has the descriptor in order to put it in the PSBT, then it can also put the rest of the data in the PSBT so that the descriptor can be inferred.
How can the scriptPubKey infer a descriptor that contains, say, a key expression that ends in '/*'?
I just don't see how this proposal is at all useful.
The point of the BIP is to transfer descriptors between devices, in particular between a coordinator and (resource constrained) signing devices. It can be viewed as a codec for wallet policies.
Today, there exists a plethora of formats for exchanging descriptors, all with downsides:
This proposal addresses them all:
Also, descriptors are a textual format, and encoding text in binary is just not very efficient. There are better ways to do that if you really wanted to.
We believe it's hopeless to keep a binary representation of output descriptors up to date with the moving target that is textual bip-380 descriptors (BCR-2020-010 attempted but failed). This BIP (along with wallet policies) address the worst offender by encoding extended keys efficiently.
Would you support an alternative BIP that changed the header to make it intentionally different from PSBT files?
That would be fine with me.
How can the
scriptPubKeyinfer a descriptor that contains, say, a key expression that ends in '/*'?
Although /* cannot be directly inferred, you can still make an educated guess. It only affects the ends of derivation paths from xpubs, so the last derivation index of a key expression with an xpub could just be replaced with /*. Although descriptors allow for xpubs without a /*, it seems unlikely to me that that would actually be used in practice.
But I don't understand why you'd need to have the parent descriptor at all. You'll have enough key origin information to derive any private keys and be able to sign.
This proposal aims to extend the capabilities of PSBTs by incorporating support for output script descriptors while also offering flexibility regarding the inclusion of the unsigned transaction within the PSBT structure. These enhancements could streamline certain Bitcoin transaction workflows and facilitate interoperability among different wallet implementations.
BIP 174 PSBTs and Extended Keys: PSBTs, specified in BIP 174, are a format for partially signed Bitcoin transactions, enabling offline signing and multi-party approval workflows. These transactions may contain extended keys for deriving input and output addresses. Extended keys allow for hierarchical deterministic (HD) wallets, where multiple addresses can be derived from a single master key.
Introduction of Output Script Descriptors: The proposal suggests introducing an additional field in PSBTs to represent arbitrary BIP 380 output script descriptors. Output script descriptors, specified in BIP 380, provide a concise way to describe various types of output scripts. This addition would enhance the flexibility and interoperability of PSBTs, allowing for more complex transaction scripts.
Optional Unsigned Transaction: Traditionally, PSBTs include the unsigned transaction itself. However, this proposal suggests making the unsigned transaction optional. This change would allow for the transfer of output descriptors outside of the signing process, potentially simplifying certain workflows or reducing data redundancy.
But I don't understand why you'd need to have the parent descriptor at all. You'll have enough key origin information to derive any private keys and be able to sign.
By example in the current ledger miniscript signing flow, the hardware device produce a Proof of Registration (PoR) against the parent descriptor that is stored by the softwarewallet (in order to keep stateless) the first time the descriptor is checked by user on signer side, then every time the software wallet send a psbt to sign to ledger device, it should also supply also the parent descriptor and PoR.
we previously discuss about this here
cc @bigspider
Hardware signing devices need knowledge of the full descriptor/wallet policy in order to:
(The second could perhaps be considered a strengthening of the traditional guarantees of hardware signers, not sure if it was ever formalized before wallet policies; I think it's essential in practice for anything that is not single-user)
While it's true that PSBTs today have enough info to sign, they do not have enough info to do it securely - the descriptor is also needed. Therefore, I agree that it would be a great improvement to be able to pass this info via PSBTs; currently, the Ledger app's signing flow is sign(PSBT, wallet_policy), and quite some work in the app goes into figuring out change/address_index for each input and change output based on the derivations in the PSBT.
However, I think that's a separate discussion, and it's unclear that recycling PSBTs for a purpose other than representing transactions brings any benefit over than directly designing a space-efficient encoding specifically for descriptors or wallet policies – if the <30% space saving that can be obtained with a re-encoding is deemed important in practice.
@seedhammer, do you plan to update here based on the review feedback?
Thanks for the prod, @jonatack . I've updated the proposal so it's no longer a PSBT extension but a separate format merely based on PSBT key-value maps.
I'd like to add proof-of-registration (PoR), but I'm not sure how it's best done. There's some discussion at https://github.com/wizardsardine/liana/issues/539#issuecomment-1877372827, where @bigspider suggests a HMAC scheme and in a later post @pythcoiner suggest that the format of PoR field should be vendor defined. I'm still of the position that to be maximally useful and interoperable, the PoR field should have a defined format and be a signature, not a HMAC.
I'd like to add proof-of-registration (PoR), but I'm not sure how it's best done. There's some discussion at wizardsardine/liana#539 (comment), where @bigspider suggests a HMAC scheme and in a later post @pythcoiner suggest that the format of PoR field should be vendor defined. I'm still of the position that to be maximally useful and interoperable, the PoR field should have a defined format and be a signature, not a HMAC.
As i already said in previous discussion, i do not have strong opinion about wether the PoR should be standardized or not, but i do not think it should be standardized in this BIP.
And anyway if i get it well both sheme (HMAC vs Signature) will be 32 bytes of data?
it should be interesting to have insight from other signing devices teams.
cc @benma @scgbckbone @stepansnigirev @stepansnigirev @JamieDriver
Also @kdmukai. Maybe others?
However, I think that's a separate discussion, and it's unclear that recycling PSBTs for a purpose other than representing transactions brings any benefit over than directly designing a space-efficient encoding specifically for descriptors or wallet policies – if the <30% space saving that can be obtained with a re-encoding is deemed important in practice.
I want to point out that while saving space is important to us, the ability to add metadata and eventually proof-of-registration is the more interesting feature in general.
I am in agreement with @bigspider's comment above.
BitBox02 libraries have functions like sign_psbt(psbt, wallet_policy) (example), and the policy/descriptor is required for anything but simple single-sigs.
It would be helpful if the way the policy is described and transferred to signers was standardized so apps don't have to implement different ways to interface with different signers.
PSBT seems like the obvious location to put this information. Another format that contains both the PSBT and the policy, which is interoperable with all software, seems difficult to achieve and impractical.
Given
Perhaps it's feasible to keep the formats separate, but concatenate them at the transport layer (QR code, files), in a backwards compatible way? Say, append the decriptor at the end of the PSBT, where devices without knowledge of descriptors may parse the PSBT and ignore the rest?
0 | @@ -0,0 +1,139 @@ 1 | +<pre> 2 | + BIP: ? 3 | + Layer: Applications 4 | + Title: Binary Output Descriptors 5 | + Author: SeedHammer <team@seedhammer.com> 6 | + License: BSD-2-Clause
The preamble is missing a few mandatory headers:
BIP: ?
Layer: Applications
Title: Binary Output Descriptors
Author: SeedHammer <team@seedhammer.com>
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-seedhammer-binary-output-descriptors
Status: Draft
Type: Standards Track
Created: YYYY-MM-DD
License: BSD-2-Clause
I have only lightly reviewed this document.
It sounds to me that there is still some discussion what solution is exactly to be pursued for this document. I’m going to change this to a draft PR for the moment, please set it ready to merge when the proposal is a bit more mature.
Please note that you will need a Backwards Compatibility section, and without going into the content in detail, it seems to me that the Rationale section could be a bit more extensive.
Thanks, Murch. I've added the mandatory headers, added a compatibility section, and expanded the rationale section.
It seems to me that the main source of contention is whether the format should be separate or part of PSBT. While convenient to extend PSBT, it's probably best to separate the format if for nothing else than descriptors are useful outside signing flows.
Proof of registration can wait for a future extension BIP, as suggested by @pythcoiner.
Thanks, Murch. I've added the mandatory headers, added a compatibility section, and expanded the rationale section.
It seems to me that the main source of contention is whether the format should be separate or part of PSBT. While convenient to extend PSBT, it's probably best to separate the format if for nothing else than descriptors are useful outside signing flows.
Proof of registration can wait for a future extension BIP, as suggested by @pythcoiner.
To be more accurate, i think how is processed the PoR should de defined in a separate BIP, but having an optional key-value pair defined in this BIP should be useful imho.
Thanks, Murch. I've added the mandatory headers, added a compatibility section, and expanded the rationale section. It seems to me that the main source of contention is whether the format should be separate or part of PSBT. While convenient to extend PSBT, it's probably best to separate the format if for nothing else than descriptors are useful outside signing flows. Proof of registration can wait for a future extension BIP, as suggested by @pythcoiner.
To be more accurate, i think
howis processed the PoR should de defined in a separate BIP, but having anoptionalkey-value pair defined in this BIP should be useful imho.
Good point. Done.
I'm very much PRO descriptors directly IN PSBTs. Even tho I understand @achow101 comments.
Regardless of the format here (which i haven't studied) it is useful to have descriptor (or at least policy) in PSBT. Example from Coldcard is when you want to have multiple miniscripts registered on device that have identical keys in miniscript but policy/script is different. Or same keys same policy but order of keys in policy is different. Here you just cannot infer solely from PSBT which wallet to use because keys match for all wallets...
why not just use PSBT_GLOBAL_PROPRIETARY key and send descriptor in there?
I'm very much PRO descriptors directly IN PSBTs. Even tho I understand @achow101 comments.
Descriptors in PSBTs are useful, but descriptors are also useful outside PSBTs: transferring descriptors between wallets, (long term) backups. It would be unfortunate to specify a descriptor format that only solved the signing use-cases.
why not just use
PSBT_GLOBAL_PROPRIETARYkey and send descriptor in there?
That would hijack PSBT_GLOBAL_PROPRIETARY, leaving it no longer available for vendor-specific uses.
26 | +===Motivation=== 27 | + 28 | +A BIP 380 output descriptor is a textual representation of a set of output 29 | +scripts, such that Bitcoin wallets may agree on the scripts and addresses 30 | +to provide the user. However, a descriptor string by itself is not ideal for 31 | +transferring between wallets: it lacks a machine recognizable header, cannot
transferring between wallets: it lacks a machine-recognizable header, cannot
30 | +to provide the user. However, a descriptor string by itself is not ideal for 31 | +transferring between wallets: it lacks a machine recognizable header, cannot 32 | +represent metadata such as name and birth block, and its use of base58 for 33 | +extended keys is inefficient. 34 | + 35 | +BIP 174 gives us a self-describing file format, metadata as well as a compact,
BIP 174 gives us a self-describing file format, metadata, and a compact,
31 | +transferring between wallets: it lacks a machine recognizable header, cannot 32 | +represent metadata such as name and birth block, and its use of base58 for 33 | +extended keys is inefficient. 34 | + 35 | +BIP 174 gives us a self-describing file format, metadata as well as a compact, 36 | +binary representation of keys. Assuming most wallets already implements the PSBT
binary representation of keys. Assuming most wallets already implement the PSBT
40 | +are useful outside of signing flows (backup, initializing wallet 41 | +software).</ref> 42 | +<ref> '''Why not use the older Blockchain Commons BCR-2020-010 format?''' 43 | +The format was [[https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md#deprecated-superseded-by-version-3-output-descriptors|recently deprecated]], 44 | +because its use of reserved CBOR tags.</ref> 45 | +<ref>'''Why not use the new Blockchain Commons BCR-2023-010 format?'''
<ref>'''Why not use the new Blockchain Commons BCR-2023-010 format?'''.
On second thought, I reverted this suggestion. None of the other rationale headings have periods.
Grazie.
39 | +The PSBT format is not a general purpose container format, and descriptors 40 | +are useful outside of signing flows (backup, initializing wallet 41 | +software).</ref> 42 | +<ref> '''Why not use the older Blockchain Commons BCR-2020-010 format?''' 43 | +The format was [[https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md#deprecated-superseded-by-version-3-output-descriptors|recently deprecated]], 44 | +because its use of reserved CBOR tags.</ref>
due to its use of reserved CBOR tags.</ref>
or "because of"
34 | + 35 | +BIP 174 gives us a self-describing file format, metadata as well as a compact, 36 | +binary representation of keys. Assuming most wallets already implements the PSBT 37 | +format, the implementation overhead of this BIP is expected to be low 38 | +<ref> '''Why not extend BIP 174?''' 39 | +The PSBT format is not a general purpose container format, and descriptors
The PSBT format is not a general-purpose container format, and descriptors
50 | +In particular, we believe BCR-2023-010 would have faced opposition 51 | +in the BIP process because it is based on the [[https://cbor.io/spec.html|CBOR encoding]]. 52 | +CBOR is designed for generality and compactness and is therefore significantly 53 | +more complex than the PSBT encoding. In contrast, the PSBT key-value maps are 54 | +supported by all wallet software that interact with PSBT files, are easier to 55 | +review and fit in embedded devices.
review, and they fit in embedded devices.
52 | +CBOR is designed for generality and compactness and is therefore significantly 53 | +more complex than the PSBT encoding. In contrast, the PSBT key-value maps are 54 | +supported by all wallet software that interact with PSBT files, are easier to 55 | +review and fit in embedded devices. 56 | + 57 | +Release in late 2023, BCR-2023-010 doesn't event have the advantage of widespread
Released in late 2023, BCR-2023-010 doesn't even have the advantage of widespread
Removed the superfluous word.
53 | +more complex than the PSBT encoding. In contrast, the PSBT key-value maps are 54 | +supported by all wallet software that interact with PSBT files, are easier to 55 | +review and fit in embedded devices. 56 | + 57 | +Release in late 2023, BCR-2023-010 doesn't event have the advantage of widespread 58 | +support.</ref>.
support at the time of this writing.</ref>.
58 | +support.</ref>. 59 | + 60 | +==Specification== 61 | + 62 | +The Binary Output Descriptor (BOD) format consists of a fixed header, a 63 | +key-value map describing the output descriptor and its metadata followed by a
It might be clearer to add a comma either after "descriptor" or "metadata", depending on the intended meaning.
Removed the mention of metadata, since it's clear from the detailed specification.
85 | +| <tt><compact size uint birth block><bytes></tt> 86 | +| The earliest block height that may contain transactions for the descriptor, optionally followed by the UTF-8 encoded name of the descriptor. 87 | +| <tt><bytes descriptor></tt> 88 | +| The output descriptor in BIP 380 format without inline keys<ref>''Why not encode the descriptor in binary?''' 89 | +The BIP 380 descriptor language is complicated and expanding and we believe 90 | +the efforts of designing a parallel binary encoding does not outweigh the
the effort of designing a parallel binary encoding does not outweigh the
(This sentence could be more clearly written, as well.)
Thanks. Rewritten.
88 | +| The output descriptor in BIP 380 format without inline keys<ref>''Why not encode the descriptor in binary?''' 89 | +The BIP 380 descriptor language is complicated and expanding and we believe 90 | +the efforts of designing a parallel binary encoding does not outweigh the 91 | +space savings. 92 | + 93 | +The major source of bloat, base58 encoded keys, are binary encoded for compactness and
The major source of bloat, base58-encoded keys, are binary encoded for compactness and
84 | +| <tt>BOD_GLOBAL_OUTPUT_DESCRIPTOR = 0x00</tt> 85 | +| <tt><compact size uint birth block><bytes></tt> 86 | +| The earliest block height that may contain transactions for the descriptor, optionally followed by the UTF-8 encoded name of the descriptor. 87 | +| <tt><bytes descriptor></tt> 88 | +| The output descriptor in BIP 380 format without inline keys<ref>''Why not encode the descriptor in binary?''' 89 | +The BIP 380 descriptor language is complicated and expanding and we believe
The BIP 380 descriptor language is complicated and expanding, and we believe
Thanks. Rewrote the paragraph.
95 | +.</ref> 96 | +|- 97 | +| Proprietary Use Type 98 | +| <tt>BOD_GLOBAL_PROPRIETARY = 0xFC</tt> 99 | +| <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt> 100 | +| Compact size unsigned integer of the length of the identifier, followed by identifier prefix, followed by a compact size unsigned integer subtype, followed by the key data itself.
Suggest using an article for each item or for none.
| A compact size unsigned integer of the length of the identifier, followed by an identifier prefix, followed by a compact size unsigned integer subtype, followed by the key data itself.
103 | +|} 104 | + 105 | +It is an error to omit the BOD_GLOBAL_OUTPUT_DESCRIPTOR entry. 106 | + 107 | +All key expressions in the BOD_GLOBAL_OUTPUT_DESCRIPTOR descriptor string must be 108 | +specified as references on the form <tt>@<index></tt> where <tt>index</tt> is
IIUC
specified as references in the form of <tt>@<index></tt> where <tt>index</tt> is
130 | +! <tt><valuedata></tt> Description 131 | +|- 132 | +| Extended Public Key 133 | +| <tt>BOD_KEY_XPUB = 0x00</tt> 134 | +| <tt><bytes xpub></tt> 135 | +| The 78 byte serialized extended public key as defined by BIP 32.
| The 78-byte serialized extended public key, as defined by BIP 32.
132 | +| Extended Public Key 133 | +| <tt>BOD_KEY_XPUB = 0x00</tt> 134 | +| <tt><bytes xpub></tt> 135 | +| The 78 byte serialized extended public key as defined by BIP 32. 136 | +| <tt><4 byte fingerprint> <32-bit little endian uint path element>*</tt> 137 | +| The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key.
| The master key fingerprint, as defined by BIP 32, concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32-bit unsigned integer indexes must match the depth provided in the extended public key.
137 | +| The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key. 138 | +|- 139 | +| Proprietary Use Type 140 | +| <tt>BOD_KEY_PROPRIETARY = 0xFC</tt> 141 | +| <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt> 142 | +| Compact size unsigned integer of the length of the identifier, followed by identifier prefix, followed by a compact size unsigned integer subtype, followed by the key data itself.
idem
| A compact size unsigned integer of the length of the identifier, followed by an identifier prefix, followed by a compact size unsigned integer subtype, followed by the key data itself.
151 | +A descriptor with a key reference out of bounds. 152 | + Descriptor: wpkh(@0/*) 153 | + Hex encoded BOD: 70736274ff0207000a77706b682840302f2a29000000 154 | + 155 | +A descriptor with an invalid UTF-8 name. 156 | + Hex encoded BOD: 70736274ff05070061c57a0a77706b682840302f2a2953010488b21e041c0ae906800000025afed56d755c088320ec9bc6acd84d33737b580083759e0a0ff8f26e429e0b77028342f5f7773f6fab374e1c2d3ccdba26bc0933fc4f63828b662b4357e4cc3791bec0fbd814c5d8729748000080000000800000008002000080000000
Hex-encoded BOD: 70736274ff05070061c57a0a77706b682840302f2a2953010488b21e041c0ae906800000025afed56d755c088320ec9bc6acd84d33737b580083759e0a0ff8f26e429e0b77028342f5f7773f6fab374e1c2d3ccdba26bc0933fc4f63828b662b4357e4cc3791bec0fbd814c5d8729748000080000000800000008002000080000000
154 | + 155 | +A descriptor with an invalid UTF-8 name. 156 | + Hex encoded BOD: 70736274ff05070061c57a0a77706b682840302f2a2953010488b21e041c0ae906800000025afed56d755c088320ec9bc6acd84d33737b580083759e0a0ff8f26e429e0b77028342f5f7773f6fab374e1c2d3ccdba26bc0933fc4f63828b662b4357e4cc3791bec0fbd814c5d8729748000080000000800000008002000080000000 157 | + 158 | +A descriptor with an inline key. 159 | + Hex encoded BOD: 70736274ff0207008e77706b68285b64633536373237362f3438682f30682f30682f32685d7870756236446959726652774e6e6a655834764873574d616a4a56464b726245456e753867415739764475517a675457457345484531367347576558585556314c42575145317943546d657072534e63715a3357373468715664674462745948557633654d3457325445556870616e2f2a29000000
Hex-encoded BOD: 70736274ff0207008e77706b68285b64633536373237362f3438682f30682f30682f32685d7870756236446959726652774e6e6a655834764873574d616a4a56464b726245456e753867415739764475517a675457457345484531367347576558585556314c42575145317943546d657072534e63715a3357373468715664674462745948557633654d3457325445556870616e2f2a29000000
165 | + Name: Satoshi's Stash 166 | + Birth block: 123456789012345 167 | + Key 0: [dc567276/48h/0h/0h/2h]xpub6DiYrfRwNnjeX4vHsWMajJVFKrbEEnu8gAW9vDuQzgTWEsEHE16sGWeXXUV1LBWQE1yCTmeprSNcqZ3W74hqVdgDbtYHUv3eM4W2TEUhpan 168 | + Key 1: [f245ae38/48h/0h/0h/2h]xpub6DnT4E1fT8VxuAZW29avMjr5i99aYTHBp9d7fiLnpL5t4JEprQqPMbTw7k7rh5tZZ2F5g8PJpssqrZoebzBChaiJrmEvWwUTEMAbHsY39Ge 169 | + Key 2: [c5d87297/48h/0h/0h/2h]xpub6DjrnfAyuonMaboEb3ZQZzhQ2ZEgaKV2r64BFmqymZqJqviLTe1JzMr2X2RfQF892RH7MyYUbcy77R7pPu1P71xoj8cDUMNhAMGYzKR4noZ 170 | + Hex encoded BOD: 70736274ff1907ff79df0d86487000005361746f73686927732053746173683477736828736f727465646d756c746928322c40302f3c303b313e2f2a2c40312f3c303b313e2f2a2c40322f3c303b313e2f2a292953010488b21e0418f8c2e7800000026b3a4cfb6a45f6305efe6e0e976b5d26ba27f7c344d7fc7abef7be2d06d52dfd021c0b479ecf6e67713ddf0c43b634592f51c037b6f951fb1dc6361a98b1e5735e0f8b515314dc5672764800008000000080000000800200008053010488b21e04221eb5a080000002c887c72d9d8ac29cddd5b2b060e8b0239039a149c784abe6079e24445db4aa8a0397fcf2274abd243d42d42d3c248608c6d1935efca46138afef43af08e971289657009d2b14f245ae384800008000000080000000800200008053010488b21e041c0ae906800000025afed56d755c088320ec9bc6acd84d33737b580083759e0a0ff8f26e429e0b77028342f5f7773f6fab374e1c2d3ccdba26bc0933fc4f63828b662b4357e4cc3791bec0fbd814c5d8729748000080000000800000008002000080000000
Hex-encoded BOD: 70736274ff1907ff79df0d86487000005361746f73686927732053746173683477736828736f727465646d756c746928322c40302f3c303b313e2f2a2c40312f3c303b313e2f2a2c40322f3c303b313e2f2a292953010488b21e0418f8c2e7800000026b3a4cfb6a45f6305efe6e0e976b5d26ba27f7c344d7fc7abef7be2d06d52dfd021c0b479ecf6e67713ddf0c43b634592f51c037b6f951fb1dc6361a98b1e5735e0f8b515314dc5672764800008000000080000000800200008053010488b21e04221eb5a080000002c887c72d9d8ac29cddd5b2b060e8b0239039a149c784abe6079e24445db4aa8a0397fcf2274abd243d42d42d3c248608c6d1935efca46138afef43af08e971289657009d2b14f245ae384800008000000080000000800200008053010488b21e041c0ae906800000025afed56d755c088320ec9bc6acd84d33737b580083759e0a0ff8f26e429e0b77028342f5f7773f6fab374e1c2d3ccdba26bc0933fc4f63828b662b4357e4cc3791bec0fbd814c5d8729748000080000000800000008002000080000000
173 | + 174 | +<references/> 175 | + 176 | +==Compatibility== 177 | + 178 | +This is a new format and as such have no campatibility burden.
This is a new format and as such has no compatibility burden.
A few review suggestions follow for the BIP text.
Hey, wanted to check in to ask what the status with this proposal is. Was there progress on determining the direction it is being developed? Is it ready for an editor review? Please let us know if we can help.
We're (still) interested in pushing this proposal forward, given enough interest from one or more signing device vendors.
I am very interested in this, and my previous comment is still my opinion today.
100 | +| A compact size unsigned integer of the length of the identifier, followed by an identifier prefix, followed by a compact size unsigned integer subtype, followed by the key data itself. 101 | +| <tt><bytes data></tt> 102 | +| Any value data as defined by the proprietary type user. 103 | +|} 104 | + 105 | +It is an error to omit the BOD_GLOBAL_OUTPUT_DESCRIPTOR entry.
An error in which stage? It seems like this should still be optional. For example, for regular single-sig transactions (and even multisig if the global xpub field is populated), one can infer the descriptor.
The descriptor field is mandatory if we assume the format is separate from PSBT (albeit similar structure). See previous comment.
140 | +| <tt>BOD_KEY_PROPRIETARY = 0xFC</tt> 141 | +| <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt> 142 | +| A compact size unsigned integer of the length of the identifier, followed by an identifier prefix, followed by a compact size unsigned integer subtype, followed by the key data itself. 143 | +| <tt><bytes data></tt> 144 | +| Any value data as defined by the proprietary type user. 145 | +|}
What's the purpose of this?
Avere un buon sviluppo, consenti una buona gestione del prodotto!!!
It serves the same purpose as PSBT_GLOBAL_PROPRIETARY. Again, assuming separate formats.
79 | +! <tt><keydata></tt> Description 80 | +! <tt><valuedata></tt> 81 | +! <tt><valuedata></tt> Description 82 | +|- 83 | +| Output Descriptor 84 | +| <tt>BOD_GLOBAL_OUTPUT_DESCRIPTOR = 0x00</tt>
It would be beneficial if we could specify a list of output descriptors, not just one, for two reasons:
To achieve this, the global field could contain a list of all descriptors, and each input and output can reference one of them, e.g. by index.
Your comment seem to assume that this proposal expands signing PSBT with extra information.
As per #1548 (comment), the high-level issue blocking this proposal is whether to expand the PSBT format, or to create a new format (that happens to have similar structure). I don't think we can move forward without a decision either way.
FWIW, I lean towards separating the formats., given @achow101 et al insisting on PSBT being kept for signing use cases only (for good reasons).
Indeed that was my assumption, apologies. I should have read the full BIP again before commenting.
I lean strongly towards extending the PSBT format instead of creating a new format.
Sono di accordo Sono di accordo per eventuale sviluppo, credo che sia una buona descrizione.
13 | +==Introduction== 14 | + 15 | +===Abstract=== 16 | + 17 | +This document proposes an efficient encoding format for output descriptors as 18 | +defined by [[bip-0380.mediawiki|BIP 380]] and its extensions. Based on
Have you considered referencing BIP-388 instead? BIP-388 has similarities to the format you describe below, e.g. placeholder for keys (@0, [@1](/bitcoin-bips/contributor/1/), ...). Mentioning it here for awareness, but it is probably better to keep the descriptors in this BIP general, without the restrictions of BIP-388.
Sono di accordo.
BIP-388 is mentioned in the "acknowledgements" section, but I can add it here if you think it brings value.
Thank you for the review. As noted in the comments below, I believe the immediate next step for this proposal is to decide whether to extend PSBT or create a new format.
I'm in favour of a separate format to PSBT, as is currently defined by this PR. There is nothing here that refers to a transaction, and wallet setup and registration is an entirely different process to transaction creation. Having a separate format simplifies how this format is detected and how it can evolve to serve future needs.
One thing to consider is whether it is worth expanding this format to also be used for collecting keys during setup, similar to how a PSBT is used to collect signatures during signing. This would allow a coordinator to specify at minimum a derivation path, and for signers to add keys to the format until it is complete. AFAIK there is currently no single format which allows for this, which makes geographically distributed multisig setup more difficult or vendor specific.
Another consideration is adding a BOD_GLOBAL_VERSION global type to specify the version, allowing for future iterations.
I also suggest adding an Encoding section which includes the file extension when serialized to disk, as in BIP174.
@seedhammer, I updated the PR title to that of the current "Title" field in this draft. Could you please verify if the PR description is current, and update it, if not?
@seedhammer, any update on this proposal?
@jonatack yes, the title is good, thank you.
Assuming Craig is willing to implement the completed format in his coordinator software, I believe the next step is to find a hardware signer vendor to OK the proposal (in principle) and work with them to implement it.
We've been too busy to lead the process, and as such the BIP is in limbo. Can it be left in draft, or should it be closed?
@seedhammer: Revisiting this, it is not required for a BIP to be implemented before it can be merged in Draft status. If you feel that your proposal is at a point where you have no further planned work and the next step is adoption, it seems that this PR should be ready for Editor review.
SGTM. Thanks.
Whenever you are ready for editor review, please use the "Ready for review" button: <img width="923" height="360" alt="image" src="https://github.com/user-attachments/assets/f391353d-fdc9-4ba3-9df8-e21893f2be10" />
Ottimo lavoro.
81 | +! <tt><valuedata></tt> Description 82 | +|- 83 | +| Output Descriptor 84 | +| <tt>BOD_GLOBAL_OUTPUT_DESCRIPTOR = 0x00</tt> 85 | +| <tt><compact size uint birth block><bytes></tt> 86 | +| The earliest block height that may contain transactions for the descriptor, optionally followed by the UTF-8 encoded name of the descriptor.
I guess the block height is a fixed length here? Else how to know the length of the descriptor name?
83 | +| Output Descriptor 84 | +| <tt>BOD_GLOBAL_OUTPUT_DESCRIPTOR = 0x00</tt> 85 | +| <tt><compact size uint birth block><bytes></tt> 86 | +| The earliest block height that may contain transactions for the descriptor, optionally followed by the UTF-8 encoded name of the descriptor. 87 | +| <tt><bytes descriptor></tt> 88 | +| The output descriptor in BIP 380 format without inline keys<ref>''Why not encode the descriptor in binary?'''
| The output descriptor in BIP 380 format without inline keys<ref>'''Why not encode the descriptor in binary?'''
Done, thanks for noticing.
Thank you for your patience. My apologies for losing track of this pull request being in our court. This proposal looks very mature. Let’s call it BIP 391. If there isn’t any more review or planned work in a few days, we can aim to publish it.
I had a similar misunderstanding as @benma when reading this, and was wondering if you might want to explicitly state either in the Abstract or at the start of the Specification section that this data structure is meant to store exactly one descriptor.
Buongiorno,
Grazie mille per la disponibilità. Cordiali saluti.
Il Mar 27 Gen 2026, 16:18 murchandamus @.***> ha scritto:
@.**** commented on this pull request.
Thank you for your patience. My apologies for losing track of this pull request being in our court. This proposal looks very mature. Let’s call it BIP 391. If there isn’t any more review or planned work in a few days, we can aim to publish it.
I had a similar misunderstanding as @benma https://github.com/benma when reading this, and was wondering if you might want to explicitly state either in the Abstract or at the start of the Specification section that this data structure is meant to store exactly one descriptor.
In bip-bod-descriptors.mediawiki https://github.com/bitcoin/bips/pull/1548#discussion_r2729780941:
+The defined global types are as follows:
- +{| +! Name +! <tt><keytype></tt> +! <tt><keydata></tt> +! <tt><keydata></tt> Description +! <tt><valuedata></tt> +! <tt><valuedata></tt> Description +|- +| Output Descriptor +| <tt>BOD_GLOBAL_OUTPUT_DESCRIPTOR = 0x00</tt> +| <tt><compact size uint birth block><bytes></tt> +| The earliest block height that may contain transactions for the descriptor, optionally followed by the UTF-8 encoded name of the descriptor. +| <tt><bytes descriptor></tt> +| The output descriptor in BIP 380 format without inline keys<ref>''Why not encode the descriptor in binary?'''
⬇️ Suggested change
-| The output descriptor in BIP 380 format without inline keys<ref>''Why not encode the descriptor in binary?''' +| The output descriptor in BIP 380 format without inline keys<ref>'''Why not encode the descriptor in binary?'''
— Reply to this email directly, view it on GitHub https://github.com/bitcoin/bips/pull/1548#pullrequestreview-3708613941, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3RVZNNXCCLEQIBANUV5M6D4I56TLAVCNFSM6AAAAABZQHKB3KVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTOMBYGYYTGOJUGE . You are receiving this because you commented.Message ID: @.***>
5 | + Author: SeedHammer <team@seedhammer.com> 6 | + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-seedhammer-binary-output-descriptors 7 | + Status: Draft 8 | + Type: Standards Track 9 | + Created: 2024-01-31 10 | + License: BSD-2-Clause
Since BIP 3 was deployed recently, there are a few changes to the Preamble:
BIP: 391
Layer: Applications
Title: Binary Output Descriptors
Authors: SeedHammer <team@seedhammer.com>
Status: Draft
Type: Specification
Assigned: 2026-01-27
License: BSD-2-Clause
Done.
Could you please also add an entry for your proposal to the table in the README?
Mi poi aiutare?
Il Mar 27 Gen 2026, 16:57 murchandamus @.***> ha scritto:
@.**** commented on this pull request.
Could you please also add an entry for your proposal to the table in the README?
In bip-bod-descriptors.mediawiki https://github.com/bitcoin/bips/pull/1548#discussion_r2732708224:
- BIP: ?
- Layer: Applications
- Title: Binary Output Descriptors
- Author: SeedHammer @.***>
- Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-seedhammer-binary-output-descriptors
- Status: Draft
- Type: Standards Track
- Created: 2024-01-31
- License: BSD-2-Clause
Since BIP 3 was deployed recently, there are a few changes to the Preamble: ⬇️ Suggested change
- BIP: ?
- Layer: Applications
- Title: Binary Output Descriptors
- Author: SeedHammer @.***>
- Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-seedhammer-binary-output-descriptors
- Status: Draft
- Type: Standards Track
- Created: 2024-01-31
- License: BSD-2-Clause
- BIP: 391
- Layer: Applications
- Title: Binary Output Descriptors
- Authors: SeedHammer @.***>
- Status: Draft
- Type: Specification
- Assigned: 2026-01-27
- License: BSD-2-Clause
— Reply to this email directly, view it on GitHub https://github.com/bitcoin/bips/pull/1548#pullrequestreview-3712035948, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3RVZNKFRJSV3FKG3ESACET4I6DFDAVCNFSM6AAAAABZQHKB3KVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTOMJSGAZTKOJUHA . You are receiving this because you commented.Message ID: @.***>
I've clarified that the format contains one descriptor, renamed the proposal to bip-0391.mediawiki, revised the preamble and added it to the README.
This format has already stepped beyond what is strictly defined by an output descriptor through inclusion of a birthday block height. Given this you may wish to also consider other practical wallet recovery metadata such as
0)That said, I actually think it would be better to extend the output descriptor language with optional key/value parameters appended to the end so we have an extensible format as new practical requirements arise. I've described such a scheme briefly in this comment: #2047 (comment). In this case, including the birthday as a separate field here would be redundant and/or confusing.
@seedhammer: I was planning on publishing this document if there wasn’t any more activity for a couple days, so please let me know whether you want to make changes before it is published as Draft due to Craig’s feedback or whether you prefer to proceed with publication. Either way, a BIP in Draft could still be adjusted after publication by another pull request.
Thank you @murchandamus . @craigraw points out that the question of where metadata belongs is not settled, so it seems to me best to put this proposal on hold. If consensus later decides that metadata should be kept entirely separate from output descriptors, we can revive this proposal. Alternatively, I could remove metadata from the proposal, leaving just the encoding of the output descriptor and keys. @craigraw is a binary output descriptor encoding worth it at this point?
is a binary output descriptor encoding worth it at this point?
Yes, I believe a standardised format is still useful.
However wrt to this proposal:
Hey there, this currently has a merge conflict. I also read @craigraw’s response as encouraging, although suggesting some amendments. Have you had a chance to look into that? Please let me know when you have an idea what you would like to happen here next.
Suggestions by @jonatack.
Co-authored-by: Jon Atack <jon@atack.com>
Suggestions by @jonatack.
I resolved the conflicts. As for the amendments, I propose waiting for BIP393 to be accepted, after which I'll remove the redundant fields from this proposal.
Just wanted to let you know that BIP 393 was published
Thanks.
I'm inclined to retract this proposal. The proposals lists 3 advantages:
it lacks a machine-recognizable header, cannot represent metadata such as name and birth block, and its use of base58 for extended keys is inefficient.
BIP 393 now handles metadata, leaving (1) the standard header and (2) the inefficiency of base58. As to (1), wallet software have to deal with header-less textual descriptors already. The size gains of (2) can be achieved with compression (with, say, BBQr) and doesn't change the fundamental issue we run up against: multisig descriptors grow proportionally with the number of participants.
Ottimo lavoro.
