npub1fg…xak44

Last Notes

2023-06-07 23:00:36 UTC

- reply

📅 Original date posted:2021-11-17
📝 Original message:Prior to 0.19.0, creating outputs with an unknown witness version was considered non-standard. This was a violation of BIP 173 and was fixed for 0.19.0+ in PR #15846.
On 11/16/2021 10:17 PM, n1ms0s via bitcoin-dev wrote:
> Hello all,
> I am currently working on a fork of bitcoinj with basic Taproot support. Currently it supports basic sending and receiving with Taproot addresses using a bitcoinj SPV wallet.
> See here: https://github.com/n1ms0s/bitcoinj
>
> It supports the above along with public/private key tweaking. Feel free to take a look, and leave feedback or even work on it yourself and submit a pull request.
>
> One issue I am running into right now though is when broadcasting a Taproot transaction to older nodes (old as in ~0.18.0) I get an error response of "Witness version reserved for soft-fork upgrades". Anyone have any idea why this happens? I have a stackexchange question open here for it:
> https://bitcoin.stackexchange.com/questions/110787/issue-when-broadcasting-taproot-transaction-to-older-nodes
>
> n1ms0s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211117/d99c1571/attachment.html>

2023-06-07 22:55:46 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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:30:32 UTC

- reply

📅 Original date posted:2021-03-15
📝 Original message:I don't think we should have a followup deployment start so close to to
timeout of ST. I think it would be better to schedule the followup
around ST, especially since the details around that are fuzzier and
dependent on the results of ST itself.
That being said, I'm not opposed to moving everything one period earlier
or shortening the activation or locked in periods, but I'm not sure if
that is the best course of action right now.
Andrew
On 3/14/21 10:51 PM, Luke Dashjr wrote:
> The last period before timeoutheight here overlaps with the current BIP8(True)
> deployment plan. So if this period specifically were to reach 90% signalling,
> nodes would activate Taproot at height 697536, but ST-only nodes would still
> wait until 709632 instead.
>
> Probably the best solution is to just move this ST window 1 period earlier?
>
> Luke
>
>
> On Saturday 06 March 2021 06:04:22 Andrew Chow via bitcoin-dev wrote:
>> I like this idea.
>>
>> In terms of actual parameters, I propose that we base this Speedy Trial
>> off of BIP 8 with the following parameters:
>> * start height = 681408
>> * timeout height = 695520
>> * lockinontimeout = False
>> * signaling bit = 2
>> * threshold = 1815/2016 blocks (90%)
>>
>> For the extended lockin period, I propose 14112 blocks, which is 7
>> retarget periods. Thus the earliest activation height will be 697536 and
>> the latest activation height will be 709632.
>>
>> This will give us an approximate start time of May 1st 2021 and an
>> approximate timeout time of August 7th 2021, for a total activation
>> period of just over 3 months. The extended lockin period is the same
>> number of blocks as the activation period so that will also be just over
>> 3 months, giving us the latest activation time of November 13th, 2021.
>> If miners activated as soon as possible, the earliest activation time
>> would be August 21st 2021.
>>
>> Additionally, this timeline assumes a mid-April release of Bitcoin Core
>> 0.21.1 containing these parameters. They could be changed to move up if
>> the expected release date were sooner.
>>
>>
>> Andrew Chow
>>
>> On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote:
>>> On the ##taproot-activation IRC channel, Russell O'Connor recently
>>> proposed a modification of the "Let's see what happens" activation
>>> proposal.[1] The idea received significant discussion and seemed
>>> acceptable to several people who could not previously agree on a
>>> proposal (although this doesn't necessarily make it their first
>>> choice). The following is my attempt at a description.
>>>
>>> 1. Start soon: shortly after the release of software containing this
>>> proposed activation logic, nodes will begin counting blocks towards
>>> the 90% threshold required to lock in taproot.[2]
>>>
>>> 2. Stop soon: if the lockin threshold isn't reached within approximately
>>> three months, the activation attempt fails. There is no mandatory
>>> activation and everyone is encouraged to try again using different
>>> activation parameters.
>>>
>>> 2. Delayed activation: in the happy occasion where the lockin threshold
>>> is reached, taproot is guaranteed to eventually activate---but not
>>> until approximately six months after signal tracking started.
>>>
>>> ## Example timeline
>>>
>>> (All dates approximate; see the section below about BIP9 vs BIP8.)
>>>
>>> - T+0: release of one or more full nodes with activation code
>>> - T+14: signal tracking begins
>>> - T+28: earliest possible lock in
>>> - T+104: locked in by this date or need to try a different activation
>>> process - T+194: activation (if lockin occurred)
>>>
>>> ## Analysis
>>>
>>> The goal of Speedy Trial is to allow a taproot activation attempt to
>>> either quickly succeed or quickly fail---without compromising safety in
>>> either case. Details below:
>>>
>>> ### Mitigating the problems of early success
>>>
>>> New rules added in a soft fork need to be enforced by a large part of
>>> the economy or there's a risk that a long chain of blocks breaking the
>>> rules will be accepted by some users and rejected by others, causing a
>>> chain split that can result in large direct losses to transaction
>>> receivers and potentially even larger indirect losses to holders due to
>>> reduced confidence in the safety of the Bitcoin system.
>>>
>>> One step developers have taken in the past to ensure widespread adoption
>>> of new consensus rules is programming in a delay between the time
>>> software with those rules is expected to be released and when the
>>> software starts tracking which blocks signal for activation. For
>>> example:
>>>
>>> Soft fork | Release | Start | Delta
>>> -----------------+------------+------------+----------
>>> BIP68 (v0.12.1) | 2016-04-15 | 2016-05-11 | 26 days
>>> BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
>>>
>>> Sources: BitcoinCore.org,
>>> https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
>>>
>>> Speedy Trial replaces most of that upfront delay with a backend delay.
>>> No matter how fast taproot's activation threshold is reached by miners,
>>> there will be six months between the time signal tracking starts and when
>>> nodes will begin enforcing taproot's rules. This gives the userbase even
>>> more time to upgrade than if we had used the most recently proposed start
>>> date for a BIP8 activation (~July 23rd).[2]
>>>
>>> ### Succeed, or fail fast
>>>
>>> The earlier version of this proposal was documented over 200 days ago[3]
>>> and taproot's underlying code was merged into Bitcoin Core over 140 days
>>> ago.[4] If we had started Speedy Trial at the time taproot
>>> was merged (which is a bit unrealistic), we would've either be less than
>>> two months away from having taproot or we would have moved on to the
>>> next activation attempt over a month ago.
>>>
>>> Instead, we've debated at length and don't appear to be any closer to
>>> what I think is a widely acceptable solution than when the mailing list
>>> began discussing post-segwit activation schemes over a year ago.[5] I
>>> think Speedy Trial is a way to generate fast progress that will either
>>> end the debate (for now, if activation is successful) or give us some
>>> actual data upon which to base future taproot activation proposals.
>>>
>>> Of course, for those who enjoy the debate, discussion can continue while
>>> waiting for the results of Speedy Trial.
>>>
>>> ### Base activation protocol
>>>
>>> The idea can be implemented on top of either Bitcoin Core's existing
>>> BIP9 code or its proposed BIP8 patchset.[6]
>>>
>>> - BIP9 uses two time-based[7] parameters, starttime and timeout. Using
>>> these values plus a time-based parameter for the minimum activation
>>> delay would give three months for miners to activate taproot, but some
>>> of that time near the start or the end might not be usable due to
>>> signals only being measured in full retarget periods. However, the
>>> six month time for users to upgrade their node would be not be
>>> affected by either slow or fast block production.
>>>
>>> BIP9 is already part of Bitcoin Core and I think the changes being
>>> proposed would be relatively small, resulting in a small patch that
>>> could be easy to review.
>>>
>>> - BIP8 uses two height-based parameters, startheight and timeoutheight.
>>> Using height values would ensure miners had a certain number of
>>> retarget periods (6) to lock in taproot and that there'd be a certain
>>> number of blocks (about 24,000) until activation, although latest lock
>>> in and expected activation could occur moderately earlier or later
>>> than the estimated three and six months.
>>>
>>> BIP8 would likely be used if Speedy Trial fails, so it could be
>>> advantageous to base this proposal on BIP8 so that we gain
>>> experience running that code in production.
>>>
>>> For additional discussion about using times versus heights, see today's
>>> log for ##taproot-activation.[11]
>>>
>>> ### Additional concerns
>>>
>>> - Encourages false signaling: false signaling is when miners signal
>>> readiness to enforce rules that their nodes don't actually support.
>>> This was partially responsible for a six-block reorg shortly after the
>>> final BIP66 activation[8] and was found to still be a problem during
>>> the BIP68 lockin period despite BIP9 being designed to avoid it.[9]
>>>
>>> Because Speedy Trial only gives miners a maximum of three months to
>>> signal support for taproot, it may encourage such false signaling. If
>>> taproot locks in as a result of their signaling but most of them fail
>>> to upgrade by the activation date several months later, unprepared
>>> miners could lose large amounts of money and users could see long
>>> reorgs (with unupgraded nodes and SPV lite clients potentially losing
>>> money).
>>>
>>> Compared to other activation proposals, I think the only difference is
>>> Speedy Trial's short timeline. False signaling is possible with any
>>> other proposal and the same problems can occur if miners fail to
>>> upgrade for any mandatory activation.
>>>
>>> ### Additional advantages
>>>
>>> - No mandatory signaling: at no time are miners required to signal by
>>> Speedy Trial. This includes no mandatory signaling during the
>>> locked_in period(s), although such signaling will be encouraged (as it
>>> was with BIP9[10]).
>>>
>>> - Party time: to a lesser degree, a benefit mentioned for flag day
>>> activation may also apply here: we could get up to six months
>>> advanced notice of taproot activation, allowing users, developers, and
>>> organizations to prepare software, announcements, and celebrations for
>>> that event.
>>>
>>> ## Implementation details and next steps
>>>
>>> Initial discussion about implementation may be found in today's
>>> ##taproot-activation log.[11] If it appears Speedy Trial may have
>>> traction, Russell O'Connor has offered to work on a patch against BIP8
>>> implementing it.
>>>
>>> ## Acknowledgments
>>>
>>> The original idea for a short-duration attempt was discussed in the
>>> ##taproot-activation IRC channel last July and the revised idea saw
>>> additional evaluation there this week. Despite growing frustration,
>>> discussion has been overwhelmingly constructive, for which all the
>>> contributors should be commended. Although this should not in any way
>>> imply endorsement, I'm grateful for the review and comments on a draft
>>> of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,
>>> Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell
>>> O'Connor, and IRC users maybehuman and proofofkeags
>>>
>>> ## Footnotes
>>>
>>> [1]
>>> https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see
>>> _what_happens.2C_BIP8.28false.2C_3m.29
>>>
>>> [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period
>>> seemed to have near-universal support during the 2021-02-16 IRC
>>> meeting. See:
>>> https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
>>>
>>> [3]
>>> https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&oldi
>>> d=68062
>>>
>>> [4] https://github.com/bitcoin/bitcoin/pull/19953
>>>
>>> [5]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/0175
>>> 47.html
>>>
>>> [6] https://github.com/bitcoin/bitcoin/pull/19573
>>>
>>> [7] BIP9's times are based on the median of the past 11 blocks, which
>>> usually trails UTC by about 90 minutes but which can trail behind
>>> realtime significantly if miners are doing weird things.
>>>
>>> [8] https://en.bitcoin.it/wiki/July_2015_chain_forks
>>>
>>> [9] https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32
>>>
>>> [10]
>>> https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf
>>> 9348f3a/src/test/versionbits_tests.cpp#L337-L339
>>>
>>> [11] http://gnusha.org/taproot-activation/2021-03-05.log
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:30:30 UTC

- reply

📅 Original date posted:2021-03-06
📝 Original message:I like this idea.
In terms of actual parameters, I propose that we base this Speedy Trial
off of BIP 8 with the following parameters:
* start height = 681408
* timeout height = 695520
* lockinontimeout = False
* signaling bit = 2
* threshold = 1815/2016 blocks (90%)
For the extended lockin period, I propose 14112 blocks, which is 7
retarget periods. Thus the earliest activation height will be 697536 and
the latest activation height will be 709632.
This will give us an approximate start time of May 1st 2021 and an
approximate timeout time of August 7th 2021, for a total activation
period of just over 3 months. The extended lockin period is the same
number of blocks as the activation period so that will also be just over
3 months, giving us the latest activation time of November 13th, 2021.
If miners activated as soon as possible, the earliest activation time
would be August 21st 2021.
Additionally, this timeline assumes a mid-April release of Bitcoin Core
0.21.1 containing these parameters. They could be changed to move up if
the expected release date were sooner.
Andrew Chow
On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote:
> On the ##taproot-activation IRC channel, Russell O'Connor recently
> proposed a modification of the "Let's see what happens" activation
> proposal.[1] The idea received significant discussion and seemed
> acceptable to several people who could not previously agree on a
> proposal (although this doesn't necessarily make it their first
> choice). The following is my attempt at a description.
>
> 1. Start soon: shortly after the release of software containing this
> proposed activation logic, nodes will begin counting blocks towards
> the 90% threshold required to lock in taproot.[2]
>
> 2. Stop soon: if the lockin threshold isn't reached within approximately
> three months, the activation attempt fails. There is no mandatory
> activation and everyone is encouraged to try again using different
> activation parameters.
>
> 2. Delayed activation: in the happy occasion where the lockin threshold
> is reached, taproot is guaranteed to eventually activate---but not
> until approximately six months after signal tracking started.
>
> ## Example timeline
>
> (All dates approximate; see the section below about BIP9 vs BIP8.)
>
> - T+0: release of one or more full nodes with activation code
> - T+14: signal tracking begins
> - T+28: earliest possible lock in
> - T+104: locked in by this date or need to try a different activation process
> - T+194: activation (if lockin occurred)
>
> ## Analysis
>
> The goal of Speedy Trial is to allow a taproot activation attempt to
> either quickly succeed or quickly fail---without compromising safety in
> either case. Details below:
>
> ### Mitigating the problems of early success
>
> New rules added in a soft fork need to be enforced by a large part of
> the economy or there's a risk that a long chain of blocks breaking the
> rules will be accepted by some users and rejected by others, causing a
> chain split that can result in large direct losses to transaction
> receivers and potentially even larger indirect losses to holders due to
> reduced confidence in the safety of the Bitcoin system.
>
> One step developers have taken in the past to ensure widespread adoption
> of new consensus rules is programming in a delay between the time software
> with those rules is expected to be released and when the software starts
> tracking which blocks signal for activation. For example:
>
> Soft fork | Release | Start | Delta
> -----------------+------------+------------+----------
> BIP68 (v0.12.1) | 2016-04-15 | 2016-05-11 | 26 days
> BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
>
> Sources: BitcoinCore.org, https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
>
> Speedy Trial replaces most of that upfront delay with a backend delay.
> No matter how fast taproot's activation threshold is reached by miners,
> there will be six months between the time signal tracking starts and when
> nodes will begin enforcing taproot's rules. This gives the userbase even
> more time to upgrade than if we had used the most recently proposed start
> date for a BIP8 activation (~July 23rd).[2]
>
> ### Succeed, or fail fast
>
> The earlier version of this proposal was documented over 200 days ago[3]
> and taproot's underlying code was merged into Bitcoin Core over 140 days
> ago.[4] If we had started Speedy Trial at the time taproot
> was merged (which is a bit unrealistic), we would've either be less than
> two months away from having taproot or we would have moved on to the
> next activation attempt over a month ago.
>
> Instead, we've debated at length and don't appear to be any closer to
> what I think is a widely acceptable solution than when the mailing list
> began discussing post-segwit activation schemes over a year ago.[5] I
> think Speedy Trial is a way to generate fast progress that will either
> end the debate (for now, if activation is successful) or give us some
> actual data upon which to base future taproot activation proposals.
>
> Of course, for those who enjoy the debate, discussion can continue while
> waiting for the results of Speedy Trial.
>
> ### Base activation protocol
>
> The idea can be implemented on top of either Bitcoin Core's existing
> BIP9 code or its proposed BIP8 patchset.[6]
>
> - BIP9 uses two time-based[7] parameters, starttime and timeout. Using
> these values plus a time-based parameter for the minimum activation
> delay would give three months for miners to activate taproot, but some
> of that time near the start or the end might not be usable due to
> signals only being measured in full retarget periods. However, the
> six month time for users to upgrade their node would be not be
> affected by either slow or fast block production.
>
> BIP9 is already part of Bitcoin Core and I think the changes being
> proposed would be relatively small, resulting in a small patch that
> could be easy to review.
>
> - BIP8 uses two height-based parameters, startheight and timeoutheight.
> Using height values would ensure miners had a certain number of
> retarget periods (6) to lock in taproot and that there'd be a certain
> number of blocks (about 24,000) until activation, although latest lock
> in and expected activation could occur moderately earlier or later
> than the estimated three and six months.
>
> BIP8 would likely be used if Speedy Trial fails, so it could be
> advantageous to base this proposal on BIP8 so that we gain
> experience running that code in production.
>
> For additional discussion about using times versus heights, see today's
> log for ##taproot-activation.[11]
>
> ### Additional concerns
>
> - Encourages false signaling: false signaling is when miners signal
> readiness to enforce rules that their nodes don't actually support.
> This was partially responsible for a six-block reorg shortly after the
> final BIP66 activation[8] and was found to still be a problem during
> the BIP68 lockin period despite BIP9 being designed to avoid it.[9]
>
> Because Speedy Trial only gives miners a maximum of three months to
> signal support for taproot, it may encourage such false signaling. If
> taproot locks in as a result of their signaling but most of them fail
> to upgrade by the activation date several months later, unprepared
> miners could lose large amounts of money and users could see long
> reorgs (with unupgraded nodes and SPV lite clients potentially losing
> money).
>
> Compared to other activation proposals, I think the only difference is
> Speedy Trial's short timeline. False signaling is possible with any
> other proposal and the same problems can occur if miners fail to
> upgrade for any mandatory activation.
>
> ### Additional advantages
>
> - No mandatory signaling: at no time are miners required to signal by
> Speedy Trial. This includes no mandatory signaling during the
> locked_in period(s), although such signaling will be encouraged (as it
> was with BIP9[10]).
>
> - Party time: to a lesser degree, a benefit mentioned for flag day
> activation may also apply here: we could get up to six months
> advanced notice of taproot activation, allowing users, developers, and
> organizations to prepare software, announcements, and celebrations for
> that event.
>
> ## Implementation details and next steps
>
> Initial discussion about implementation may be found in today's
> ##taproot-activation log.[11] If it appears Speedy Trial may have
> traction, Russell O'Connor has offered to work on a patch against BIP8
> implementing it.
>
> ## Acknowledgments
>
> The original idea for a short-duration attempt was discussed in the
> ##taproot-activation IRC channel last July and the revised idea saw
> additional evaluation there this week. Despite growing frustration,
> discussion has been overwhelmingly constructive, for which all the
> contributors should be commended. Although this should not in any way
> imply endorsement, I'm grateful for the review and comments on a draft
> of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,
> Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell
> O'Connor, and IRC users maybehuman and proofofkeags
>
> ## Footnotes
>
> [1] https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29
>
> [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period
> seemed to have near-universal support during the 2021-02-16 IRC
> meeting. See: https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
>
> [3] https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&oldid=68062
>
> [4] https://github.com/bitcoin/bitcoin/pull/19953
>
> [5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
>
> [6] https://github.com/bitcoin/bitcoin/pull/19573
>
> [7] BIP9's times are based on the median of the past 11 blocks, which
> usually trails UTC by about 90 minutes but which can trail behind
> realtime significantly if miners are doing weird things.
>
> [8] https://en.bitcoin.it/wiki/July_2015_chain_forks
>
> [9] https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32
>
> [10] https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339
>
> [11] http://gnusha.org/taproot-activation/2021-03-05.log
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:22:22 UTC

- 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 UTC

- 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:19:17 UTC

- reply

📅 Original date posted:2019-07-09
📝 Original message:This was the original intent of the sighash field. Either the sighash is acceptable to the signer and the signer signs with it, or they do not sign at all.
On 7/9/19 11:58 AM, Jonathan Underwood via bitcoin-dev wrote:
> Hi all,
>
> Just to be brief, I'll kick off with an attack scenario.
>
> 1. I am a signer, I get a PSBT that is ready to sign. I parse. I sign according to the PSBT as-is.
> 2. I notice my UTXO was stolen by a hacker because they changed my PSBT input's sighashtype to SIGHASH_ANYONECANPAY | SIGHASH_NONE and after the fact they changed the outputs to send to themselves, and added an input they signed with SIGHASH_ALL.
> 3. I lose the BTC in my UTXO.
>
> So we should definitely add to the signer checks "ensure the sighash type given is the type of sighash you want to sign." etc.
>
> My proposal for a wording change would be addition to the bullet list:
>
> - If a sighash type is provided, the signer MUST check that the sighash type is acceptable to them, and fail signing if unacceptable.
> - If a sighash type is not provided, the signer SHOULD sign using SIGHASH_ALL, but may sign with any sighash type they wish.
>
> Any thoughts?
>
> Thanks,
> Jon
>
> --
>
> -----------------
> Jonathan Underwood
> ビットバンク社　チーフビットコインオフィサー
> -----------------
>
> 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
>
> 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190709/c75ad156/attachment-0001.html>

2023-06-07 18:17:52 UTC

- 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 17:57:42 UTC

- reply

📅 Original date posted:2017-03-23
📝 Original message:The issue is due to Segwit blocks since Testnet has already activated
Segwit. 0.12.x- nodes will receive a Segwit block with all of the
witnesses stripped. When they relay this block to a 0.13.0+ node, the
block will be rejected because those have Segwit functionality and
require the witnesses to be in the block. Given that Testnet has a
smaller number of nodes and less difficulty, this could result in some
miners using 0.13.0+ mining blocks which do not propagate well and thus
causing multiple chain splits and reorgs as other miners find blocks for
the same height before receiving a block for that height.
On 3/23/2017 6:37 PM, Juan Garavaglia via bitcoin-dev wrote:
>
> We notice some reorgs in Bitcoin testnet, while reorgs in testnet are
> common and may be part of different tests and experiments, it seems
> the forks are not created by a single user and multiple blocks were
> mined by different users in each chain. My first impression was that
> the problem was related to network issues but some Bitcoin explorers
> were following one chain while others follow the other one.
> Nonetheless, well established explorers like blocktrail.com or
> blockr.io were following different chains at different heights which
> led to me to believe that it was not a network issue. After some time,
> a reorg occurs and it all comes to normal state as a single chain.
>
> We started investigating more and we identified that the fork occurs
> with nodes 0.12; in some situations, nodes 0.12 has longer/different
> chains. The blocks in both chains are valid so something must be
> occurring in the communication between nodes but not related with the
> network itself.
>
> Long story short, when nodes 0.13+ receive blocks from 0.13+ nodes all
> is ok, and those blocks propagate to older nodes with no issues. But
> when a block tries to be propagated from bitcoind 0.12.+ to newer ones
> those blocks are NOT being propagated to the peers with newer versions
> while these newer blocks are being propagated to peers with older
> versions with no issues.
>
> My conclusion is that we have a backward compatibility issue between
> 0.13.X+ and older versions.
>
> The issue is simple to replicate, first, get latest version of
> bitcoind, complete the IBD after is at current height, then force it
> to use exclusively one or more peers of versions 0.12.X and older, and
> you will notice that the latest version node will never receive a new
> block.
>
> Probably some alternative bitcoin implementations act as bridges
> between these two versions and facilitate the chain reorgs.
>
> I have not yet found any way where/how it can be used in a malicious
> way or be exploited by a miner but in theory Bitcoin 0.13.X+ should
> remain compatible with older ones, but a 0.13+ node may become
> isolated by 0.12 peers, and there is not notice for the node owner.
>
>
>
>
>
> _______________________________________________
> 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/20170323/a54eedc6/attachment-0001.html>