Andrew Chow [ARCHIVE] / is on Nostr

Last Notes

2023-06-07 23:18:21

- reply

📅 Original date posted:2023-01-16
🗒️ Summary of this message: Proposal for Bitcoin vaults raises concerns about address reuse and privacy. Implementation may require unique recovery scripts to avoid reuse. Limit usage to tapscripts for simpler implementation.
📝 Original message:Hi James,
This seems like a promising proposal, but I noticed have a few issues
regarding batching and privacy.
It seems like this proposal will encourage address reuse for vaults, at
least in some parts. It seems like it would not be difficult to ensure
that each vault address was unique through the use of key derivation.
The recovery and unvault scripts could be produced from ranged
descriptors and so there would each vault address would be unique as
each recovery and unvault script is unique. It would not be hard to have
descriptors for vaults, which would then allow for usage of other
descriptors and miniscript into the recovery and unvault scripts.
However the current construction makes it impossible to spend these
vaults together. Since OP_VAULT requires the recovery script of the
unvault output to match what's provided in the input, if there are
multiple inputs with different recovery scripts, then the transaction
will fail. I'm not sure how this could be solved though.
But from my reading of the code, it looks like the unvault scripts can
be unique, so at least address reuse can be avoided here. It just means
that the recovery scripts must be the same, and this would leave an
identifying mark on chain for every unvault. An observer would be able
to correlate unvault transactions by the hashes of the recovery scripts,
and I think this would be rather detrimental to user privacy, not to
mention that sweeping to recovery would also reveal all of your coins too.
On the topic of address reuse, the implemented optional re-vault output
explicitly requires address reuse, as well as breaking the batched
unvaulting of scripts that have different unvault scripts. It's
currently implemented as requiring the unvault script to exactly match
the prevout script of the inputs being spent. This means that all inputs
must have the same script. I think it would be sufficient to do the same
check as the OP_UNVAULT script and just require that the recovery script
and the delay are the same, with the hash of the trigger script being
provided in the input in the same way the target hash is provided for
OP_UNVAULT. This would break the address reuse requirement.
I'm also not convinced that OP_VAULT and OP_UNVAULT should be allowed
for bare and P2WSH outputs. It seems like it would make sense to just
limit their usage to tapscripts as this would simply their implementation.
Andrew
On 01/09/2023 11:07 AM, James O'Beirne via bitcoin-dev wrote:
> For the last few years, I've been interested in vaults as a way to
> substantially derisk custodying Bitcoin, both at personal and commercial
> scales. Instead of abating with familiarity, as enthusiasm sometimes
> does, my conviction that vaults are an almost necessary part of bitcoin's
> viability has only grown over the years.
>
> Since people first started discussing vaults, it's been pretty clear that
> some kind of covenant-enabling consensus functionality is necessary to
> provide the feature set necessary to make vault use practical.
>
> Earlier last year I experimented with using OP_CTV[1], a limited covenant
> mechanism, to implement a "minimum-viable" vault design. I found that the
> inherent limitations of a precomputed covenant scheme left the resulting
> vault implementation wanting, even though it was an improvement over
> existing strategies that rely on presigned transactions and (hopefully)
> ephemeral keys.
>
> But I also found proposed "general" covenant schemes to be
> unsuitable for this use. The bloated scriptPubKeys, both in size and
> complexity, that would result when implementing something like a vault
> weren't encouraging. Also importantly, the social-consensus quagmire
> regarding which covenant proposal to actually deploy feels at times
> intractable.
>
> As a result, I wanted to explore a middle way: a design solely concerned
> with making the best vault use possible, with covenant functionality as a
> secondary consideration. In other words, a proposal that would deliver
> the safety benefits of vaults to users without getting hung up on
> trying to solve the general problem of covenants.
>
> At first this design, OP_VAULT, was just sort of a pipe dream. But as I
> did more thinking (and eventually implementing) I became more convinced
> that, even if it isn't considered for soft-fork, it is a worthwhile
> device to serve as a standard benchmark against which other proposals
> might be judged.
>
> I wrote a paper that summarizes my findings and the resulting proposal:
> https://jameso.be/vaults.pdf
>
> along with an accompanying draft implementation:
> https://github.com/bitcoin/bitcoin/pull/26857
>
> I might work on a BIP if there's interest.
>
> James
>
> [1]: https://github.com/jamesob/simple-ctv-vault

2023-06-07 23:12:15

- reply

📅 Original date posted:2022-07-26
📝 Original message:I went with just tuples of two values because that's easier to implement and targets exactly what people were asking for. However I don't see why this couldn't generalize to any sized tuples. As long as the tuples are all the same length, and the limit is one tuple per key expression, then we don't get any combinatorial blowup issues.
Are there any use cases for variable length tuples?
Andrew
On 07/26/2022 05:56 PM, Pavol Rusnak wrote:
> Thanks Andrew for this BIP. We've been already using this for quite some time for Trezor in production.
>
> Just one clarification: Should <NUM;NUM;NUM>, <NUM;NUM;NUM;NUM>, ... also work or we only aim to support only tuples of exactly two values?
>
> On Tue, 26 Jul 2022 at 23:51, Andrew Chow via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi All,
>>
>> I would like to propose a BIP that de-duplicates and simplifies how we
>> represent descriptors for receiving and change addresses. Under the
>> existing BIPs, this requires two descriptors, where the vast majority of
>> the descriptors are the same, except for a single derivation path
>> element. This proposal allows descriptors to have a single derivation
>> path element that can specify a pair of indexes. Parsers would then
>> expand these into two almost identical descriptors with the difference
>> being that the first uses the first of the pair of indexes, and the
>> second uses the second.
>>
>> The proposed notation is `<a;b>`. As an example,
>> `wpkh(xpub.../0/<0;1>/*)` would be expanded into `wpkh(xpub.../0/0/*)`
>> and `wpkh(xpub.../0/1/*)`.
>>
>> This also works for descriptors involving multiple keys - the first
>> element in every pair is used for the first descriptor, and the second
>> element of each pair in the second descriptor.
>>
>> The full text of the BIP can be found at
>> https://github.com/achow101/bips/blob/bip-multipath-descs/bip-multipath-descs.mediawiki
>> and also copied below. An implementation of it to Bitcoin Core is
>> available at https://github.com/bitcoin/bitcoin/pull/22838.
>>
>> Any feedback on this would be appreciated.
>>
>> Thanks,
>> Andrew Chow
>>
>> ---
>>
>> <pre>
>> BIP: multipath-descs
>> Layer: Applications
>> Title: Multipath Descriptor Key Expressions
>> Author: Andrew Chow <andrew at achow101.com>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> https://github.com/bitcoin/bips/wiki/Comments:BIP-multipath-descs
>> Status: Draft
>> Type: Informational
>> Created: 2022-07-26
>> License: BSD-2-Clause
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies a modification to Key Expressions of Descriptors
>> that are described in BIP 380.
>> This modification allows Key Expressions to indicate BIP 32 derivation
>> path steps that can have multiple values.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Motivation==
>>
>> Descriptors can describe the scripts that are used in a wallet, but
>> wallets often require at least two descriptors for all of the scripts
>> that they watch for.
>> Wallets typically have one descriptor for producing receiving addresses,
>> and the other for change addresses.
>> These descriptors are often extremely similar - they produce the same
>> types of scripts, derive keys from the same master key, and use
>> derivation paths that are almost identical.
>> The only differences are in the derivation path where one of the steps
>> will be different between the descriptors.
>> Thus it is useful to have a notation to represent both descriptors as a
>> single descriptor where one of the derivation steps is a pair of values.
>>
>> ==Specification==
>>
>> For extended keys and their derivations paths in a Key Expression, BIP
>> 380 states:
>>
>> * <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
>> extended private key (as defined in BIP 32)
>> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
>> elements indicating BIP 32 derivation steps to be taken after the given
>> extended key.
>> ** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final
>> step to denote all direct unhardened or hardened children.
>>
>> This is modifed to state:
>>
>> * <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
>> extended private key (as defined in BIP 32)
>> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
>> elements indicating BIP 32 derivation steps to be taken after the given
>> extended key.
>> ** Followed by zero or one <tt>/<NUM;NUM></tt> (<tt>NUM</tt> may be
>> followed by <tt>h</tt> to indicated a hardened step) path element
>> indicating a pair of BIP 32 derivation steps to be taken after the given
>> extended key.
>> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
>> elements indicating BIP 32 derivation steps to be taken after the given
>> extended key.
>> ** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final
>> step to denote all direct unhardened or hardened children.
>>
>> When a <tt>/<NUM;NUM></tt> is encountered, parsers should produce two
>> descriptors where the first descriptor uses the first <tt>NUM</tt>, and
>> a second descriptor uses the second <tt>NUM</tt>.
>>
>> The common use case for this is to represent descriptors for producing
>> receiving and change addresses.
>> When interpreting for this use case, wallets should use the first
>> descriptor for producing receiving addresses, and the second descriptor
>> for producing change addresses.
>> For this use case, the element will commonly be the value <tt>/<0;1></tt>
>>
>> ==Test Vectors==
>>
>> TBD
>>
>> ==Backwards Compatibility==
>>
>> This is an addition to the Key Expressions defined in BIP 380.
>> Key Expressions using the format described in BIP 380 are compatible
>> with this modification and parsers that implement this will still be
>> able to parse such descriptors.
>> However as this is an addition to Key Expressions, older parsers will
>> not be able to understand such descriptors.
>>
>> This modification to Key Expressions uses two new characters: <tt><</tt>
>> and <tt>;</tt>.
>> These are part of the descriptor character set and so are covered by the
>> checksum algorithm.
>> As these are previously unused characters, old parsers will not
>> accidentally mistake them for indicating something else.
>>
>> ==Reference Implementation==
>>
>> https://github.com/bitcoin/bitcoin/pull/22838
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
>
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> Co-Founder, SatoshiLabs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220726/a37dc703/attachment.html>

2023-06-07 23:12:14

- reply

📅 Original date posted:2022-07-26
📝 Original message:Hi All,
I would like to propose a BIP that de-duplicates and simplifies how we
represent descriptors for receiving and change addresses. Under the
existing BIPs, this requires two descriptors, where the vast majority of
the descriptors are the same, except for a single derivation path
element. This proposal allows descriptors to have a single derivation
path element that can specify a pair of indexes. Parsers would then
expand these into two almost identical descriptors with the difference
being that the first uses the first of the pair of indexes, and the
second uses the second.
The proposed notation is `<a;b>`. As an example,
`wpkh(xpub.../0/<0;1>/*)` would be expanded into `wpkh(xpub.../0/0/*)`
and `wpkh(xpub.../0/1/*)`.
This also works for descriptors involving multiple keys - the first
element in every pair is used for the first descriptor, and the second
element of each pair in the second descriptor.
The full text of the BIP can be found at
https://github.com/achow101/bips/blob/bip-multipath-descs/bip-multipath-descs.mediawiki
and also copied below. An implementation of it to Bitcoin Core is
available at https://github.com/bitcoin/bitcoin/pull/22838.
Any feedback on this would be appreciated.
Thanks,
Andrew Chow
---
<pre>
BIP: multipath-descs
Layer: Applications
Title: Multipath Descriptor Key Expressions
Author: Andrew Chow <andrew at achow101.com>
Comments-Summary: No comments yet.
Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-multipath-descs
Status: Draft
Type: Informational
Created: 2022-07-26
License: BSD-2-Clause
</pre>
==Abstract==
This document specifies a modification to Key Expressions of Descriptors
that are described in BIP 380.
This modification allows Key Expressions to indicate BIP 32 derivation
path steps that can have multiple values.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
Descriptors can describe the scripts that are used in a wallet, but
wallets often require at least two descriptors for all of the scripts
that they watch for.
Wallets typically have one descriptor for producing receiving addresses,
and the other for change addresses.
These descriptors are often extremely similar - they produce the same
types of scripts, derive keys from the same master key, and use
derivation paths that are almost identical.
The only differences are in the derivation path where one of the steps
will be different between the descriptors.
Thus it is useful to have a notation to represent both descriptors as a
single descriptor where one of the derivation steps is a pair of values.
==Specification==
For extended keys and their derivations paths in a Key Expression, BIP
380 states:
* <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
extended private key (as defined in BIP 32)
** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
elements indicating BIP 32 derivation steps to be taken after the given
extended key.
** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final
step to denote all direct unhardened or hardened children.
This is modifed to state:
* <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
extended private key (as defined in BIP 32)
** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
elements indicating BIP 32 derivation steps to be taken after the given
extended key.
** Followed by zero or one <tt>/<NUM;NUM></tt> (<tt>NUM</tt> may be
followed by <tt>h</tt> to indicated a hardened step) path element
indicating a pair of BIP 32 derivation steps to be taken after the given
extended key.
** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
elements indicating BIP 32 derivation steps to be taken after the given
extended key.
** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final
step to denote all direct unhardened or hardened children.
When a <tt>/<NUM;NUM></tt> is encountered, parsers should produce two
descriptors where the first descriptor uses the first <tt>NUM</tt>, and
a second descriptor uses the second <tt>NUM</tt>.
The common use case for this is to represent descriptors for producing
receiving and change addresses.
When interpreting for this use case, wallets should use the first
descriptor for producing receiving addresses, and the second descriptor
for producing change addresses.
For this use case, the element will commonly be the value <tt>/<0;1></tt>
==Test Vectors==
TBD
==Backwards Compatibility==
This is an addition to the Key Expressions defined in BIP 380.
Key Expressions using the format described in BIP 380 are compatible
with this modification and parsers that implement this will still be
able to parse such descriptors.
However as this is an addition to Key Expressions, older parsers will
not be able to understand such descriptors.
This modification to Key Expressions uses two new characters: <tt><</tt>
and <tt>;</tt>.
These are part of the descriptor character set and so are covered by the
checksum algorithm.
As these are previously unused characters, old parsers will not
accidentally mistake them for indicating something else.
==Reference Implementation==
https://github.com/bitcoin/bitcoin/pull/22838

2023-06-07 22:56:00

- reply

📅 Original date posted:2021-07-03
📝 Original message:On 7/2/21 11:24 PM, David A. Harding wrote:
> Is there any chance we can take this opportunity to make "h"/"H" the
> preferred aliases? Using "'" in bourne-style shells is very
> annoying[1], and I suspect it's also creating unnecessary complications
> elsewhere.
I've updated the text to use "h".
> Alternatives:
>
> - Completely kill "'" (I'd prefer this, but I realize it's complicated
> with descriptors already being used widely). If "h"/"H" are made the
> preferred aliases, maybe it'd be enough to make implementing "'" a
> SHOULD rather than a MUST; this would push implementations towards
> displaying descriptors using the h versions for maximum compatibility.
Since there already are software implementing descriptors, I don't think
we can do this. I'm not sure about making "'" a SHOULD either.
> - Calculate the checksum over s/(h|H)/'/ (again, I know that's
> complicated with descriptors already widely used)
This has been discussed in the past and the conclusion was that the
checksum should be strictly over the string itself. This would allow for
dumb checksum checkers which don't have to be able to parse descriptors
in order to check the checksum.
Thanks,
Andrew
>
> Thanks,
>
> -Dave
>
> [1] https://github.com/bitcoin/bitcoin/issues/15740#issuecomment-695815432

2023-06-07 22:55:59

- reply

📅 Original date posted:2021-07-02
📝 Original message:I've opened a PR against my own BIPs fork for review: https://github.com/achow101/bips/pull/3
Andrew
On 6/29/21 11:41 PM, Jeremy wrote:
> Kudos, this is fantastic!
>
> It might be easier, since there is a ton of content here, for you to open up some WIP PRs to collect feedback?
> --
> [@JeremyRubin](https://twitter.com/JeremyRubin)
>
> On Tue, Jun 29, 2021 at 2:15 PM Andrew Chow via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi All,
>>
>> I've been working on formalizing the Output Script Descriptors that have
>> been available in Bitcoin Core for a while into BIPs. Since descriptors
>> are modular and have optional components, I've decided to split it into
>> 7 BIPs, rather than a single one. The first describes descriptors in
>> general and does not specify any particular descriptor. However it does
>> describe the general operation, key expressions (including derivation
>> paths and key origin info), and the descriptor checksum. The following 6
>> BIPs specify the actual descriptors themselves. These are non-segwit
>> descriptor (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig
>> descriptors (multi, sortedmulti), the taproot descriptor (tr), the combo
>> descriptor, and opaque descriptors (raw, addr). This separation is so
>> that implementors can choose to not implement some descriptors and still
>> say which descriptors they support without being too difficult to
>> understand.
>>
>> The text of all of the documents are below, and they can also be found
>> on github:https://github.com/achow101/bips/tree/descriptors/
>>
>> Thanks,
>> Andrew Chow
>>
>> ---
>>
>> <pre>
>> BIP: bip-descriptors-general
>> Layer: Applications
>> Title: Output Script Descriptors General Operation
>> Author: Pieter Wuille <pieter at wuille.net>
>> Andrew Chow <andrew at achow101.com>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-general
>> Status: Draft
>> Type: Informational
>> Created: 2021-06-27
>> License: BSD-2-Clause
>> </pre>
>>
>> ==Abstract==
>>
>> Output Script Descriptors are a simple language which can be used to
>> describe collections ofoutput scripts.
>> There can be many different descriptor fragments and functions.
>> This document describes the general syntax for descriptors, descriptor
>> checksums, and common expressions.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Motivation==
>>
>> Bitcoin wallets traditionally have stored a set of keys which are later
>> serialized and mutated to produce the output scripts that the wallet
>> watches and the addresses it provides to users.
>> Typically backups have consisted of solely the private keys, nowadays
>> primarily in the form of BIP 39 mnemonics.
>> However this backup solution is insuffient, especially since the
>> introduction of Segregated Witness which added new output types.
>> Given just the private keys, it is not possible for restored wallets to
>> know which kinds of output scripts and addresses to produce.
>> This has lead to incompatibilities between wallets when restoring a
>> backup or exporting data for a watch only wallet.
>>
>> Further complicating matters are BIP 32 derivation paths.
>> Although BIPs 44, 49, and 84 have specified standard BIP 32 derivation
>> paths for different output scripts and addresses, not all wallets
>> support them nor use those derivation paths.
>> The lack of derivation path information in these backups and exports
>> leads to further incompatibilities between wallets.
>>
>> Current solutions to these issues have not been generic and can be
>> viewed as being layer violations.
>> Solutions such as introducing different version bytes for extended key
>> serialization both are a layer violation (key derivation should be
>> separate from script type meaning) and specific only to a particular
>> derivation path and script type.
>>
>> Output Script Descriptors introduces a generic solution to these issues.
>> Script types are specified explicitly through the use of Script Expressions.
>> Key derivation paths are specified explicitly in Key Expressions.
>> These allow for creating wallet backups and exports which specify the
>> exact scripts, subscripts (redeemScript, witnessScript, etc.), and keys
>> to produce.
>> With the general structure specified in this BIP, new Script Expressions
>> can be introduced as new script types are added.
>> Lastly, the use of common terminology and existing standards allow for
>> Output Script Descriptors to be engineer readable so that the results
>> can be understood at a glance.
>>
>> ==Specification==
>>
>> Descriptors consist of several types of expressions.
>> The top level expression is a <tt>SCRIPT</tt>.
>> This expression may be followed by <tt>#CHECKSUM</tt>, where
>> <tt>CHECKSUM</tt> is an 8 character alphanumeric descriptor checksum.
>>
>> ===Script Expressions===
>>
>> Script Expressions (denoted <tt>SCRIPT</tt>) are expressions which
>> correspond directly with a Bitcoin script.
>> These expressions are written as functions and take arguments.
>> Such expressions have a script template which is filled with the
>> arguments correspondingly.
>> Expressions are written with a human readable identifier string with the
>> arguments enclosed with parentheses.
>> The identifier string should be alphanumeric and may include underscores.
>>
>> The arguments to a script expression are defined by that expression itself.
>> They could be a script expression, a key expression, or some other
>> expression entirely.
>>
>> ===Key Expressions===
>>
>> A common expression used as an argument to script expressions are key
>> expressions (denoted <tt>KEY</tt>).
>> These represent a public or private key and, optionally, information
>> about the origin of that key.
>> Key expressions can only be used as arguments to script expressions.
>>
>> Key expressions consist of:
>> * Optionally, key origin information, consisting of:
>> ** An open bracket <tt>[</tt>
>> ** Exactly 8 hex characters for the fingerprint of the key where the
>> derivation starts (see BIP 32 for details)
>> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUM'</tt> path
>> elements to indicate the unhardened or hardened derivation steps between
>> the fingerprint and the key that follows.
>> ** A closing bracket <tt>]</tt>
>> * Followed by the actual key, which is either:
>> ** A hex encoded public key, which depending the script expression, may
>> be either:
>> *** 66 hex character string beginning with <tt>02</tt> or <tt>03</tt>
>> representing a compressed public key
>> *** 130 hex character string beginning with <tt>04</tt> representing an
>> uncompressed public key
>> *** 64 hex character string representing an x-only public key
>> ** A [[[https://en.bitcoin.it/wiki/Wallet_import_format|WIF](https://en.bitcoin.it/wiki/Wallet_import_format%7CWIF)]] encoded
>> private key
>> ** <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
>> extended private key (as defined in BIP 32)
>> *** Followed by zero or more <tt>/NUM</tt> or <tt>/NUM'</tt> path
>> elements indicating BIP 32 derivation steps to be taken after the given
>> extended key.
>> *** Optionally followed by a single <tt>/*</tt> or <tt>/*'</tt> final
>> step to denote all direct unhardened or hardened children.
>>
>> If the <tt>KEY</tt> is a BIP 32 extended key, before output scripts can
>> be created, child keys must be derived using the derivation information
>> that follows the extended key.
>> When the final step is <tt>/*</tt> or <tt>/*'</tt>, an output script
>> will be produced for every child key index.
>> The derived key must be serialized as a compressed public key.
>>
>> In the above specification, the hardened indicator <tt>'</tt> may be
>> replaced with alternative hardnened indicators of <tt>h</tt> or <tt>H</tt>.
>>
>> ===Character Set===
>>
>> The expressions used in descriptors must only contain characters within
>> this character set so that the descriptor checksum will work.
>>
>> The allowed characters are:
>> <pre>
>> 0123456789()[],'/*abcdefgh@:$%{}
>> IJKLMNOPQRSTUVWXYZ&+-.;<=>?!^_|~
>> ijklmnopqrstuvwxyzABCDEFGH`#"\<space>
>> </pre>
>> Note that <tt><space></tt> on the last line is a space character.
>>
>> This character set is written as 3 groups of 32 characters in this
>> specific order so that the checksum below can identify more errors.
>> The first group are the most common "unprotected" characters (i.e.
>> things such as hex and keypaths that do not already have their own
>> checksums).
>> Case errors cause an offset that is a multiple of 32 while as many
>> alphabetic characters are in the same group while following the previous
>> restrictions.
>>
>> ===Checksum===
>>
>> Follwing the top level script expression is a single octothorpe
>> (<tt>#</tt>) followed by the 8 character checksum.
>> The checksum is an error correcting checksum similar to bech32.
>>
>> The checksum has the following properties:
>> * Mistakes in a descriptor string are measured in "symbol errors". The
>> higher the number of symbol errors, the harder it is to detect:
>> ** An error substituting a character from
>> <tt>0123456789()[],'/*abcdefgh@:$%{}</tt> for another in that set always
>> counts as 1 symbol error.
>> *** Note that hex encoded keys are covered by these characters. Extended
>> keys (<tt>xpub</tt> and <tt>xprv</tt>) use other characters too, but
>> also have their own checksum mechansim.
>> *** <tt>SCRIPT</tt> expression function names use other characters, but
>> mistakes in these would generally result in an unparsable descriptor.
>> ** A case error always counts as 1 symbol error.
>> ** Any other 1 character substitution error counts as 1 or 2 symbol errors.
>> * Any 1 symbol error is always detected.
>> * Any 2 or 3 symbol error in a descriptor of up to 49154 characters is
>> always detected.
>> * Any 4 symbol error in a descriptor of up to 507 characters is always
>> detected.
>> * Any 5 symbol error in a descriptor of up to 77 characters is always
>> detected.
>> * Is optimized to minimize the chance of a 5 symbol error in a
>> descriptor up to 387 characters is undetected
>> * Random errors have a chance of 1 in 2<super>40</super> of being
>> undetected.
>>
>> The checksum itself uses the same character set as bech32:
>> <tt>qpzry9x8gf2tvdw0s3jn54khce6mua7l</tt>
>>
>> Valid descriptor strings with a checksum must pass the criteria for
>> validity specified by the Python3 code snippet below.
>> The function <tt>descsum_check</tt> must return true when its argument
>> <tt>s</tt> is a descriptor consisting in the form <tt>SCRIPT#CHECKSUM</tt>.
>>
>> <pre>
>> INPUT_CHARSET =
>> "0123456789()[],'/*abcdefgh@:$%{}IJKLMNOPQRSTUVWXYZ&+-.;<=>?!^_|~ijklmnopqrstuvwxyzABCDEFGH`#\"\\
>> "
>> CHECKSUM_CHARSET = "qpzry9x8gf2tvdw0s3jn54khce6mua7l"
>> GENERATOR = [0xf5dee51989, 0xa9fdca3312, 0x1bab10e32d, 0x3706b1677a,
>> 0x644d626ffd]
>>
>> def descsum_polymod(symbols):
>> """Internal function that computes the descriptor checksum."""
>> chk = 1
>> for value in symbols:
>> top = chk >> 35
>> chk = (chk & 0x7ffffffff) << 5 ^ value
>> for i in range(5):
>> chk ^= GENERATOR[i] if ((top >> i) & 1) else 0
>> return chk
>>
>> def descsum_expand(s):
>> """Internal function that does the character to symbol expansion"""
>> groups = []
>> symbols = []
>> for c in s:
>> if not c in INPUT_CHARSET:
>> return None
>> v = INPUT_CHARSET.find(c)
>> symbols.append(v & 31)
>> groups.append(v >> 5)
>> if len(groups) == 3:
>> symbols.append(groups[0] * 9 + groups[1] * 3 + groups[2])
>> groups = []
>> if len(groups) == 1:
>> symbols.append(groups[0])
>> elif len(groups) == 2:
>> symbols.append(groups[0] * 3 + groups[1])
>> return symbols
>>
>> def descsum_check(s):
>> """Verify that the checksum is correct in a descriptor"""
>> if s[-9] != '#':
>> return False
>> if not all(x in CHECKSUM_CHARSET for x in s[-8:]):
>> return False
>> symbols = descsum_expand(s[:-9]) + [CHECKSUM_CHARSET.find(x) for x
>> in s[-8:]]
>> return descsum_polymod(symbols) == 1
>> </pre>
>>
>> This implements a BCH code that has the properties described above.
>> The entire descriptor string is first processed into an array of symbols.
>> The symbol for each character is its position within its group.
>> After every 3rd symbol, a 4th symbol is inserted which represents the
>> group numbers combined together.
>> This means that a change that only affects the position within a group,
>> or only a group number change, will only affect a single symbol.
>>
>> To construct a valid checksum given a script expression, the code below
>> can be used:
>>
>> <pre>
>> def descsum_create(s):
>> """Add a checksum to a descriptor without"""
>> symbols = descsum_expand(s) + [0, 0, 0, 0, 0, 0, 0, 0]
>> checksum = descsum_polymod(symbols) ^ 1
>> return s + '#' + ''.join(CHECKSUM_CHARSET[(checksum >> (5 * (7 -
>> i))) & 31] for i in range(8))
>>
>> </pre>
>>
>> ==Backwards Compatibility==
>>
>> Output script descriptors are an entirely new language which is not
>> compatible with any existing software.
>> However many components of the expressions reuse encodings and
>> serializations defined by previous BIPs.
>>
>> Output script descriptors are designed for future extension with further
>> fragment types and new script expressions.
>> These will be specified in additional BIPs.
>>
>> ==Reference Implemntation==
>>
>> Descriptors have been implemented in Bitcoin Core since version 0.17.
>>
>> ---
>>
>> <pre>
>> BIP: bip-descriptors-segwit
>> Layer: Applications
>> Title: segwit Output Script Descriptors
>> Author: Pieter Wuille <pieter at wuille.net>
>> Andrew Chow <andrew at achow101.com>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-segwit
>> Status: Draft
>> Type: Informational
>> Created: 2021-06-27
>> License: BSD-2-Clause
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies <tt>wpkh()</tt>, and <tt>wsh()</tt> output
>> script descriptors.
>> <tt>wpkh()</tt> descriptors take a key and produces a P2WPKH output script.
>> <tt>wsh()</tt> descriptors take a script and produces a P2WSH output script.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Motivation==
>>
>> Segregated Witness added 2 additional standard output script formats:
>> P2WPKH and P2WSH.
>> These expressions allow specifying those formats as a descriptor.
>>
>> ==Specification==
>>
>> Two new script expressions are defined: <tt>wpkh()</tt>, and <tt>wsh()</tt>.
>>
>> ===<tt>wpkh()</tt>===
>>
>> The <tt>wpkh(KEY)</tt> expression can be used as a top level expression,
>> or inside of a <tt>sh()</tt> descriptor.
>> It takes a single key expression as an argument and produces a P2WPKH
>> output script.
>> Only keys which are/has compressed public keys can be contained in a
>> <tt>wpkh()</tt> expression.
>>
>> The output script produced is:
>> <pre>
>> OP_0 <KEY_hash160>
>> </pre>
>>
>> ===<tt>wsh()</tt>===
>>
>> The <tt>wsh(SCRIPT)</tt> expression can be used as a top level
>> expression, or inside of a <tt>sh()</tt> descriptor.
>> It takes a single script expression as an argument and produces a P2WSH
>> output script.
>> <tt>wsh()</tt> expressions also create a witnessScript which is required
>> in order to spend outputs which use its output script.
>> This redeemScript is the output script produced by the <tt>SCRIPT</tt>
>> argument to <tt>wsh()</tt>.
>> Any key expression found in any script expression contained by a
>> <tt>wsh()</tt> expression must only produce compresed public keys.
>>
>> The output script produced is:
>> <pre>
>> OP_0 <SCRIPT_sha256>
>> </pre>
>>
>> ==Test Vectors==
>>
>> TBD
>>
>> ==Backwards Compatibility==
>>
>> <tt>wpkh()</tt>, and <tt>wsh()</tt> descriptors use the format and
>> general operation specified in
>> [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
>> As these are a wholly new descriptors, they are not compatible with any
>> implementation.
>> However the scripts produced are standard scripts so existing software
>> are likely to be familiar with them.
>>
>> ==Reference Implemntation==
>>
>> <tt>wpkh()</tt>, and <tt>wsh()</tt> descriptors have been implemented in
>> Bitcoin Core since version 0.17.
>>
>> ---
>>
>> <pre>
>> BIP: bip-descriptors-non-segwit
>> Layer: Applications
>> Title: Non-segwit Output Script Descriptors
>> Author: Pieter Wuille <pieter at wuille.net>
>> Andrew Chow <andrew at achow101.com>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-non-segwit
>> Status: Draft
>> Type: Informational
>> Created: 2021-06-27
>> License: BSD-2-Clause
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies <tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt>
>> output script descriptors.
>> <tt>pk()</tt> descriptors take a key and produces a P2PK output script.
>> <tt>pkh()</tt> descriptors take a key and produces a P2PKH output script.
>> <tt>sh()</tt> descriptors take a script and produces a P2SH output script.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Motivation==
>>
>> Prior to the activation of Segregated Witness, there were 3 main
>> standard output script formats: P2PK, P2PKH, and P2SH.
>> These expressions allow specifying those formats as a descriptor.
>>
>> ==Specification==
>>
>> Three new script expressions are defined: <tt>pk()</tt>, <tt>pkh()</tt>,
>> and <tt>sh()</tt>.
>>
>> ===<tt>pk()</tt>===
>>
>> The <tt>pk(KEY)</tt> expression can be used in any context or level of a
>> descriptor.
>> It takes a single key expression as an argument and produces a P2PK
>> output script.
>> Depending on the higher level descriptors, there may be restrictions on
>> the type of public keys that can be included.
>> Such restrictions will be specified by those descriptors.
>>
>> The output script produced is:
>> <pre>
>> <KEY> OP_CHECKSIG
>> </pre>
>>
>> ===<tt>pkh()</tt>===
>>
>> The <tt>pkh(KEY)</tt> expression can be used as a top level expression,
>> or inside of either a <tt>sh()</tt> or <tt>wsh()</tt> descriptor.
>> It takes a single key expression as an argument and produces a P2PKH
>> output script.
>> Depending on the higher level descriptors, there may be restrictions on
>> the type of public keys that can be included.
>> Such restrictions will be specified by those descriptors.
>>
>> The output script produced is:
>> <pre>
>> OP_DUP OP_HASH160 <KEY_hash160> OP_EQUALVERIFY OP_CHECKSIG
>> </pre>
>>
>> ===<tt>sh()</tt>===
>>
>> The <tt>sh(SCRIPT)</tt> expression can only be used as a top level
>> expression.
>> It takes a single script expression as an argument and produces a P2SH
>> output script.
>> <tt>sh()</tt> expressions also create a redeemScript which is required
>> in order to spend outputs which use its output script.
>> This redeemScript is the output script produced by the <tt>SCRIPT</tt>
>> argument to <tt>sh()</tt>.
>>
>> The output script produced is:
>> <pre>
>> OP_HASH160 <SCRIPT_hash160> OP_EQUAL
>> </pre>
>>
>> ==Test Vectors==
>>
>> TBD
>>
>> ==Backwards Compatibility==
>>
>> <tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt> descriptors use the
>> format and general operation specified in
>> [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
>> As these are a wholly new descriptors, they are not compatible with any
>> implementation.
>> However the scripts produced are standard scripts so existing software
>> are likely to be familiar with them.
>>
>> ==Reference Implemntation==
>>
>> <tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt> descriptors have been
>> implemented in Bitcoin Core since version 0.17.
>>
>> ---
>>
>> <pre>
>> BIP: bip-descriptors-tr
>> Layer: Applications
>> Title: tr() Output Script Descriptors
>> Author: Pieter Wuille <pieter at wuille.net>
>> Andrew Chow <andrew at achow101.com>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-tr
>> Status: Draft
>> Type: Informational
>> Created: 2021-06-27
>> License: BSD-2-Clause
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies <tt>tr()</tt> output script descriptors.
>> <tt>tr()</tt> descriptors take a key and optionally a tree of scripts
>> and produces a P2TR output script.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Motivation==
>>
>> Taproot added one additional standard output script format: P2TR.
>> These expressions allow specifying those formats as a descriptor.
>>
>> ==Specification==
>>
>> A new script expressions are defined: <tt>tr()</tt>.
>> A new expression is defined: Tree Expressions
>>
>> ===Tree Expression===
>>
>> A Tree Expression (denoted <tt>TREE</tt>) is an expression which
>> represents a tree of scripts.
>> The way the tree is represented in an output script is dependent on the
>> higher level expressions.
>>
>> A Tree Expression is:
>> * Any Script Expression that is allowed at the level this Tree
>> Expression is in.
>> * A pair of Tree Expressions consisting of:
>> ** An open brace <tt>{</tt>
>> ** A Tree Expression
>> ** A comma <tt>,</tt>
>> ** A Tree Expression
>> ** A closing brance <tt>}</tt>
>>
>> ===<tt>tr()</tt>===
>>
>> The <tt>tr(KEY)</tt> or <tt>tr(KEY, TREE)</tt> expression can only be
>> used as a top level expression.
>> All key expressions under any <tt>tr()</tt> expression must create
>> x-only public keys.
>>
>> <tt>tr(KEY</tt> takes a single key expression as an argument and
>> produces a P2TR output script which does not have a script path.
>> The keys produced by the key expression are used as the internal key as
>> specified by [[bip-0341.mediawiki#cite_ref-22-0|BIP 341]].
>> Specifically, "If the spending conditions do not require a script path,
>> the output key should commit to an unspendable script path instead of
>> having no script path.
>> This can be achieved by computing the output key point as ''Q = P +
>> int(hash<sub>TapTweak</sub>(bytes(P)))G''."
>>
>> <pre>
>> internal_key: lift_x(KEY)
>> 32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G
>> scriptPubKey: OP_1 <32_byte_output_key>
>> </pre>
>>
>> <tt>tr(KEY, TREE)</tt> takes a key expression as the first argument, and
>> a tree expression as the second argument and produces a P2TR output
>> script which has a script path.
>> The keys produced by the first key expression are used as the internal
>> key as specified by
>> [[bip-0341.mediawiki#Constructing_and_spending_Taproot_outputs|BIP 341]].
>> The Tree expression becomes the Taproot script tree as described in BIP 341.
>> A merkle root is computed from this tree and combined with the internal
>> key to create the Taproot output key.
>>
>> <pre>
>> internal_key: lift_x(KEY)
>> merkle_root: HashTapBranch(TREE)
>> 32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)
>> || merkle_root))G
>> scriptPubKey: OP_1 <32_byte_output_key>
>> </pre>
>>
>> ==Test Vectors==
>>
>> TBD
>>
>> ==Backwards Compatibility==
>>
>> <tt>tr()</tt> descriptors use the format and general operation specified
>> in [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
>> As these are a wholly new descriptors, they are not compatible with any
>> implementation.
>> However the scripts produced are standard scripts so existing software
>> are likely to be familiar with them.
>>
>> Tree Expressions are largely incompatible with existing script
>> expressions due to the restrictions in those expressions.
>> As of 2021-06-27, the only allowed script expression that can be used in
>> a tree expression is <tt>pk()</tt>.
>> However there will be future BIPs that specify script expressions that
>> can be used in tree expressions.
>>
>> ==Reference Implemntation==
>>
>> <tt>tr()</tt> descriptors have been implemented in Bitcoin Core since
>> version 22.0.
>>
>> ---
>>
>> <pre>
>> BIP: bip-descriptors-multi
>> Layer: Applications
>> Title: Multisig Output Script Descriptors
>> Author: Pieter Wuille <pieter at wuille.net>
>> Andrew Chow <andrew at achow101.com>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-multi
>> Status: Draft
>> Type: Informational
>> Created: 2021-06-27
>> License: BSD-2-Clause
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies <tt>multi()</tt>, and <tt>sortedmulti()</tt>
>> output script descriptors.
>> Both functions take a threshold and one or more public keys and produce
>> a multisig output script.
>> <tt>multi()</tt> specifies the public keys in the output script in the
>> order given in the descriptor while <tt>sortedmulti()</tt> sorts the
>> public keys lexicographically when the output script is produced.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Motivation==
>>
>> The most common complex script used in Bitcoin is a threshold multisig.
>> These expressions allow specifying multisig scripts as a descriptor.
>>
>> ==Specification==
>>
>> Two new script expressions are defined: <tt>multi()</tt>, and
>> <tt>sortedmulti()</tt>.
>> Both expressions produce the scripts of the same template and take the
>> same arguments.
>> They are written as <tt>multi(k,KEY_1,KEY_2,...,KEY_n)</tt>.
>> <tt>k</tt> is the threshold - the number of keys that must sign the
>> input for the script to be valid.
>> <tt>KEY_1,KEY_2,...,KEY_n</tt> are the key expressions for the multisig.
>> <tt>k</tt> must be less than or equal to <tt>n<tt>.
>>
>> <tt>multi()</tt> and <tt>sortedmulti()</tt> expressions can be used as a
>> top level expression, or inside of either a <tt>sh()</tt> or
>> <tt>wsh()</tt> descriptor.
>> Depending on the higher level descriptors, there may be restrictions on
>> the type of public keys that can be included.
>>
>> Depending on the higher level descriptors, there are also restrictions
>> on the number of keys that can be present, i.e. the maximum value of
>> <tt>n</tt>.
>> When used at the top level, there can only be at most 3 keys.
>> When used inside of a <tt>sh()</tt> expression, there can only be most
>> 15 compressed public keys (this is limited by the P2SH script limit).
>> Otherwise the maximum number of keys is 20.
>>
>> The output script produced also depends on the value of <tt>k</tt>. If
>> <tt>k</tt> is less than or equal to 16:
>> <pre>
>> OP_k KEY_1 KEY_2 ... KEY_n OP_CHECKMULTISIG
>> </pre>
>>
>> if <tt>k</tt> is greater than 16:
>> <pre>
>> k KEY_1 KEY_2 ... KEY_n OP_CHECKMULTISIG
>> </pre>
>>
>> ===<tt>sortedmulti()</tt>===
>>
>> The only change for <tt>sortedmulti()</tt> is that the keys are sorted
>> lexicographically prior to the creation of the output script.
>> This sorting is on the keys that are to be put into the output script,
>> i.e. after all extended keys are derived.
>>
>> ===Multiple Extended Keys</tt>===
>>
>> When one or more the key expressions in a <tt>multi()</tt> or
>> <tt>sortedmulti()</tt> expression are extended keys, the derived keys
>> use the same child index.
>> This changes the keys in lockstep and allows for output scripts to be
>> indexed in the same way that the derived keys are indexed.
>>
>> ==Test Vectors==
>>
>> TBD
>>
>> ==Backwards Compatibility==
>>
>> <tt>multi()</tt>, and <tt>sortedmulti()</tt> descriptors use the format
>> and general operation specified in
>> [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
>> As these are a wholly new descriptors, they are not compatible with any
>> implementation.
>> However the scripts produced are standard scripts so existing software
>> are likely to be familiar with them.
>>
>> ==Reference Implemntation==
>>
>> <tt>multi()</tt>, and <tt>multi()</tt> descriptors have been implemented
>> in Bitcoin Core since version 0.17.
>>
>> ---
>>
>> <pre>
>> BIP: bip-descriptors-combo
>> Layer: Applications
>> Title: combo() Output Script Descriptors
>> Author: Pieter Wuille <pieter at wuille.net>
>> Andrew Chow <andrew at achow101.com>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-combo
>> Status: Draft
>> Type: Informational
>> Created: 2021-06-27
>> License: BSD-2-Clause
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies <tt>combo()</tt> output script descriptors.
>> These take a key and produce P2PK, P2PKH, P2WPKH, and P2SH-P2WPKH output
>> scripts if applicable to the key.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Motivation==
>>
>> In order to make the transition from traditional key based wallets to
>> descriptor based wallets easier, it is useful to be able to take a key
>> and produce the scripts which have traditionally been produced by wallet
>> software.
>>
>> ==Specification==
>>
>> A new top level script expression is defined: <tt>combo(KEY)</tt>.
>> This expression can only be used as a top level expression.
>> It takes a single key expression as an argument and produces either 2 or
>> 4 output scripts, depending on the key.
>> A <tt>combo()</tt> expression always produces a P2PK and P2PKH script,
>> the same as putting the key in both a <tt>pk()</tt> and a <tt>pkh()</tt>
>> expression.
>> If the key is/has a compressed public key, then P2WPKH and P2SH-P2WPKH
>> scripts are also produced, the same as putting the key in both a
>> <tt>wpkh()</tt> and <tt>sh(wpkh())</tt> expression.
>>
>> ==Test Vectors==
>>
>> TBD
>>
>> ==Backwards Compatibility==
>>
>> <tt>combo()</tt> descriptors use the format and general operation
>> specified in [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
>> As this is a wholly new descriptor, it is not compatible with any
>> implementation.
>> However the scripts produced are standard scripts so existing software
>> are likely to be familiar with them.
>>
>> ==Reference Implemntation==
>>
>> <tt>combo</tt> descriptors have been implemented in Bitcoin Core since
>> version 0.17.
>>
>> ---
>>
>> <pre>
>> BIP: bip-descriptors-encap
>> Layer: Applications
>> Title: raw() and addr() Output Script Descriptors
>> Author: Andrew Chow <andrew at achow101.com>
>> Pieter Wuille <pieter at wuille.net>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-raw
>> Status: Draft
>> Type: Informational
>> Created: 2021-06-27
>> License: BSD-2-Clause
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies <tt>raw()</tt> and <tt>addr()</tt> output script
>> descriptors.
>> <tt>raw()</tt> encapsulates a raw script as a descriptor.
>> <tt>addr()</tt> encapsulates an address as a descriptor.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Motivation==
>>
>> In order to make descriptors maximally compatible with scripts in use
>> today, it is useful to be able to wrap any arbitrary output script or an
>> address into a descriptor.
>>
>> ==Specification==
>>
>> Two new script expressions are defined: <tt>raw()</tt> and <tt>addr()</tt>.
>>
>> ===<tt>raw()</tt>===
>>
>> The <tt>raw(HEX)</tt> expression can only be used as a top level descriptor.
>> As the argument, it takes a hex string representing a Bitcoin script.
>> The output script produced by this descriptor is the script represented
>> by <tt>HEX</tt>.
>>
>> ===<tt>addr()</tt>===
>>
>> The <tt>addr(ADDR)</tt> expression can only be used as a top level
>> descriptor.
>> It takes an address as its single argument.
>> The output script produced by this descriptor is the output script
>> produced by the address <tt>ADDR</tt>.
>>
>> ==Test Vectors==
>>
>> TBD
>>
>> ==Backwards Compatibility==
>>
>> <tt>raw()</tt> and <tt>addr()</tt> descriptors use the format and
>> general operation specified in
>> [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
>> As this is a wholly new descriptor, it is not compatible with any
>> implementation.
>> The reuse of existing Bitcoin addresses allows for this to be more
>> easily implemented.
>>
>> ==Reference Implemntation==
>>
>> <tt>raw()</tt> and <tt>addr</tt> descriptors have been implemented in
>> Bitcoin Core since version 0.17.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210702/12a7e13b/attachment-0001.html>

2023-06-07 22:55:46

- reply

📅 Original date posted:2021-06-29
📝 Original message:Hi All,
I've been working on formalizing the Output Script Descriptors that have
been available in Bitcoin Core for a while into BIPs. Since descriptors
are modular and have optional components, I've decided to split it into
7 BIPs, rather than a single one. The first describes descriptors in
general and does not specify any particular descriptor. However it does
describe the general operation, key expressions (including derivation
paths and key origin info), and the descriptor checksum. The following 6
BIPs specify the actual descriptors themselves. These are non-segwit
descriptor (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig
descriptors (multi, sortedmulti), the taproot descriptor (tr), the combo
descriptor, and opaque descriptors (raw, addr). This separation is so
that implementors can choose to not implement some descriptors and still
say which descriptors they support without being too difficult to
understand.
The text of all of the documents are below, and they can also be found
on github:https://github.com/achow101/bips/tree/descriptors/
Thanks,
Andrew Chow
---
<pre>
BIP: bip-descriptors-general
Layer: Applications
Title: Output Script Descriptors General Operation
Author: Pieter Wuille <pieter at wuille.net>
          Andrew Chow <andrew at achow101.com>
Comments-Summary: No comments yet.
Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-general
Status: Draft
Type: Informational
Created: 2021-06-27
License: BSD-2-Clause
</pre>
==Abstract==
Output Script Descriptors are a simple language which can be used to
describe collections ofoutput scripts.
There can be many different descriptor fragments and functions.
This document describes the general syntax for descriptors, descriptor
checksums, and common expressions.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
Bitcoin wallets traditionally have stored a set of keys which are later
serialized and mutated to produce the output scripts that the wallet
watches and the addresses it provides to users.
Typically backups have consisted of solely the private keys, nowadays
primarily in the form of BIP 39 mnemonics.
However this backup solution is insuffient, especially since the
introduction of Segregated Witness which added new output types.
Given just the private keys, it is not possible for restored wallets to
know which kinds of output scripts and addresses to produce.
This has lead to incompatibilities between wallets when restoring a
backup or exporting data for a watch only wallet.
Further complicating matters are BIP 32 derivation paths.
Although BIPs 44, 49, and 84 have specified standard BIP 32 derivation
paths for different output scripts and addresses, not all wallets
support them nor use those derivation paths.
The lack of derivation path information in these backups and exports
leads to further incompatibilities between wallets.
Current solutions to these issues have not been generic and can be
viewed as being layer violations.
Solutions such as introducing different version bytes for extended key
serialization both are a layer violation (key derivation should be
separate from script type meaning) and specific only to a particular
derivation path and script type.
Output Script Descriptors introduces a generic solution to these issues.
Script types are specified explicitly through the use of Script Expressions.
Key derivation paths are specified explicitly in Key Expressions.
These allow for creating wallet backups and exports which specify the
exact scripts, subscripts (redeemScript, witnessScript, etc.), and keys
to produce.
With the general structure specified in this BIP, new Script Expressions
can be introduced as new script types are added.
Lastly, the use of common terminology and existing standards allow for
Output Script Descriptors to be engineer readable so that the results
can be understood at a glance.
==Specification==
Descriptors consist of several types of expressions.
The top level expression is a <tt>SCRIPT</tt>.
This expression may be followed by <tt>#CHECKSUM</tt>, where
<tt>CHECKSUM</tt> is an 8 character alphanumeric descriptor checksum.
===Script Expressions===
Script Expressions (denoted <tt>SCRIPT</tt>) are expressions which
correspond directly with a Bitcoin script.
These expressions are written as functions and take arguments.
Such expressions have a script template which is filled with the
arguments correspondingly.
Expressions are written with a human readable identifier string with the
arguments enclosed with parentheses.
The identifier string should be alphanumeric and may include underscores.
The arguments to a script expression are defined by that expression itself.
They could be a script expression, a key expression, or some other
expression entirely.
===Key Expressions===
A common expression used as an argument to script expressions are key
expressions (denoted <tt>KEY</tt>).
These represent a public or private key and, optionally, information
about the origin of that key.
Key expressions can only be used as arguments to script expressions.
Key expressions consist of:
* Optionally, key origin information, consisting of:
** An open bracket <tt>[</tt>
** Exactly 8 hex characters for the fingerprint of the key where the
derivation starts (see BIP 32 for details)
** Followed by zero or more <tt>/NUM</tt> or <tt>/NUM'</tt> path
elements to indicate the unhardened or hardened derivation steps between
the fingerprint and the key that follows.
** A closing bracket <tt>]</tt>
* Followed by the actual key, which is either:
** A hex encoded public key, which depending the script expression, may
be either:
*** 66 hex character string beginning with <tt>02</tt> or <tt>03</tt>
representing a compressed public key
*** 130 hex character string beginning with <tt>04</tt> representing an
uncompressed public key
*** 64 hex character string representing an x-only public key
** A [[https://en.bitcoin.it/wiki/Wallet_import_format|WIF]] encoded
private key
** <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
extended private key (as defined in BIP 32)
*** Followed by zero or more <tt>/NUM</tt> or <tt>/NUM'</tt> path
elements indicating BIP 32 derivation steps to be taken after the given
extended key.
*** Optionally followed by a single <tt>/*</tt> or <tt>/*'</tt> final
step to denote all direct unhardened or hardened children.
If the <tt>KEY</tt> is a BIP 32 extended key, before output scripts can
be created, child keys must be derived using the derivation information
that follows the extended key.
When the final step is <tt>/*</tt> or <tt>/*'</tt>, an output script
will be produced for every child key index.
The derived key must be serialized as a compressed public key.
In the above specification, the hardened indicator <tt>'</tt> may be
replaced with alternative hardnened indicators of <tt>h</tt> or <tt>H</tt>.
===Character Set===
The expressions used in descriptors must only contain characters within
this character set so that the descriptor checksum will work.
The allowed characters are:
<pre>
0123456789()[],'/*abcdefgh@:$%{}
IJKLMNOPQRSTUVWXYZ&+-.;<=>?!^_|~
ijklmnopqrstuvwxyzABCDEFGH`#"\<space>
</pre>
Note that <tt><space></tt> on the last line is a space character.
This character set is written as 3 groups of 32 characters in this
specific order so that the checksum below can identify more errors.
The first group are the most common "unprotected" characters (i.e.
things such as hex and keypaths that do not already have their own
checksums).
Case errors cause an offset that is a multiple of 32 while as many
alphabetic characters are in the same group while following the previous
restrictions.
===Checksum===
Follwing the top level script expression is a single octothorpe
(<tt>#</tt>) followed by the 8 character checksum.
The checksum is an error correcting checksum similar to bech32.
The checksum has the following properties:
* Mistakes in a descriptor string are measured in "symbol errors". The
higher the number of symbol errors, the harder it is to detect:
** An error substituting a character from
<tt>0123456789()[],'/*abcdefgh@:$%{}</tt> for another in that set always
counts as 1 symbol error.
*** Note that hex encoded keys are covered by these characters. Extended
keys (<tt>xpub</tt> and <tt>xprv</tt>) use other characters too, but
also have their own checksum mechansim.
*** <tt>SCRIPT</tt> expression function names use other characters, but
mistakes in these would generally result in an unparsable descriptor.
** A case error always counts as 1 symbol error.
** Any other 1 character substitution error counts as 1 or 2 symbol errors.
* Any 1 symbol error is always detected.
* Any 2 or 3 symbol error in a descriptor of up to 49154 characters is
always detected.
* Any 4 symbol error in a descriptor of up to 507 characters is always
detected.
* Any 5 symbol error in a descriptor of up to 77 characters is always
detected.
* Is optimized to minimize the chance of a 5 symbol error in a
descriptor up to 387 characters is undetected
* Random errors have a chance of 1 in 2<super>40</super> of being
undetected.
The checksum itself uses the same character set as bech32:
<tt>qpzry9x8gf2tvdw0s3jn54khce6mua7l</tt>
Valid descriptor strings with a checksum must pass the criteria for
validity specified by the Python3 code snippet below.
The function <tt>descsum_check</tt> must return true when its argument
<tt>s</tt> is a descriptor consisting in the form <tt>SCRIPT#CHECKSUM</tt>.
<pre>
INPUT_CHARSET =
"0123456789()[],'/*abcdefgh@:$%{}IJKLMNOPQRSTUVWXYZ&+-.;<=>?!^_|~ijklmnopqrstuvwxyzABCDEFGH`#\"\\
"
CHECKSUM_CHARSET = "qpzry9x8gf2tvdw0s3jn54khce6mua7l"
GENERATOR = [0xf5dee51989, 0xa9fdca3312, 0x1bab10e32d, 0x3706b1677a,
0x644d626ffd]
def descsum_polymod(symbols):
    """Internal function that computes the descriptor checksum."""
    chk = 1
    for value in symbols:
        top = chk >> 35
        chk = (chk & 0x7ffffffff) << 5 ^ value
        for i in range(5):
            chk ^= GENERATOR[i] if ((top >> i) & 1) else 0
    return chk
def descsum_expand(s):
    """Internal function that does the character to symbol expansion"""
    groups = []
    symbols = []
    for c in s:
        if not c in INPUT_CHARSET:
            return None
        v = INPUT_CHARSET.find(c)
        symbols.append(v & 31)
        groups.append(v >> 5)
        if len(groups) == 3:
            symbols.append(groups[0] * 9 + groups[1] * 3 + groups[2])
            groups = []
    if len(groups) == 1:
        symbols.append(groups[0])
    elif len(groups) == 2:
        symbols.append(groups[0] * 3 + groups[1])
    return symbols
def descsum_check(s):
    """Verify that the checksum is correct in a descriptor"""
    if s[-9] != '#':
        return False
    if not all(x in CHECKSUM_CHARSET for x in s[-8:]):
        return False
    symbols = descsum_expand(s[:-9]) + [CHECKSUM_CHARSET.find(x) for x
in s[-8:]]
    return descsum_polymod(symbols) == 1
</pre>
This implements a BCH code that has the properties described above.
The entire descriptor string is first processed into an array of symbols.
The symbol for each character is its position within its group.
After every 3rd symbol, a 4th symbol is inserted which represents the
group numbers combined together.
This means that a change that only affects the position within a group,
or only a group number change, will only affect a single symbol.
To construct a valid checksum given a script expression, the code below
can be used:
<pre>
def descsum_create(s):
    """Add a checksum to a descriptor without"""
    symbols = descsum_expand(s) + [0, 0, 0, 0, 0, 0, 0, 0]
    checksum = descsum_polymod(symbols) ^ 1
    return s + '#' + ''.join(CHECKSUM_CHARSET[(checksum >> (5 * (7 -
i))) & 31] for i in range(8))
</pre>
==Backwards Compatibility==
Output script descriptors are an entirely new language which is not
compatible with any existing software.
However many components of the expressions reuse encodings and
serializations defined by previous BIPs.
Output script descriptors are designed for future extension with further
fragment types and new script expressions.
These will be specified in additional BIPs.
==Reference Implemntation==
Descriptors have been implemented in Bitcoin Core since version 0.17.
---
<pre>
BIP: bip-descriptors-segwit
Layer: Applications
Title: segwit Output Script Descriptors
Author: Pieter Wuille <pieter at wuille.net>
          Andrew Chow <andrew at achow101.com>
Comments-Summary: No comments yet.
Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-segwit
Status: Draft
Type: Informational
Created: 2021-06-27
License: BSD-2-Clause
</pre>
==Abstract==
This document specifies <tt>wpkh()</tt>, and <tt>wsh()</tt> output
script descriptors.
<tt>wpkh()</tt> descriptors take a key and produces a P2WPKH output script.
<tt>wsh()</tt> descriptors take a script and produces a P2WSH output script.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
Segregated Witness added 2 additional standard output script formats:
P2WPKH and P2WSH.
These expressions allow specifying those formats as a descriptor.
==Specification==
Two new script expressions are defined: <tt>wpkh()</tt>, and <tt>wsh()</tt>.
===<tt>wpkh()</tt>===
The <tt>wpkh(KEY)</tt> expression can be used as a top level expression,
or inside of a <tt>sh()</tt> descriptor.
It takes a single key expression as an argument and produces a P2WPKH
output script.
Only keys which are/has compressed public keys can be contained in a
<tt>wpkh()</tt> expression.
The output script produced is:
<pre>
OP_0 <KEY_hash160>
</pre>
===<tt>wsh()</tt>===
The <tt>wsh(SCRIPT)</tt> expression can be used as a top level
expression, or inside of a <tt>sh()</tt> descriptor.
It takes a single script expression as an argument and produces a P2WSH
output script.
<tt>wsh()</tt> expressions also create a witnessScript which is required
in order to spend outputs which use its output script.
This redeemScript is the output script produced by the <tt>SCRIPT</tt>
argument to <tt>wsh()</tt>.
Any key expression found in any script expression contained by a
<tt>wsh()</tt> expression must only produce compresed public keys.
The output script produced is:
<pre>
OP_0 <SCRIPT_sha256>
</pre>
==Test Vectors==
TBD
==Backwards Compatibility==
<tt>wpkh()</tt>, and <tt>wsh()</tt> descriptors use the format and
general operation specified in
[[bip-descriptor-general.mediawiki|bip-descriptor-general]].
As these are a wholly new descriptors, they are not compatible with any
implementation.
However the scripts produced are standard scripts so existing software
are likely to be familiar with them.
==Reference Implemntation==
<tt>wpkh()</tt>, and <tt>wsh()</tt> descriptors have been implemented in
Bitcoin Core since version 0.17.
---
<pre>
BIP: bip-descriptors-non-segwit
Layer: Applications
Title: Non-segwit Output Script Descriptors
Author: Pieter Wuille <pieter at wuille.net>
          Andrew Chow <andrew at achow101.com>
Comments-Summary: No comments yet.
Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-non-segwit
Status: Draft
Type: Informational
Created: 2021-06-27
License: BSD-2-Clause
</pre>
==Abstract==
This document specifies <tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt>
output script descriptors.
<tt>pk()</tt> descriptors take a key and produces a P2PK output script.
<tt>pkh()</tt> descriptors take a key and produces a P2PKH output script.
<tt>sh()</tt> descriptors take a script and produces a P2SH output script.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
Prior to the activation of Segregated Witness, there were 3 main
standard output script formats: P2PK, P2PKH, and P2SH.
These expressions allow specifying those formats as a descriptor.
==Specification==
Three new script expressions are defined: <tt>pk()</tt>, <tt>pkh()</tt>,
and <tt>sh()</tt>.
===<tt>pk()</tt>===
The <tt>pk(KEY)</tt> expression can be used in any context or level of a
descriptor.
It takes a single key expression as an argument and produces a P2PK
output script.
Depending on the higher level descriptors, there may be restrictions on
the type of public keys that can be included.
Such restrictions will be specified by those descriptors.
The output script produced is:
<pre>
<KEY> OP_CHECKSIG
</pre>
===<tt>pkh()</tt>===
The <tt>pkh(KEY)</tt> expression can be used as a top level expression,
or inside of either a <tt>sh()</tt> or <tt>wsh()</tt> descriptor.
It takes a single key expression as an argument and produces a P2PKH
output script.
Depending on the higher level descriptors, there may be restrictions on
the type of public keys that can be included.
Such restrictions will be specified by those descriptors.
The output script produced is:
<pre>
OP_DUP OP_HASH160 <KEY_hash160> OP_EQUALVERIFY OP_CHECKSIG
</pre>
===<tt>sh()</tt>===
The <tt>sh(SCRIPT)</tt> expression can only be used as a top level
expression.
It takes a single script expression as an argument and produces a P2SH
output script.
<tt>sh()</tt> expressions also create a redeemScript which is required
in order to spend outputs which use its output script.
This redeemScript is the output script produced by the <tt>SCRIPT</tt>
argument to <tt>sh()</tt>.
The output script produced is:
<pre>
OP_HASH160 <SCRIPT_hash160> OP_EQUAL
</pre>
==Test Vectors==
TBD
==Backwards Compatibility==
<tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt> descriptors use the
format and general operation specified in
[[bip-descriptor-general.mediawiki|bip-descriptor-general]].
As these are a wholly new descriptors, they are not compatible with any
implementation.
However the scripts produced are standard scripts so existing software
are likely to be familiar with them.
==Reference Implemntation==
<tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt> descriptors have been
implemented in Bitcoin Core since version 0.17.
---
<pre>
BIP: bip-descriptors-tr
Layer: Applications
Title: tr() Output Script Descriptors
Author: Pieter Wuille <pieter at wuille.net>
          Andrew Chow <andrew at achow101.com>
Comments-Summary: No comments yet.
Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-tr
Status: Draft
Type: Informational
Created: 2021-06-27
License: BSD-2-Clause
</pre>
==Abstract==
This document specifies <tt>tr()</tt> output script descriptors.
<tt>tr()</tt> descriptors take a key and optionally a tree of scripts
and produces a P2TR output script.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
Taproot added one additional standard output script format: P2TR.
These expressions allow specifying those formats as a descriptor.
==Specification==
A new script expressions are defined: <tt>tr()</tt>.
A new expression is defined: Tree Expressions
===Tree Expression===
A Tree Expression (denoted <tt>TREE</tt>) is an expression which
represents a tree of scripts.
The way the tree is represented in an output script is dependent on the
higher level expressions.
A Tree Expression is:
* Any Script Expression that is allowed at the level this Tree
Expression is in.
* A pair of Tree Expressions consisting of:
** An open brace <tt>{</tt>
** A Tree Expression
** A comma <tt>,</tt>
** A Tree Expression
** A closing brance <tt>}</tt>
===<tt>tr()</tt>===
The <tt>tr(KEY)</tt> or <tt>tr(KEY, TREE)</tt> expression can only be
used as a top level expression.
All key expressions under any <tt>tr()</tt> expression must create
x-only public keys.
<tt>tr(KEY</tt> takes a single key expression as an argument and
produces a P2TR output script which does not have a script path.
The keys produced by the key expression are used as the internal key as
specified by [[bip-0341.mediawiki#cite_ref-22-0|BIP 341]].
Specifically, "If the spending conditions do not require a script path,
the output key should commit to an unspendable script path instead of
having no script path.
This can be achieved by computing the output key point as ''Q = P +
int(hash<sub>TapTweak</sub>(bytes(P)))G''."
<pre>
internal_key:       lift_x(KEY)
32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G
scriptPubKey:       OP_1 <32_byte_output_key>
</pre>
<tt>tr(KEY, TREE)</tt> takes a key expression as the first argument, and
a tree expression as the second argument and produces a P2TR output
script which has a script path.
The keys produced by the first key expression are used as the internal
key as specified by
[[bip-0341.mediawiki#Constructing_and_spending_Taproot_outputs|BIP 341]].
The Tree expression becomes the Taproot script tree as described in BIP 341.
A merkle root is computed from this tree and combined with the internal
key to create the Taproot output key.
<pre>
internal_key:       lift_x(KEY)
merkle_root:        HashTapBranch(TREE)
32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)
|| merkle_root))G
scriptPubKey:       OP_1 <32_byte_output_key>
</pre>
==Test Vectors==
TBD
==Backwards Compatibility==
<tt>tr()</tt> descriptors use the format and general operation specified
in [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
As these are a wholly new descriptors, they are not compatible with any
implementation.
However the scripts produced are standard scripts so existing software
are likely to be familiar with them.
Tree Expressions are largely incompatible with existing script
expressions due to the restrictions in those expressions.
As of 2021-06-27, the only allowed script expression that can be used in
a tree expression is <tt>pk()</tt>.
However there will be future BIPs that specify script expressions that
can be used in tree expressions.
==Reference Implemntation==
<tt>tr()</tt> descriptors have been implemented in Bitcoin Core since
version 22.0.
---
<pre>
BIP: bip-descriptors-multi
Layer: Applications
Title: Multisig Output Script Descriptors
Author: Pieter Wuille <pieter at wuille.net>
          Andrew Chow <andrew at achow101.com>
Comments-Summary: No comments yet.
Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-multi
Status: Draft
Type: Informational
Created: 2021-06-27
License: BSD-2-Clause
</pre>
==Abstract==
This document specifies <tt>multi()</tt>, and <tt>sortedmulti()</tt>
output script descriptors.
Both functions take a threshold and one or more public keys and produce
a multisig output script.
<tt>multi()</tt> specifies the public keys in the output script in the
order given in the descriptor while <tt>sortedmulti()</tt> sorts the
public keys lexicographically when the output script is produced.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
The most common complex script used in Bitcoin is a threshold multisig.
These expressions allow specifying multisig scripts as a descriptor.
==Specification==
Two new script expressions are defined: <tt>multi()</tt>, and
<tt>sortedmulti()</tt>.
Both expressions produce the scripts of the same template and take the
same arguments.
They are written as <tt>multi(k,KEY_1,KEY_2,...,KEY_n)</tt>.
<tt>k</tt> is the threshold - the number of keys that must sign the
input for the script to be valid.
<tt>KEY_1,KEY_2,...,KEY_n</tt> are the key expressions for the multisig.
<tt>k</tt> must be less than or equal to <tt>n<tt>.
<tt>multi()</tt> and <tt>sortedmulti()</tt> expressions can be used as a
top level expression, or inside of either a <tt>sh()</tt> or
<tt>wsh()</tt> descriptor.
Depending on the higher level descriptors, there may be restrictions on
the type of public keys that can be included.
Depending on the higher level descriptors, there are also restrictions
on the number of keys that can be present, i.e. the maximum value of
<tt>n</tt>.
When used at the top level, there can only be at most 3 keys.
When used inside of a <tt>sh()</tt> expression, there can only be most
15 compressed public keys (this is limited by the P2SH script limit).
Otherwise the maximum number of keys is 20.
The output script produced also depends on the value of <tt>k</tt>. If
<tt>k</tt> is less than or equal to 16:
<pre>
OP_k KEY_1 KEY_2 ... KEY_n OP_CHECKMULTISIG
</pre>
if <tt>k</tt> is greater than 16:
<pre>
k KEY_1 KEY_2 ... KEY_n OP_CHECKMULTISIG
</pre>
===<tt>sortedmulti()</tt>===
The only change for <tt>sortedmulti()</tt> is that the keys are sorted
lexicographically prior to the creation of the output script.
This sorting is on the keys that are to be put into the output script,
i.e. after all extended keys are derived.
===Multiple Extended Keys</tt>===
When one or more the key expressions in a <tt>multi()</tt> or
<tt>sortedmulti()</tt> expression are extended keys, the derived keys
use the same child index.
This changes the keys in lockstep and allows for output scripts to be
indexed in the same way that the derived keys are indexed.
==Test Vectors==
TBD
==Backwards Compatibility==
<tt>multi()</tt>, and <tt>sortedmulti()</tt> descriptors use the format
and general operation specified in
[[bip-descriptor-general.mediawiki|bip-descriptor-general]].
As these are a wholly new descriptors, they are not compatible with any
implementation.
However the scripts produced are standard scripts so existing software
are likely to be familiar with them.
==Reference Implemntation==
<tt>multi()</tt>, and <tt>multi()</tt> descriptors have been implemented
in Bitcoin Core since version 0.17.
---
<pre>
BIP: bip-descriptors-combo
Layer: Applications
Title: combo() Output Script Descriptors
Author: Pieter Wuille <pieter at wuille.net>
          Andrew Chow <andrew at achow101.com>
Comments-Summary: No comments yet.
Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-combo
Status: Draft
Type: Informational
Created: 2021-06-27
License: BSD-2-Clause
</pre>
==Abstract==
This document specifies <tt>combo()</tt> output script descriptors.
These take a key and produce P2PK, P2PKH, P2WPKH, and P2SH-P2WPKH output
scripts if applicable to the key.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
In order to make the transition from traditional key based wallets to
descriptor based wallets easier, it is useful to be able to take a key
and produce the scripts which have traditionally been produced by wallet
software.
==Specification==
A new top level script expression is defined: <tt>combo(KEY)</tt>.
This expression can only be used as a top level expression.
It takes a single key expression as an argument and produces either 2 or
4 output scripts, depending on the key.
A <tt>combo()</tt> expression always produces a P2PK and P2PKH script,
the same as putting the key in both a <tt>pk()</tt> and a <tt>pkh()</tt>
expression.
If the key is/has a compressed public key, then P2WPKH and P2SH-P2WPKH
scripts are also produced, the same as putting the key in both a
<tt>wpkh()</tt> and <tt>sh(wpkh())</tt> expression.
==Test Vectors==
TBD
==Backwards Compatibility==
<tt>combo()</tt> descriptors use the format and general operation
specified in [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
As this is a wholly new descriptor, it is not compatible with any
implementation.
However the scripts produced are standard scripts so existing software
are likely to be familiar with them.
==Reference Implemntation==
<tt>combo</tt> descriptors have been implemented in Bitcoin Core since
version 0.17.
---
<pre>
BIP: bip-descriptors-encap
Layer: Applications
Title: raw() and addr() Output Script Descriptors
Author: Andrew Chow <andrew at achow101.com>
          Pieter Wuille <pieter at wuille.net>
Comments-Summary: No comments yet.
Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-raw
Status: Draft
Type: Informational
Created: 2021-06-27
License: BSD-2-Clause
</pre>
==Abstract==
This document specifies <tt>raw()</tt> and <tt>addr()</tt> output script
descriptors.
<tt>raw()</tt> encapsulates a raw script as a descriptor.
<tt>addr()</tt> encapsulates an address as a descriptor.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
In order to make descriptors maximally compatible with scripts in use
today, it is useful to be able to wrap any arbitrary output script or an
address into a descriptor.
==Specification==
Two new script expressions are defined: <tt>raw()</tt> and <tt>addr()</tt>.
===<tt>raw()</tt>===
The <tt>raw(HEX)</tt> expression can only be used as a top level descriptor.
As the argument, it takes a hex string representing a Bitcoin script.
The output script produced by this descriptor is the script represented
by <tt>HEX</tt>.
===<tt>addr()</tt>===
The <tt>addr(ADDR)</tt> expression can only be used as a top level
descriptor.
It takes an address as its single argument.
The output script produced by this descriptor is the output script
produced by the address <tt>ADDR</tt>.
==Test Vectors==
TBD
==Backwards Compatibility==
<tt>raw()</tt> and <tt>addr()</tt> descriptors use the format and
general operation specified in
[[bip-descriptor-general.mediawiki|bip-descriptor-general]].
As this is a wholly new descriptor, it is not compatible with any
implementation.
The reuse of existing Bitcoin addresses allows for this to be more
easily implemented.
==Reference Implemntation==
<tt>raw()</tt> and <tt>addr</tt> descriptors have been implemented in
Bitcoin Core since version 0.17.

2023-06-07 22:55:22

- reply

📅 Original date posted:2021-06-22
📝 Original message:Hi All,
I would like to propose a simple derivation path scheme for keys to be
used in single key Taproot scripts. This is based on BIP 44 so it is
basically identical to BIPs 49 and 84. Like with those BIPs, the actual
value to be used in the purpose level will be set to the BIP number,
once assigned.
Note that the keys derived in this method should be for the Taproot
internal key, which should then be tweaked with the hash of itself as
recommended by BIP 341. The keys derived at this path should not be used
directly as the Taproot output pubkey. Additionally, this BIP does not
specify new version bytes for extended key serialization because, with
the advent of descriptors, I think that is unnecessary. In fact, this
BIP feels somewhat unnecessary to me, but it seems like it will be
needed for now in order to drive adoption and implementation of Taproot
into software and hardware wallets.
The text can be viewed below, with the rendered text available at
https://github.com/achow101/bips/blob/taproot-bip44/bip-taproot-bip44.mediawiki
Andrew Chow
---
<pre>
BIP: bip-taproot-bip44
Layer: Applications
Title: Derivation scheme for P2TR based accounts
Author: Andrew Chow <andrew at achow101.com>
Comments-Summary: No comments yet.
Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-taproot-bip44
Status: Draft
Type: Informational
Created: 2021-06-22
License: BSD-2-Clause
</pre>
==Abstract==
This document suggests a derivation scheme for HD wallets whose keys are
involved in single key
P2TR ([[bip-0341.mediawiki|BIP 341]]) outputs as the Taproot internal key.
===Copyright===
This BIP is licensed under the 2-clause BSD license.
==Motivation==
With the usage of single key P2TR transactions, it is useful to have a
common derivation scheme so
that HD wallets that only have a backup of the HD seed can be likely to
recover single key Taproot
outputs. Although there are now solutions which obviate the need for
fixed derivation paths for
specific script types, many software wallets and hardware signers still
use seed backups which
lack derivation path and script information. Thus we largely use the
same approach used in BIPs
[[bip-0049.mediawiki|49]] and [[bip-0084.mediawiki|84]] for ease of
implementation.
==Specifications==
This BIP defines the two needed steps to derive multiple deterministic
addresses based on a
[[bip-0032.mediawiki|BIP 32]] master private key.
===Public key derivation===
To derive a public key from the root account, this BIP uses the same
account-structure as
defined in BIPs [[bip-0044.mediawiki|44]], [[bip-0049.mediawiki|49]],
and [[bip-0084.mediawiki|84]],
but with a different purpose value for the script type.
<pre>
m / purpose' / coin_type' / account' / change / address_index
</pre>
For the <tt>purpose</tt>-path level it uses <tt><BIPNUMBER>'</tt>.
The rest of the levels are used as defined in BIPs 44, 49, and 84.
===Address derivation===
To derive the output key used in the P2TR script from the derived public
key, we use the method
recommended in
[[bip-0341.mediawiki#constructing-and-spending-taproot-outputs|BIP 341]]:
<pre>
internal_key:       lift_x(derived_key)
32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G
</pre>
In a transaction, the scripts and witnesses are as defined in
[[bip-0341.mediawiki#specification|BIP 341]]:
<pre>
witness:      <signature>
scriptSig:    (empty)
scriptPubKey: 1 <32_byte_output_key>
              (0x5120{32_byte_output_key})
</pre>
==Backwards Compatibility==
This BIP is not backwards compatible by design.
An incompatible wallet will not discover these accounts at all and the
user will notice that
something is wrong.
However this BIP uses the same method used in BIPs 44, 49, and 84, so it
should not be difficult
to implement.
==Test vectors==
TBD
==Reference==
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic
Wallets]]
* [[bip-0049.mediawiki|BIP49 - Derivation scheme for
P2WPKH-nested-in-P2SH based accounts]]
* [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based accounts]]
* [[bip-0341.mediawiki|BIP341 - Taproot: SegWit version 1 spending rules]]

2023-06-07 22:55:21

- reply

📅 Original date posted:2021-06-28
📝 Original message:Hi Salvatore,
On 6/28/21 6:03 AM, Salvatore Ingala wrote:
> Hi Andrew,
>
> I just have a small suggestion on this proposal.
>
> On Tue, 22 Jun 2021 at 23:29, Andrew Chow via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> | Taproot Leaf Script
>> | <tt>PSBT_IN_TAP_LEAF_SCRIPT = 0x15</tt>
>> | <tt><control block></tt>
>> | The control block for this leaf as specified in BIP 341. The control
>> block contains the merkle tree path to this leaf.
>> | <tt><script> <8-bit uint></tt>
>> | The script for this leaf as would be provided in the witness stack
>> followed by the single byte leaf version.
>
> So far, all the defined PSBT types had a relatively short keydata (not much bigger than a couple of pubkeys).
> I think that is a desirable property to keep, as it is often a reasonable assumption that dictionary keys are not very large.
> The control block as per BIP 341 can be up to 33 + 32*128 = 4129 bytes long.
>
> Perhaps it would be better to split this into PSBT_IN_TAP_LEAF_SCRIPT and PSBT_IN_TAP_LEAF_CONTROL_BLOCK (both with no keydata)?
A taproot tree can have multiple leaf scripts, and since it is possible that the actual script to be used is not known at the time scripts and control blocks are added to the PSBT, it would not be sufficient to only have two fields with no keydata. It would not be possible to specify multiple leaf scripts.
Furthermore, it is possible to have the same leaf script appear multiple times in the tree. So it is not sufficient to use the leaf hash as the keydata as a script that appears multiple times would only have one control block possible, where in reality it would have more than one.
Thus the only way to allow multiple different leaf scripts, and the same leaf script to appear multiple times, is to use the control block as keydata.
Andrew Chow
> Best,
> Salvatore Ingala
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210628/b423a8cc/attachment.html>

2023-06-07 22:55:19

- reply

📅 Original date posted:2021-06-22
📝 Original message:Hi All,
I would like to propose a BIP which defines new fields for Taproot
support in PSBT.
The full text is below, and the rendered file can be found at
https://github.com/achow101/bips/blob/taproot-psbt/bip-taproot-psbt.mediawiki.
Andrew Chow
---
<pre>
BIP: taproot-psbt
Layer: Applications
Title: Taproot Fields for PSBT
Author: Andrew Chow <andrew at achow101.com>
Comments-Summary: No comments yet.
Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-taproot-psbt
Status: draft
Type: Standards Track
Created: 2021-06-21
License: BSD-2-Clause
</pre>
==Introduction==
===Abstract===
This document proposes additional fields for BIP 174 PSBTv0 and BIP 370
PSBTv2 that allow for
BIP 340/341/342 Taproot data to be included in a PSBT of any version.
These will be fields for
signatures and scripts that are relevant to the creation of Taproot inputs.
===Copyright===
This BIP is licensed under the 2-clause BSD license.
===Motivation===
BIPs 340, 341, and 342 specify Taproot which provides a wholly new way
to create and spend Bitcoin outputs.
The existing PSBT fields are unable to support Taproot due to the new
signature algorithm and the method
by which scripts are embedded inside of a Taproot output. Therefore new
fields must be defined to allow
PSBTs to carry the information necessary for signing Taproot inputs.
==Specification==
The new per-input types are defined as follows:
{|
! Name
! <tt><keytype></tt>
! <tt><keydata></tt>
! <tt><keydata></tt> Description
! <tt><valuedata></tt>
! <tt><valuedata></tt> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
|-
| Taproot Key Spend Signature
| <tt>PSBT_IN_TAP_KEY_SIG = 0x13</tt>
| None
| No key data <ref>'''Why is there no key data for
<tt>PSBT_IN_TAP_KEY_SIG</tt>'''The signature in a key path spend
corresponds directly with the pubkey provided in the output script. Thus
it is not necessary to provide any metadata that attaches the key path
spend signature to a particular pubkey.</ref>
| <tt><signature></tt>
| The 64 or 65 byte Schnorr signature for key path spending a Taproot
output.
|
|
| 0, 2
|-
| Taproot Script Spend Signature
| <tt>PSBT_IN_TAP_SCRIPT_SIG = 0x14</tt>
| <tt><xonlypubkey> <leafhash></tt>
| The 32 byte X-only public key concatenated with the 32 byte hash of
the leaf it is part of.
| <tt><signature></tt>
| The 64 or 65 byte Schnorr signature for this pubkey and leaf combination.
|
|
| 0, 2
|-
| Taproot Leaf Script
| <tt>PSBT_IN_TAP_LEAF_SCRIPT = 0x15</tt>
| <tt><control block></tt>
| The control block for this leaf as specified in BIP 341. The control
block contains the merkle tree path to this leaf.
| <tt><script> <8-bit uint></tt>
| The script for this leaf as would be provided in the witness stack
followed by the single byte leaf version.
|
|
| 0, 2
|-
| Taproot Key BIP 32 Derivation Path
| <tt>PSBT_IN_TAP_BIP32_DERIVATION = 0x16</tt>
| <tt><xonlypubkey></tt>
| The 32 byte X-only public key
| <tt><hashes len> <leaf hash>* <32-bit uint> <32-bit uint>*</tt>
| A compact size unsigned integer representing the number of leaf
hashes, followed by a list of leaf hashes, followed by the master key
fingerprint 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. Public keys are those needed to
spend this output. The leaf hashes are of the leaves which involve this
public key.
|
|
| 0, 2
|-
| Taproot Internal Key
| <tt>PSBT_IN_TAP_INTERNAL_KEY = 0x17</tt>
| None
| No key data
| <tt><pubkey></tt>
| The X-only pubkey used as the internal key in this output.<ref>'''Why
is the internal key provided?'''The internal key is not necessarily the
same key as in the Taproot output script. BIP 341 recommends tweaking
the key with the hash of itself. It may be necessary for signers to know
what the internal key actually is so that they are able to determine
whether an input can be signed by it.</ref>
|
|
| 0, 2
|-
| Taproot Merkle Root
| <tt>PSBT_IN_TAP_MERKLE_ROOT = 0x18</tt>
| None
| No key data
| <tt><pubkey></tt>
| The 32 byte Merkle root hash
|
|
| 0, 2
|}
The new per-output types are defined as follows:
{|
! Name
! <tt><keytype></tt>
! <tt><keydata></tt>
! <tt><keydata></tt> Description
! <tt><valuedata></tt>
! <tt><valuedata></tt> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
|-
| Taproot Internal Key
| <tt>PSBT_OUT_TAP_INTERNAL_KEY = 0x05</tt>
| None
| No key data
| <tt><pubkey></tt>
| The X-only pubkey used as the internal key in this output.
|
|
| 0, 2
|-
| Taproot Tree
| <tt>PSBT_OUT_TAP_TREE = 0x06</tt>
| None
| No key data
| <tt>{<8-bit uint depth> <8-bit uint leaf version> <scriptlen>
<script>}*</tt>
| One or more tuples representing the depth, leaf version, and script
for a leaf in the Taproot tree, allowing the entire tree to be
reconstructed. The tuples must be in depth first search order so that
the tree is correctly reconstructed. Each tuple is an 8-bit unsigned
integer representing the depth in the Taproot tree for this script, an
8-bit unsigned integer representing the leaf version, the length of the
script as a compact size unsigned integer, and the script itself.
|
|
| 0, 2
|-
| Taproot Key BIP 32 Derivation Path
| <tt>PSBT_OUT_TAP_BIP32_DERIVATION = 0x07</tt>
| <tt><xonlypubkey></tt>
| The 32 byte X-only public key
| <tt><hashes len> <leaf hash>* <32-bit uint> <32-bit uint>*</tt>
| A compact size unsigned integer representing the number of leaf
hashes, followed by a list of leaf hashes, followed by the master key
fingerprint 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. Public keys are those needed to
spend this output. The leaf hashes are of the leaves which involve this
public key.
|
|
| 0, 2
|}
===UTXO Types===
BIP 174 recommends using <tt>PSBT_IN_NON_WITNESS_UTXO</tt> for all
inputs because of potential attacks involving
an updater lying about the amounts in an output. Because a Taproot
signature will commit to all of the amounts
and output scripts spent by the inputs of the transaction, such attacks
are prevented as any such lying would
result in an invalid signature. Thus Taproot inputs can use just
<tt>PSBT_IN_WITNESS_UTXO</tt>.
==Compatibility==
These are simply new fields added to the existing PSBT format. Because
PSBT is designed to be extensible, old
software will ignore the new fields.
==Test Vectors==
TBD
==Rationale==
<references/>
==Reference implementation==
The reference implementation of the PSBT format is available at TBD.
==Acknowledgements==
TBD

2023-06-07 18:28:02

- reply

📅 Original date posted:2021-01-06
📝 Original message:Hi Rusty,
On 1/6/21 6:26 PM, Rusty Russell wrote:
> Hi Andrew et al,
>
> Very excited to see this progress; thanks for doing all the
> work! Sorry for the delayed feedback, I didn't get to this before the
> break.
>
>> Additionally, I would like to add a new global field:
>> * PSBT_GLOBAL_UNDER_CONSTRUCTION = 0x05
>> * Key: empty
>> * Value: A single byte as a boolean. 0 for False, 1 for True. All
>> other values ore prohibited. Must be omitted for PSBTv0, may be omitted
>> in PSBTv2.
>>
>> PSBT_GLOBAL_UNDER_CONSTRUCTION is used to signal whether inputs and
>> outputs can be added to the PSBT. This flag may be set to True when
>> inputs and outputs are being updated, signed, and finalized. However
>> care must be taken when there are existing signatures. If this field is
>> omitted or set to False, no further inputs and outputs may be added to
>> the PSBT.
> I wonder if this can be flagged simply by omitting the (AFAICT
> redundant) PSBT_GLOBAL_INPUT_COUNT and PSBT_GLOBAL_OUTPUT_COUNT? What
> are the purposes of those fields?
The purpose of those fields is to know how many input and output maps
there are. Without PSBT_GLOBAL_UNSIGNED_TX, there is no way to determine
whether a map is an input map or an output map. So the counts are there
to allow that.
> For our uses, there would be no signatures at this stage; it's simply a
> subdivision of the Creator role. This role would be terminated by
> removing the under-construction marker. For this, it could be clear
> that such an under-construction PSBT SHOULD NOT be signed.
There are some protocols where signed inputs are added to transactions.
> Otherwise, if an explicit marker is required, I would omit the value and
> simply use its existence to as a flag. Having two "false" values is
> simply asking for trouble.
Seems reasonable.
Andrew
> Thanks!
> Rusty.
> PS. Perhaps we should change the name to PBT (Partial Bitcoin
> Transaction) now, since it's more than just signing...

2023-06-07 18:27:45

- reply

📅 Original date posted:2020-12-22
📝 Original message:Hi All,
I have some updates on this after speaking with some people off-list.
Firstly, the version number will be set to 2. In most discussions, this
proposal was being referred to as PSBT version 2, so it'll be easier and
clearer to set the version number to 2.
For lock times, instead of a single PSBT_IN_REQUIRED_LOCKTIME field,
there will be 2 of them, one for a time based lock time, and the other
for height based. These will be:
* PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x10
* Key: empty
* Value: 32 bit unsigned little endian integer greater than or equal
to 500000000 representing the minimum Unix timestamp that this input
requires to be set as the transaction's lock time. Must be omitted in
PSBTv0, and may be omitted in PSBTv2
* PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x11
* Key: empty
* Value: 32 bit unsigned little endian integer less than 500000000
representing the minimum block height that this input requires to be set
as the transaction's lock time. Must be omitted in PSBTv0, and may be
omitted in PSBTv2.
Having two lock time fields is necessary due to the behavior where all
inputs must use the same type of lock time (height or time). Thus if an
input requires a particular type of lock time, it must set the requisite
field. Any new inputs being added must be able to accommodate all
existing inputs' lock time type. This means they either must not have a
lock time specified (i.e. no OP_CLTV involved), or have branches that
allow the acceptance of either type. If an input has a lock time type
that is incompatible with the rest of the transaction, it must not be added.
PSBT_GLOBAL_PREFERRED_LOCKTIME is changed to purely be the fallback
option if no input lock time fields are present. If there are input lock
times, all lock time calculations must ignore it.
Any role which does lock time calculation will first check if there are
input lock time fields. If there are not, it must then check for a
PSBT_GLOBAL_PREFERRED_LOCKTIME. If this field exists, its value is the
transaction's lock time. If it does not, the lock time is 0. If there
are input lock time fields, it must choose the type which does not
invalidate any inputs. The lock time is then determined to be the
maximum value of all of the lock time fields for the chosen type.
Additionally, I would like to add a new global field:
* PSBT_GLOBAL_UNDER_CONSTRUCTION = 0x05
* Key: empty
* Value: A single byte as a boolean. 0 for False, 1 for True. All
other values ore prohibited. Must be omitted for PSBTv0, may be omitted
in PSBTv2.
PSBT_GLOBAL_UNDER_CONSTRUCTION is used to signal whether inputs and
outputs can be added to the PSBT. This flag may be set to True when
inputs and outputs are being updated, signed, and finalized. However
care must be taken when there are existing signatures. If this field is
omitted or set to False, no further inputs and outputs may be added to
the PSBT.
Several rules must be followed to ensure that adding additional inputs
and outputs will not invalidate existing signatures. First, an input or
output adder must check for any existing signatures in all of the other
inputs. If there are none, the input or output may be added in any
position. If there are one or more signatures, each signature's sighash
type must be examined. Inputs may only be added if all existing
signatures use SIGHASH_ANYONECANPAY. Outputs may only be added if all
existing signatures use SIGHASH_NONE. If an input has a signature using
SIGHASH_SINGLE, the same number of inputs and outputs must be added
before that input and it's corresponding output. For all other sighash
types (i.e. SIGHASH_ALL and any future sighash types), no inputs or
outputs may be added to the PSBT. Specific exceptions can be made in the
future for additional sighash types.
Furthermore, these newly added inputs must follow additional lock time
rules. Because all signatures, regardless of sighash type, sign the
transaction lock time, newly added inputs when there are existing
signatures must have the same type of lock time used in the transaction,
and must be less than or equal to the transaction lock time. It must not
cause the transaction lock time to change, otherwise the signatures will
be invalidated.
Lastly, to uniquely identify transactions for combiners, a txid can be
computed from the information present in the PSBT. Internally, combiners
can create an unsigned transaction given the transaction version, the
input prevouts, the outputs, and the computed locktime. This can then be
used to calculate a txid and thus used as a way to identify PSBTs.
Combiners will need to do this for all version 2 PSBTs in order to avoid
combining distinct transactions.
Andrew Chow
On 12/9/20 5:25 PM, Andrew Chow wrote:
> Hi All,
>
> I would like to propose a new PSBT version that addresses a few
> deficiencies in the current PSBT v0. As this will be backwards
> incompatible, a new PSBT version will be used, v1.
>
> The primary change is to truly have all input and output data for each
> in their respective maps. Instead of having to parse an unsigned
> transaction and lookup some data from there, and other data from the
> correct map, all of the data for an input will be contained in its map.
> Doing so also disallows PSBT_GLOBAL_UNSIGNED_TX in this new version.
> Thus I propose that the following fields be added:
>
> Global:
> * PSBT_GLOBAL_TX_VERSION = 0x02
> * Key: empty
> * Value: 32-bit little endian unsigned integer for the transaction
> version number. Must be provided in PSBT v1 and omitted in v0.
> * PSBT_GLOBAL_PREFERRED_LOCKTIME = 0x03
> * Key: empty
> * Value: 32 bit little endian unsigned integer for the preferred
> transaction lock time. Must be omitted in PSBT v0. May be provided in
> PSBT v1, assumed to be 0 if not provided.
> * PSBT_GLOBAL_INPUT_COUNT = 0x04
> * Key: empty
> * Value: Compact size unsigned integer. Number of inputs in this
> PSBT. Must be provided in PSBT v1 and omitted in v0.
> * PSBT_GLOBAL_OUTPUT_COUNT = 0x05
> * Key: empty
> * Value: Compact size unsigned integer. Number of outputs in this
> PSBT. Must be provided in PSBT v1 and omitted in v0.
>
> Input:
> * PSBT_IN_PREVIOUS_TXID = 0x0e
> * Key: empty
> * Value: 32 byte txid of the previous transaction whose output at
> PSBT_IN_OUTPUT_INDEX is being spent. Must be provided in PSBT v1 and
> omitted in v0.
> * PSBT_IN_OUTPUT_INDEX = 0x0f
> * Key: empty
> * Value: 32 bit little endian integer for the index of the output
> being spent. Must be provided in PSBT v1 and omitted in v0.
> * PSBT_IN_SEQUENCE = 0x0f
> * Key: empty
> * Value: 32 bit unsigned little endian integer for the sequence
> number. Must be omitted in PSBT v0. May be provided in PSBT v1 assumed
> to be max sequence (0xffffffff) if not provided.
> * PSBT_IN_REQUIRED_LOCKTIME = 0x10
> * Key: empty
> * Value: 32 bit unsigned little endian integer for the lock time that
> this input requires. Must be omitted in PSBT v0. May be provided in PSBT
> v1, assumed to be 0 if not provided.
>
> Output:
> * PSBT_OUT_VALUE = 0x03
> * Key: empty
> * Value: 64-bit unsigned little endian integer for the output's
> amount in satoshis. Must be provided in PSBT v1 and omitted in v0.
> * PSBT_OUT_OUTPUT_SCRIPT = 0x04
> * Key: empty
> * Value: The script for this output. Otherwise known as the
> scriptPubKey. Must be provided in PSBT v1 and omitted in v0.
>
> This change allows for PSBT to be used in the construction of
> transactions. With these new fields, inputs and outputs can be added as
> needed. One caveat is that there is no longer a unique transaction
> identifier so more care must be taken when combining PSBTs.
> Additionally, adding new inputs and outputs must be done such that
> signatures are not invalidated. This may be harder to specify.
>
> An important thing to note in this proposal are the fields
> PSBT_GLOBAL_PREFERRED_LOCKTIME and PSBT_IN_REQUIRED_LOCKTIME. A Bitcoin
> transaction only has a single locktime yet a PSBT may have multiple
> locktimes. To choose the locktime for the transaction, finalizers must
> choose the maximum of all of the *_LOCKTIME fields.
> PSBT_IN_REQUIRED_LOCKTIME is added because some inputs, such as those
> involving OP_CHECKLOCKTIMEVERIFY, require a specific minimum locktime to
> be set. This field allows finalizers to choose a locktime that is high
> enough for all inputs without needing to understand the scripts
> involved. The PSBT_GLOBAL_PREFERRED_LOCKTIME is the locktime to use if
> no inputs require a particular locktime.
>
> As these changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1
> needs the version number bump to enforce backwards incompatibility.
> However once the inputs and outputs of a PSBT are decided, a PSBT could
> be "downgraded" back to v0 by creating the unsigned transaction from the
> above fields, and then dropping these new fields.
>
> If the list finds that these changes are reasonable, I will write a PR
> to modify BIP 174 to incorporate them.
>
> Thanks,
> Andrew Chow

2023-06-07 18:27:43

- reply

📅 Original date posted:2020-12-09
📝 Original message:Hi All,
I would like to propose a new PSBT version that addresses a few
deficiencies in the current PSBT v0. As this will be backwards
incompatible, a new PSBT version will be used, v1.
The primary change is to truly have all input and output data for each
in their respective maps. Instead of having to parse an unsigned
transaction and lookup some data from there, and other data from the
correct map, all of the data for an input will be contained in its map.
Doing so also disallows PSBT_GLOBAL_UNSIGNED_TX in this new version.
Thus I propose that the following fields be added:
Global:
* PSBT_GLOBAL_TX_VERSION = 0x02
* Key: empty
* Value: 32-bit little endian unsigned integer for the transaction
version number. Must be provided in PSBT v1 and omitted in v0.
* PSBT_GLOBAL_PREFERRED_LOCKTIME = 0x03
* Key: empty
* Value: 32 bit little endian unsigned integer for the preferred
transaction lock time. Must be omitted in PSBT v0. May be provided in
PSBT v1, assumed to be 0 if not provided.
* PSBT_GLOBAL_INPUT_COUNT = 0x04
* Key: empty
* Value: Compact size unsigned integer. Number of inputs in this
PSBT. Must be provided in PSBT v1 and omitted in v0.
* PSBT_GLOBAL_OUTPUT_COUNT = 0x05
* Key: empty
* Value: Compact size unsigned integer. Number of outputs in this
PSBT. Must be provided in PSBT v1 and omitted in v0.
Input:
* PSBT_IN_PREVIOUS_TXID = 0x0e
* Key: empty
* Value: 32 byte txid of the previous transaction whose output at
PSBT_IN_OUTPUT_INDEX is being spent. Must be provided in PSBT v1 and
omitted in v0.
* PSBT_IN_OUTPUT_INDEX = 0x0f
* Key: empty
* Value: 32 bit little endian integer for the index of the output
being spent. Must be provided in PSBT v1 and omitted in v0.
* PSBT_IN_SEQUENCE = 0x0f
* Key: empty
* Value: 32 bit unsigned little endian integer for the sequence
number. Must be omitted in PSBT v0. May be provided in PSBT v1 assumed
to be max sequence (0xffffffff) if not provided.
* PSBT_IN_REQUIRED_LOCKTIME = 0x10
* Key: empty
* Value: 32 bit unsigned little endian integer for the lock time that
this input requires. Must be omitted in PSBT v0. May be provided in PSBT
v1, assumed to be 0 if not provided.
Output:
* PSBT_OUT_VALUE = 0x03
* Key: empty
* Value: 64-bit unsigned little endian integer for the output's
amount in satoshis. Must be provided in PSBT v1 and omitted in v0.
* PSBT_OUT_OUTPUT_SCRIPT = 0x04
* Key: empty
* Value: The script for this output. Otherwise known as the
scriptPubKey. Must be provided in PSBT v1 and omitted in v0.
This change allows for PSBT to be used in the construction of
transactions. With these new fields, inputs and outputs can be added as
needed. One caveat is that there is no longer a unique transaction
identifier so more care must be taken when combining PSBTs.
Additionally, adding new inputs and outputs must be done such that
signatures are not invalidated. This may be harder to specify.
An important thing to note in this proposal are the fields
PSBT_GLOBAL_PREFERRED_LOCKTIME and PSBT_IN_REQUIRED_LOCKTIME. A Bitcoin
transaction only has a single locktime yet a PSBT may have multiple
locktimes. To choose the locktime for the transaction, finalizers must
choose the maximum of all of the *_LOCKTIME fields.
PSBT_IN_REQUIRED_LOCKTIME is added because some inputs, such as those
involving OP_CHECKLOCKTIMEVERIFY, require a specific minimum locktime to
be set. This field allows finalizers to choose a locktime that is high
enough for all inputs without needing to understand the scripts
involved. The PSBT_GLOBAL_PREFERRED_LOCKTIME is the locktime to use if
no inputs require a particular locktime.
As these changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1
needs the version number bump to enforce backwards incompatibility.
However once the inputs and outputs of a PSBT are decided, a PSBT could
be "downgraded" back to v0 by creating the unsigned transaction from the
above fields, and then dropping these new fields.
If the list finds that these changes are reasonable, I will write a PR
to modify BIP 174 to incorporate them.
Thanks,
Andrew Chow

2023-06-07 18:22:22

- reply

📅 Original date posted:2020-01-13
📝 Original message:On 1/13/20 9:28 AM, Peter D. Gray wrote:
> I don't have a specific attack in mind, but these signatures, if
> adopted by the community at large, will allow detection of-, and
> could mitigate damage from-, some broad "bug-classes".
>
> Consider if the PSBT Signer (hardware wallet) has bugs. Perhaps if
> you tweak the PSBT in some unnatural way it produces output that
> reveals the private key (duplicate k-value perhaps), or corrupts
> the display of the transaction in helpful (to the attacker) ways
> (typically case: output hidden as change).
Since the PSBT is to be signed by one of the Signers for the PSBT, I
don't see how this is useful. If it is mutated and the signer has bugs,
especially parsing bugs, the Signer also adding its signature won't
help. In your proposal, it is the Signer who adds the signature, so it
will receive a PSBT without auth sigs and thus that could be mutated to
trigger those bugs anyways.
> There could also be bugs in the Combiner/Finalizer which the MiTM
> wants to trigger. Legimate files, signed by the PSBT Signer, will not
> contain those attacks, so are "safer" to process, even if your
> Combiner's PSBT parser has bugs or is tragically dumb.
The job of Combiners is fairly limited and is really just related to
parsing the PSBT into some internal object then shuffling those fields
around. In that case, any bugs an attacker would want to exploit have to
be deserialization bugs, in which case, your auth sigs don't help. The
Combiner still has to deserialize the PSBT to get the signature, then it
needs to re-serialize the PSBT to check that signature. An attacker
could insert bad bytes into the PSBT which causes problems during
deserialization, before the Combiner is able to check the signature.
For Finalizers, since its job is to construct the final
scriptSig/scriptWitness, at worst, all it can do is produce an invalid
transaction. Finalizers don't have access to the private keys so there's
no bug possible that can result in a Finalizer producing a transaction
that reveals the private key.
>
> That's just it, when we receive a signed PSBT, at present we don't
> know *what* was signed without a complete understanding of the
> transaction, the input UTXO (at least syntactially), and PSBT file
> contents. If there are bugs in that understanding (ie. checks we
> all know are needed, but no-one actually implemented) then we might
> transmit an harmful transaction, or continue to process a file
> that has been corrupted-with-intent by a MiTM.
ISTM the same is true of your proposal. You need to deserialize the PSBT
and then figure out which fields were "original" and in what order. If
there is a bug in your deserialization, an attacker can still exploit
that. And if there is a bug in your reconstruction of "original", you'll
have false positives.
> It's fine to say that, but in an embedded environment, with very
> limited memory like the Coldcard, PGP isn't an option (signing vs.
> signature verification). I want to leverage the existing crypto and
> PKI that we already have in play.
My point was that you can achieve your MiTM protection by having the
signature separate from the PSBT. You can still make your ECDSA
signature and send it along with the PSBT, and you can do it with fixed
or exchanged keys, no need for parsing the PSBT itself. It can be part
of the transport protocol, not part of the data that is being transferred.
Andrew
>
>> On 1/11/20 3:17 PM, Dmitry Petukhov via bitcoin-dev wrote:
> ... [many valid points, repeated by Andrew] ...
>>> If there is MitM, checking something at Finalizer is likely too
>>> late - the party that can intercept PSBTs can finalize before the
>>> legitimate Finalizer and broadcast the transaction.
>
> Yes, that is a problem which is proposal does not address. If the
> MitM has control over both directions, in and out, then whatever
> he or she was trying to do will still happen. Personally, I'm okay
> with that as a limition, but using the same signatures features,
> and a pre-shared public key between the PSBT Creator and the Signer,
> we could block the Signer from looking at MitM'ed files. (The Signer
> would require and verify incoming unsigned PSBT to contain the
> last-output-section-signature thing.) I'm not planning on supporting
> that on the Coldcard (at least not yet), but with the proposed
> additions, it is possible to do without further changes to the PSBT
> spec.
>
>>> Participants can work from the same PSBT ...
>>> either pass two files (original and updated), or work out which fields
>>> (key-value blobs) to remove to get the 'source' PSBT (which might not be
>>> trivial with presense of proprietary and unknown fields). Even if you
>>> know which key-value pairs to remove, there is no requirement for
>>> ordering of the fields, and some signer can serialize them in different
>>> order after dserialize/sign/add-signatures/re-serialize operation.
> ...
>>> Introducing additional ordering or other structure requirements over
>>> simple key-value structure will add complexity to PSBT processing, and
>>> adding complexity on such a basic level should have really serious
>>> reasons, because that increases effort required for even basic
>>> implementations and increases chance of bugs.
>
> I want these signatures to protect against PSBT parsing bugs. That's
> why they are byte-level on the whole file contents, and not based
> on sub-sections of the file or various fields inside the file. Yes,
> there are non-linear PSBT paths that will be difficult or impossible
> to support with this approach. I would not expect implementations to
> do anything fancy to reconstruct PSBT contents, I think they would
> just track the complete file. In most setups today the Creator,
> Combiner and Finalizer are the same device, and they are desktop
> systems with gigs of memory.
>
>>> If there is some authority on the 'correctness' of 'original' PSBT
>>> (all particpants receive same PSBT at the start), particpants should
>>> check the signature by that authority. That authority might use
>>> the key used only for authentication, and not in the tx signing.
>
> Yes, this can be acheived by pre-sharing a public key with the
> Signer (described above). Only signed incoming PSBT's would be
> accepted. That key doesn't have anything to do with the blockchain
> or value transfer.
>
>>> I think you do not need to wait for officially-assigned key numbers,
>>> and can just implement the scheme you envision with proprietary keys,
>>> document and promote it. Then if it shows its usefulness, it will
>>> either become de-facto standard with your proprietary keys...
>
> Yes, 100% ... but I value the list's feedback, and I would prefer to
> start with a legitimate key number which I don't need to change later. It's
> a non-breaking change and I wouldn't propose it otherwise.
>
> ---
> Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
>
> On Mon, Jan 13, 2020 at 06:39:28AM +0000, Andrew Chow wrote:
>> I agree with Dimitry. I don't see the point of having the MiTM
>> protection within the PSBT structure itself, in addition to the fact
>> that adding new fields is largely unnecessary. In fact, I'm not quite
>> sure what kind of attack you are trying to defend against with this
>> proposal.
>>
>> If there is a MiTM who can modify your PSBT, then they can just modify
>> the result the signed PSBT to drop the auth signatures. Furthermore, any
>> modifications to scripts or UTXOs would just result in an invalid
>> signature, so only time is wasted. But you'll just waste time anyways
>> when you see a failed auth sig.
>>
>> Additionally, when a signer processes a PSBT, it will either accept the
>> PSBT and add a signature for its inputs, or reject it and do nothing.
>> Given this behavior (and I assume you aren't going to add auth sigs for
>> rejected PSBTs because that doesn't make any sense), then you already
>> have a signature there that covers everything your auth signature would
>> cover. So just verify those signatures instead; for any inputs with
>> signatures, everything you need to verify them are already there.
>>
>> Lastly, IMO, if you want MiTM protection, then you should do your
>> protection with out of band communication. Just PGP sign the PSBT (or
>> something similar) and send the signature along separately.
>>
>> Andrew
>>
>> On 1/11/20 3:17 PM, Dmitry Petukhov via bitcoin-dev wrote:
>>>
>>> I am not sure that this particular task should be done with data
>>> embedded in PSBT itself, and not with some sort of container that
>>> includes PSBT and the authentication information.
>>>
>>> The benefit seems to be in reusing PSBT structure for compatibilty, and
>>> this might be a valid way, although I do not agree with some of your
>>> points. I elaborate below:
>>>
>>>> 1) In the PSBT globals section, a signature over the "source" PSBT
>>>> file. It would cover all the bytes of the original PSBT file, as
>>>> it was received by the Signer.
>>>
>>> The problem of authenticating the contents of PSBT is independent of
>>> the signing action. PSBT might be altered on the path from Creator to
>>> Signer. Therefore you cannot always say that Signer will be an
>>> authority over 'correctness' of PSBT.
>>>
>>>> - At the end of the signing process, the Finalizer should check all
>>>> the Signers have worked from the same PSBT file (assuming that's
>>>> the flow expected)
>>>
>>> If there is MitM, checking something at Finalizer is likely too
>>> late - the party that can intercept PSBTs can finalize before the
>>> legitimate Finalizer and broadcast the transaction.
>>>
>>> Participants can work from the same PSBT file if they all receive the
>>> same PSBT, and not working in chain where next particpant receives
>>> updated PSBT from the previous participant. Otherwise they will need to
>>> either pass two files (original and updated), or work out which fields
>>> (key-value blobs) to remove to get the 'source' PSBT (which might not be
>>> trivial with presense of proprietary and unknown fields). Even if you
>>> know which key-value pairs to remove, there is no requirement for
>>> ordering of the fields, and some signer can serialize them in different
>>> order after dserialize/sign/add-signatures/re-serialize operation.
>>>
>>> Introducing additional ordering or other structure requirements over
>>> simple key-value structure will add complexity to PSBT processing, and
>>> adding complexity on such a basic level should have really serious
>>> reasons, because that increases effort required for even basic
>>> implementations and increases chance of bugs.
>>>
>>> If there is some authority on the 'correctness' of 'original' PSBT
>>> (all particpants receive same PSBT at the start), particpants should
>>> check the signature by that authority. That authority might use
>>> the key used only for authentication, and not in the tx signing.
>>>
>>> If particpants send PSBT in chain after adding their signatures, then
>>> each participant can add their signature to say 'the contents
>>> of PSBT after my updates should match this hash'.
>>>
>>> The signatures of previous participants in the chain most likely do not
>>> matter because of difficulty of restoring the contents of PSBT as it
>>> was before the previous particpant, if you do not pass _all_ the PSBTs
>>> (which is excessive).
>>>
>>>> 2) In the output section, specifically, the last key/value pair of
>>>> the last output of the transaction, I want to add a similar signature,
>>>> again signed by one of the keys used in the signing process. This
>>>> signature will cover all the bytes of the resulting (signed) PSBT
>>>> up to that point. Because it is the last output of the output
>>>> section, that signature will be the last few bytes of the PSBT file.
>>>> By "appending" the signature in this way, it's easier to validate
>>>> and create the signature, without blanking the signature area during
>>>> digest step.
>>>
>>> This will introduce unnecessary higher-level structure to PSBT for the
>>> reasons that I do not find strong enough for the amount of complexity
>>> added.
>>>
>>> Also, as I said above, you likely do not need more than one
>>> signature - if this is 'fan-out' scheme, then participants need do
>>> check the sig of authority that created PSBT; if this is piggy-back
>>> chain, then only previous particpant's signature is easily verifiable.
>>>
>>>> ## Next Steps
>>>>
>>>> I'd like to get two officially-assigned BIP-174 key numbers assigned
>>>> for these two signatures, and then I will see that it gets added
>>>> into Coldcard's firmware immediately. In time, other tools are
>>>> welcome to take advantage of these checks. I will also write a BIP
>>>> for this, and/or make an addition to BIP-174.
>>>
>>> I think you do not need to wait for officially-assigned key numbers,
>>> and can just implement the scheme you envision with proprietary keys,
>>> document and promote it. Then if it shows its usefulness, it will
>>> either become de-facto standard with your proprietary keys (and
>>> everyone will want to support 'Coldard PSBT auth' or whatever the name),
>>> or the scheme will have serious grounds to be converted to standard and
>>> have non-proprietary keys assigned.
>>>
>>> // Dmitry.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>

2023-06-07 18:22:21

- reply

📅 Original date posted:2020-01-13
📝 Original message:I agree with Dimitry. I don't see the point of having the MiTM
protection within the PSBT structure itself, in addition to the fact
that adding new fields is largely unnecessary. In fact, I'm not quite
sure what kind of attack you are trying to defend against with this
proposal.
If there is a MiTM who can modify your PSBT, then they can just modify
the result the signed PSBT to drop the auth signatures. Furthermore, any
modifications to scripts or UTXOs would just result in an invalid
signature, so only time is wasted. But you'll just waste time anyways
when you see a failed auth sig.
Additionally, when a signer processes a PSBT, it will either accept the
PSBT and add a signature for its inputs, or reject it and do nothing.
Given this behavior (and I assume you aren't going to add auth sigs for
rejected PSBTs because that doesn't make any sense), then you already
have a signature there that covers everything your auth signature would
cover. So just verify those signatures instead; for any inputs with
signatures, everything you need to verify them are already there.
Lastly, IMO, if you want MiTM protection, then you should do your
protection with out of band communication. Just PGP sign the PSBT (or
something similar) and send the signature along separately.
Andrew
On 1/11/20 3:17 PM, Dmitry Petukhov via bitcoin-dev wrote:
>
> I am not sure that this particular task should be done with data
> embedded in PSBT itself, and not with some sort of container that
> includes PSBT and the authentication information.
>
> The benefit seems to be in reusing PSBT structure for compatibilty, and
> this might be a valid way, although I do not agree with some of your
> points. I elaborate below:
>
>> 1) In the PSBT globals section, a signature over the "source" PSBT
>> file. It would cover all the bytes of the original PSBT file, as
>> it was received by the Signer.
>
> The problem of authenticating the contents of PSBT is independent of
> the signing action. PSBT might be altered on the path from Creator to
> Signer. Therefore you cannot always say that Signer will be an
> authority over 'correctness' of PSBT.
>
>> - At the end of the signing process, the Finalizer should check all
>> the Signers have worked from the same PSBT file (assuming that's
>> the flow expected)
>
> If there is MitM, checking something at Finalizer is likely too
> late - the party that can intercept PSBTs can finalize before the
> legitimate Finalizer and broadcast the transaction.
>
> Participants can work from the same PSBT file if they all receive the
> same PSBT, and not working in chain where next particpant receives
> updated PSBT from the previous participant. Otherwise they will need to
> either pass two files (original and updated), or work out which fields
> (key-value blobs) to remove to get the 'source' PSBT (which might not be
> trivial with presense of proprietary and unknown fields). Even if you
> know which key-value pairs to remove, there is no requirement for
> ordering of the fields, and some signer can serialize them in different
> order after dserialize/sign/add-signatures/re-serialize operation.
>
> Introducing additional ordering or other structure requirements over
> simple key-value structure will add complexity to PSBT processing, and
> adding complexity on such a basic level should have really serious
> reasons, because that increases effort required for even basic
> implementations and increases chance of bugs.
>
> If there is some authority on the 'correctness' of 'original' PSBT
> (all particpants receive same PSBT at the start), particpants should
> check the signature by that authority. That authority might use
> the key used only for authentication, and not in the tx signing.
>
> If particpants send PSBT in chain after adding their signatures, then
> each participant can add their signature to say 'the contents
> of PSBT after my updates should match this hash'.
>
> The signatures of previous participants in the chain most likely do not
> matter because of difficulty of restoring the contents of PSBT as it
> was before the previous particpant, if you do not pass _all_ the PSBTs
> (which is excessive).
>
>> 2) In the output section, specifically, the last key/value pair of
>> the last output of the transaction, I want to add a similar signature,
>> again signed by one of the keys used in the signing process. This
>> signature will cover all the bytes of the resulting (signed) PSBT
>> up to that point. Because it is the last output of the output
>> section, that signature will be the last few bytes of the PSBT file.
>> By "appending" the signature in this way, it's easier to validate
>> and create the signature, without blanking the signature area during
>> digest step.
>
> This will introduce unnecessary higher-level structure to PSBT for the
> reasons that I do not find strong enough for the amount of complexity
> added.
>
> Also, as I said above, you likely do not need more than one
> signature - if this is 'fan-out' scheme, then participants need do
> check the sig of authority that created PSBT; if this is piggy-back
> chain, then only previous particpant's signature is easily verifiable.
>
>> ## Next Steps
>>
>> I'd like to get two officially-assigned BIP-174 key numbers assigned
>> for these two signatures, and then I will see that it gets added
>> into Coldcard's firmware immediately. In time, other tools are
>> welcome to take advantage of these checks. I will also write a BIP
>> for this, and/or make an addition to BIP-174.
>
> I think you do not need to wait for officially-assigned key numbers,
> and can just implement the scheme you envision with proprietary keys,
> document and promote it. Then if it shows its usefulness, it will
> either become de-facto standard with your proprietary keys (and
> everyone will want to support 'Coldard PSBT auth' or whatever the name),
> or the scheme will have serious grounds to be converted to standard and
> have non-proprietary keys assigned.
>
> // Dmitry.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:17:52

- reply

📅 Original date posted:2019-05-01
📝 Original message:Hi Stepan,
I think that this would be a good extension.
Just for clairty, by xpub, do you mean the extended serialization format
defined in BIP 32 or the Base58 check encoded string of that serialization?
Andrew
On 4/26/19 11:21 AM, Stepan Snigirev via bitcoin-dev wrote:
> Hi list,
>
> I was looking at the bip174 PSBT specs, in particular for
> multisignature setup, and I think with current spec there is a way to
> steal user funds in M of N setup with M ≤ N/2.
>
> I made a small write-up on this:
> https://github.com/stepansnigirev/random_notes/blob/master/psbt_multisig.md
>
> To compress:
>
> Currently in PSBT there is no way to reliably say if the output uses
> the keys derived from the same root keys as the inputs aside from the
> key owned by the signer => there is no way to verify that the output
> is a change output in multisig setup.
>
> Therefore an attacker can replace half of the keys in the change
> address by his own keys and still get the transaction signed.
>
> I suggest to add an xpub field to the inputs and outputs metadata,
> then signers can verify that the same xpubs are used for public keys
> in inputs and outputs => output is indeed a change.
>
> Normally change and receiving addresses are derived from the same xpub
> with non-hardened derivation pathes, so providing xpub after the last
> hardened index should be enough to see that public keys of inputs and
> change output are derived from the same xpub.
>
> I suggest to add the following key-value pairs to PSBT:
>
> Type: BIP 32 public key `PSBT_IN_BIP32_XPUB = 0x10`
> - Key: derivation path for xpub
> `{0x10}|{master key fingerprint}|{32-bit int}|...|{32-bit int}`
> - Value: 78-byte xpub value
> `{xpub}`
>
> Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB = 0x03`
> - Key: derivation path for xpub
> `{0x03}|{master key fingerprint}|{32-bit int}|...|{32-bit int}`
> - Value: 78-byte xpub value
> `{xpub}`
>
> Derivation paths are in the key of the key-value pair as they are used
> for lookup, and xpub itself is the actual value being looked up.
>
> I also want to mention that Trezor for example doesn't suffer from
> this problem as they use xpubs to verify change outputs. So it may
> make sense to go through the communication protocols of existing
> hardware / multisignature wallets and see if there is something else
> we are missing.
>
> If everyone is happy about the proposal I would prepare a pull request
> to the bip.
>
> Best regards,
> Stepan Snigirev.
>

2023-06-07 18:13:10

- reply

📅 Original date posted:2018-06-23
📝 Original message:On 06/23/2018 10:00 AM, William Casarin wrote:
> Since we're still considering the encoding, I wonder if it would be a
> good idea to have a human-readible part like lightning invoices[1]?
I don't think that is necessary.
> Then perhaps you could drop the magic code as well?
The magic is still necessary for the binary format in order to prevent
normal transaction deserializers from accidentally deserializing a psbt.
> Also we could do a base encoding that excludes + and / characters, such
> as base62 (gmp-style). It's easier to copy/paste (double clicking a
> string stops at / or + in base64 encodings).
While that would be ideal, I think it is better to use an encoding that
most wallets already support. Most wallets already have Base64 decoding
available so that they can decode signed messages which also use Base64
encoding. I think it is unnecessary to introduce another encoding.
On 06/23/2018 11:27 AM, Peter D. Gray wrote:
> Personally, I don't think you should spec an encoding. It should be binary only and hex for developers and JSON interfaces. My thinking is that PSBT's are not user-visible things. They have a short lifetime and are nothing something that is "stored" or referenced much later. Hex is good enough and has no downsides as an excoding except for density.
I think what will end up happening though is that, at least in the
beginning, PSBTs will primarily be strings that people end up copy and
pasting. Since a PSBT can get pretty large, the strings are rather
cumbersome to move around, especially as hex. At least with Base64 the
strings will be smaller.
> On the other hand, suggesting a filename extension (probably .PSBT?) and a mime-type to match, are helpful since wallets and such will want to register with their operating systems to become handlers of those mimetypes. Really that's a lot more important for interoperability at this point, than an encoding.
Agreed. I will include those in the BIP.
> Looking forward to test vectors, and I might have more to say once my code can handle them (again).
>
> Feedback on the BIP as it stands now:
>
> - Appendix A needs an update, and I suggest defining symbols (PK_PARTIAL_SIG == 0x02) for the numeric key values. This helps implementers as we don't all define our own symbols and/or use numeric constants in our code.
Okay.
> - Those tables are just not working. Might want to reformat as descriptive lists, point form, or generally anything else... sorry.
I will try my best to fix that. Mediawiki sucks...
Andrew

2023-06-07 18:04:51

- reply

📅 Original date posted:2017-08-18
📝 Original message:Hi everyone,
I would like to propose a standard format for unsigned and partially signed
transactions.
===Abstract===
This document proposes a binary transaction format which contains the
information
necessary for a signer to produce signatures for the transaction and holds
the
signatures for an input while the input does not have a complete set of
signatures.
The signer can be offline as all necessary information will be provided in
the
transaction.
===Motivation===
Creating unsigned or partially signed transactions to be passed around to
multiple
signers is currently implementation dependent, making it hard for people
who use
different wallet software from being able to easily do so. One of the goals
of this
document is to create a standard and extensible format that can be used
between clients to allow
people to pass around the same transaction to sign and combine their
signatures. The
format is also designed to be easily extended for future use which is
harder to do
with existing transaction formats.
Signing transactions also requires users to have access to the UTXOs being
spent. This transaction
format will allow offline signers such as air-gapped wallets and hardware
wallets
to be able to sign transactions without needing direct access to the UTXO
set and without
risk of being defrauded.
The full text can be found here:
https://github.com/achow101/bips/blob/bip-psbt/bip-psbt.mediawiki
Andrew Chow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170818/3166e8de/attachment.html>

2023-06-07 18:01:40

- reply

📅 Original date posted:2017-05-23
📝 Original message:Hi James,
>From what I understand, this proposal is incompatible with the current
segwit implementation with regards to the NODE_WITNESS service bit. I
believe it could cause network partitioning if the service bit is not
changed.
Andrew
On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrote:
> I would like to propose an implementation that accomplishes the first
> part of the Barry Silbert proposal independently from the second:
>
> "Activate Segregated Witness at an 80% threshold, signaling at bit 4"
> in a way that
>
> The goal here is to minimize chain split risk and network disruption
> while maximizing backwards compatibility and still providing for rapid
> activation of segwit at the 80% threshold using bit 4.
>
> By activating segwit immediately and separately from any HF we can
> scale quickly without risking a rushed combined segwit+HF that would
> almost certainly cause widespread issues.
>
> Draft proposal:
> https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>
> Proposal text:
> <pre>
> BIP: segsignal
> Layer: Consensus (soft fork)
> Title: Reduced signalling threshold activation of existing segwit deployment
> Author: James Hilliard <james.hilliard1 at gmail.com>
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
> </pre>
>
> ==Abstract==
>
> This document specifies a method to activate the existing BIP9 segwit
> deployment with a majority hashpower less than 95%.
>
> ==Definitions==
>
> "existing segwit deployment" refer to the BIP9 "segwit" deployment
> using bit 1, between November 15th 2016 and November 15th 2017 to
> activate BIP141, BIP143 and BIP147.
>
> ==Motivation==
>
> Segwit increases the blocksize, fixes transaction malleability, and
> makes scripting easier to upgrade as well as bringing many other
> [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower. For a number of reasons a complete redeployment of segwit
> is difficulty to do until the existing deployment expires. This is due
> to 0.13.1+ having many segwit related features active already,
> including all the P2P components, the new network service flag, the
> witness-tx and block messages, compact blocks v2 and preferential
> peering. A redeployment of segwit will need to redefine all these
> things and doing so before expiry would greatly complicate testing.
>
> ==Specification==
>
> While this BIP is active, all blocks must set the nVersion header top
> 3 bits to 001 together with bit field (1<<1) (according to the
> existing segwit deployment). Blocks that do not signal as required
> will be rejected.
>
> ==Deployment==
>
> This BIP will be deployed by a "version bits" with an 80%(this can be
> adjusted if desired) activation threshold BIP9 with the name
> "segsignal" and using bit 4.
>
> This BIP will have a start time of midnight June 1st, 2017 (epoch time
> 1496275200) and timeout on midnight November 15th 2017 (epoch time
> 1510704000). This BIP will cease to be active when segwit is
> locked-in.
>
> === Reference implementation ===
>
> <pre>
> // Check if Segregated Witness is Locked In
> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
> Consensus::Params& params)
> {
> LOCK(cs_main);
> return (VersionBitsState(pindexPrev, params,
> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
> THRESHOLD_LOCKED_IN);
> }
>
> // SEGSIGNAL mandatory segwit signalling.
> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
> &&
> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> // Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
> and is not active.
> {
> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS;
> bool fSegbit = (pindex->nVersion &
> VersionBitsMask(chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGWIT)) != 0;
> if (!(fVersionBits && fSegbit)) {
> return state.DoS(0, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> }
> }
> </pre>
>
> https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1
>
> ==Backwards Compatibility==
>
> This deployment is compatible with the existing "segwit" bit 1
> deployment scheduled between midnight November 15th, 2016 and midnight
> November 15th, 2017. Miners will need to upgrade their nodes to
> support segsignal otherwise they may build on top of an invalid block.
> While this bip is active users should either upgrade to segsignal or
> wait for additional confirmations when accepting payments.
>
> ==Rationale==
>
> Historically we have used IsSuperMajority() to activate soft forks
> such as BIP66 which has a mandatory signalling requirement for miners
> once activated, this ensures that miners are aware of new rules being
> enforced. This technique can be leveraged to lower the signalling
> threshold of a soft fork while it is in the process of being deployed
> in a backwards compatible way.
>
> By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
> deployment, this BIP can cause the existing "segwit" deployment to
> activate without needing to release a new deployment.
>
> ==References==
>
> *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html
> Mailing list discussion]
> *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
> P2SH flag day activation]
> *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
> *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
> *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
> *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
> Version 0 Witness Program]]
> *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]
> *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
> *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
> *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]
>
> ==Copyright==
>
> This document is dual licensed as BSD 3-clause, and Creative Commons
> CC0 1.0 Universal.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev