It may be useful to be able to represent P2TR outputs in descriptors whose script tree and/or internal key aren’t known. This PR does that, by adding a rawtr(KEY) descriptor, where the KEY represents the output key directly. If the private key corresponding to that output key is known, it also permits signing with it.
I’m not convinced this is desirable, but presumably “tr(KEY)” sounds more intended for direct use than “rawtr(KEY)”.
72@@ -73,6 +73,7 @@ Descriptors consist of several types of expressions. The top level expression is
73 - `tr(KEY)` or `tr(KEY,TREE)` (top level only): P2TR output with the specified key as internal key, and optionally a tree of script paths.
74 - `addr(ADDR)` (top level only): the script which ADDR expands to.
75 - `raw(HEX)` (top level only): the script whose hex encoding is HEX.
76+- `rawtr(KEY)` (top level only): P2TR output with the specified key as tweaked key.
tweaked key could be confusing unless you know what’s going on under the hood of taproot. Maybe something like output key would be better
Agreed that the documentation needs a disclaimer. The two drawbacks that I can think of.
Some more points for discussion:
Can we separate descriptors into two types in the spec itself? So, we can have addr, raw, rawtr into the infer-only category. The rest into another category that we can sign. In the infer only category, we can restrict the KEY expression to be a concrete public key without any BIP32 derivations or wildcards.
Correct me if I am wrong if the only use of inferred descriptors is that I can give it another party for watching a particular txout for me without revealing/knowing how the txout was constructed. So, assuming we disallow signing rawtr() (to encourage the usage of tr ) is there is any use of rawtr() over raw()?
rawtr() is potentially incomplete information because there could always be another way to spend that you don’t know about… But that’s exactly its feature, so I guess it’s fine. Anyway, I think if you do “raw” stuff, you should be know what you’re doing.
- is there is any use of
rawtr()overraw()?
I second that question.
Right; I guess the only advantage of rawtr over raw/addr is dealing with cases where the public key is either actually untweaked (and e.g. you need want to provide origin information along with it) or it is tweaked in an unknown way, but you have the tweaked private key.
raw() in those cases cannot represent all information you have, while rawtr can.
Agree with Sanket’s comments. I also agree that having raw in the name should be sufficient warning for users to avoid this, especially since it’s not any harder to use tr.
Regarding the usefulness, I think it’s definitely useful for “infer-only” cases like running scanutxoset. May also be useful for recovery scenarios … although it’s hard for me to think of a case where you’ve generated a weird Taproot key but somehow need Bitcoin Core to spend it.
A usecase for rawtr. Note that this protocol is not reviewed(and might be insecure), but I am starting to think we don’t want to preclude people from using new ways to create output keys. In this protocol, it is still possible to prove that there is no script spend using a different way than revealing the internal key. Such proof is not required for the correctness above protocol, but it highlights that there might be other ways to prove the non-existence of script spend than revealing the internal key.
Although as I mentioned later in response comment, this can also be made compatible with tr descriptor. But doing so would be inefficient and it offers no benefit because we can already prove that there is no script spend.
Overall, I am leaning towards a concept ACK for this.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Should tr(xpriv) and rawtr(xpriv) return different addresses ?
I created two blank wallets and imported tr(xpriv) into one and rawtr(xpriv) into the other. The xpriv was the same.
The addresses have the same desc property but not the same address, as seen below.
There are also some fields missing from the address generated from rawtr(xpriv) like timestamp.
0$ ./src/bitcoin-cli -regtest -named createwallet wallet_name=tr_test blank=true
1
2$ ./src/bitcoin-cli -regtest importdescriptors "[{\"desc\": \"tr(tprv8ZgxMBicQKsPdKziibn63Rm6aNzp7dSjDnufZMStXr71Huz7iihCRpbZZZ6Voy5HyuHCWx6foHMipzMzUq4tZrtkZ24DJwz5EeNWdsuwX5h/*)#223d6gp6\", \"active\": true, \"timestamp\": \"now\"}]"
3
4$ ./src/bitcoin-cli -regtest -named createwallet wallet_name=rawtr_test blank=true
5
6$ ./src/bitcoin-cli -regtest -rpcwallet="rawtr_test" importdescriptors "[{\"desc\": \"rawtr(tprv8ZgxMBicQKsPdKziibn63Rm6aNzp7dSjDnufZMStXr71Huz7iihCRpbZZZ6Voy5HyuHCWx6foHMipzMzUq4tZrtkZ24DJwz5EeNWdsuwX5h/*)#223d6gp6\", \"active\": true, \"timestamp\": \"now\"}]"
7
8$ ./src/bitcoin-cli -regtest -rpcwallet="tr_test" -named getnewaddress address_type='bech32m'
9bcrt1p8eafa4hnyfae7kyc42ehndduu49zfuhneerma58j2xexc6lx5wxsm8e5j7
10
11$ ./src/bitcoin-cli -regtest -rpcwallet="rawtr_test" -named getnewaddress address_type='bech32m'
12bcrt1pqwnxn65jduuptqhvfgqqh9rjh29pwdrlt7c4nmwafgrsx6n8rr4supy9dh
13
14$ ./src/bitcoin-cli -regtest -rpcwallet="rawtr_test" getaddressinfo "bcrt1pqwnxn65jduuptqhvfgqqh9rjh29pwdrlt7c4nmwafgrsx6n8rr4supy9dh"
15{
16 "address": "bcrt1pqwnxn65jduuptqhvfgqqh9rjh29pwdrlt7c4nmwafgrsx6n8rr4supy9dh",
17 "scriptPubKey": "512003a669ea926f381582ec4a000b9472ba8a17347f5fb159eddd4a07036a6718eb",
18 "ismine": true,
19 "solvable": true,
20 "desc": "rawtr([8324d0e9/0]03a669ea926f381582ec4a000b9472ba8a17347f5fb159eddd4a07036a6718eb)#5rk6yanl",
21 "parent_desc": "rawtr(tpubD6NzVbkrYhZ4Wo2WcFSgSqRD9QWkGxddo6WSqsVBx7uQ8QEtM7WncKDRjhFEexK119NigyCsFygA4b7sAPQxqebyFGAZ9XVV1BtcgNzbCRR/*)#x2xz0lq0",
22 "iswatchonly": false,
23 "isscript": true,
24 "iswitness": true,
25 "witness_version": 1,
26 "witness_program": "03a669ea926f381582ec4a000b9472ba8a17347f5fb159eddd4a07036a6718eb",
27 "ischange": false,
28 "labels": [
29 ""
30 ]
31}
32
33$ ./src/bitcoin-cli -regtest -rpcwallet="tr_test" getaddressinfo "bcrt1p8eafa4hnyfae7kyc42ehndduu49zfuhneerma58j2xexc6lx5wxsm8e5j7"
34{
35 "address": "bcrt1p8eafa4hnyfae7kyc42ehndduu49zfuhneerma58j2xexc6lx5wxsm8e5j7",
36 "scriptPubKey": "51203e7a9ed6f3227b9f5898aab379b5bce54a24f2f3ce47bed0f251b26c6be6a38d",
37 "ismine": true,
38 "solvable": true,
39 "desc": "tr([8324d0e9/0]03a669ea926f381582ec4a000b9472ba8a17347f5fb159eddd4a07036a6718eb)#05zmkxzl",
40 "parent_desc": "tr(tpubD6NzVbkrYhZ4Wo2WcFSgSqRD9QWkGxddo6WSqsVBx7uQ8QEtM7WncKDRjhFEexK119NigyCsFygA4b7sAPQxqebyFGAZ9XVV1BtcgNzbCRR/*)#fdlr9alf",
41 "iswatchonly": false,
42 "isscript": true,
43 "iswitness": true,
44 "witness_version": 1,
45 "witness_program": "3e7a9ed6f3227b9f5898aab379b5bce54a24f2f3ce47bed0f251b26c6be6a38d",
46 "ischange": false,
47 "timestamp": 1646090838,
48 "hdkeypath": "m/0",
49 "hdseedid": "0000000000000000000000000000000000000000",
50 "hdmasterfingerprint": "8324d0e9",
51 "labels": [
52 ""
53 ]
54}
@w0xlt Yes, that’d definitely expected. rawtr(KEY) literally puts the key in the scriptPubKey directly. tr(KEY) will construct an output key derived from KEY as internal key.
If the two weren’t different, we wouldn’t need to add rawtr in the first place.
@sipa Thanks for the clarification.
But since the wallet is able to generate multiple addresses for rawtr(KEY), I assumed that there would also be key derivations for KEY in this case.
For example:
0# First address
1"desc": "tr([8324d0e9/0]03a669ea926f381582ec4a000b9472ba8a17347f5fb159eddd4a07036a6718eb)#05zmkxzl"
2"desc": "rawtr([8324d0e9/0]03a669ea926f381582ec4a000b9472ba8a17347f5fb159eddd4a07036a6718eb)#5rk6yanl"
3
4# Second address
5"desc": "tr([8324d0e9/1]bbf56b14b119bccafb686adec2e3d2a6b51b1626213590c3afa815d1fd36f85d)#0djkz4yx"
6"desc": "rawtr([8324d0e9/1]bbf56b14b119bccafb686adec2e3d2a6b51b1626213590c3afa815d1fd36f85d)#56xhsw4x"
Shouldn’t rawtr() generate just a single address ?
It looks like the CI is failing due to the difference between the expected result and the RPC result in rpc_decodescript.py:decodescript_datadriven_tests().
Script (first element in rpc_decodescript.json):
5120eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
Expected result:
{'asm': '1 eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee', 'address': 'bcrt1pamhwamhwamhwamhwamhwamhwamhwamhwamhwamhwamhwamhwamhqz6nvlh', 'desc': 'addr(bcrt1pamhwamhwamhwamhwamhwamhwamhwamhwamhwamhwamhwamhwamhqz6nvlh)#v52jnujz', 'type': 'witness_v1_taproot'}
RPC result:
{'asm': '1 eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee', 'desc': 'rawtr(eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee)#jk7c6kys', 'address': 'bcrt1pamhwamhwamhwamhwamhwamhwamhwamhwamhwamhwamhwamhwamhqz6nvlh', 'type': 'witness_v1_taproot'}
wallet_taroot.py is also failing. Apparently the PSBT is not completing and assert(res['complete']) fails.
I noticed the behavior below. I’m not sure if it’s as expected.
The address bcrt1...8n6wyskueguk returns the tr(...) descriptor in getaddressinfo RPC, which looks correct as it was generated via getnewaddress '' 'bech32m'
But when this same address is used as the recipient of a transaction, its descriptor is displayed as rawtr(...), as seen below.
0$ bitcoin-cli -regtest -rpcwallet="receiver" getnewaddress '' 'bech32m'
1bcrt1pwlhw9uxkga774g6er3hthkaa4npvr2zcutt4gcqxyf5f2y8n6wyskueguk
2
3$ bitcoin-cli -regtest -rpcwallet="receiver" getaddressinfo "bcrt1pwlhw9uxkga774g6er3hthkaa4npvr2zcutt4gcqxyf5f2y8n6wyskueguk"
4{
5 "address": "bcrt1pwlhw9uxkga774g6er3hthkaa4npvr2zcutt4gcqxyf5f2y8n6wyskueguk",
6 "scriptPubKey": "512077eee2f0d6477deaa3591c6ebbdbbdacc2c1a858e2d754600622689510f3d389",
7 ...
8 "desc": "tr([92c4c112/86'/1'/0'/0/0]a612d64e3415afb653e98da12bb34a9c0785a10c6880cbf0436791a89428826b)#f67tyh68",
9 ...
10}
11
12$ bitcoin-cli -regtest -rpcwallet="sender" -named send outputs="{\"bcrt1pwlhw9uxkga774g6er3hthkaa4npvr2zcutt4gcqxyf5f2y8n6wyskueguk\": 12.00000381}" fee_rate=1 options="{\"add_to_wallet\": false }"
13{
14 ...
15 "hex": "020000...ca3078fbd0900000000"
16}
17
18$ bitcoin-cli -regtest decodetransaction "020000...ca3078fbd0900000000"
19{
20 "txid": "fa4f78fc970bbae4e932690b5b9370d18545316f43fa126991a0e76cf57a1e63",
21 "hash": "dc5ac5d41fd0cf0b4990f9cafb3b64eac5b05680776e80c61f3867ee51b70df2",
22 "version": 2,
23 ...
24 "vout": [
25 {
26 "value": 12.00000381,
27 "n": 0,
28 "scriptPubKey": {
29 "asm": "1 77eee2f0d6477deaa3591c6ebbdbbdacc2c1a858e2d754600622689510f3d389",
30 "desc": "rawtr(77eee2f0d6477deaa3591c6ebbdbbdacc2c1a858e2d754600622689510f3d389)#u26fgmea",
31 "hex": "512077eee2f0d6477deaa3591c6ebbdbbdacc2c1a858e2d754600622689510f3d389",
32 "address": "bcrt1pwlhw9uxkga774g6er3hthkaa4npvr2zcutt4gcqxyf5f2y8n6wyskueguk",
33 "type": "witness_v1_taproot"
34 }
35 },
36 ...
37 ]
38}
Concept ACK. Agree with @sanket1729’s thoughts.
A usecase for rawtr. Note that this protocol is not reviewed(and might be insecure), but I am starting to think we don’t want to preclude people from using new ways to create output keys.
As others have said wallet_taproot.py is still failing. I’m getting a:
TypeError: do_test() takes 5 positional arguments but 6 were given on Line 449.
0self.do_test(
1 "rawtr(XPRV)",
2 "rawtr($1/*)",
3 [True],
4 lambda k1: key(k1),
5 1
6 )
Is the 1 needed?
edit: Removing the 1 hits the assert(res['complete']) previously encountered error again.
928+ if (!xpk.IsFullyValid()) return {};
929+ WitnessV1Taproot output{xpk};
930+ return Vector(GetScriptForDestination(output));
931+ }
932+public:
933+ RawTRDescriptor(std::unique_ptr<PubkeyProvider> internal_key) : DescriptorImpl(Vector(std::move(internal_key)), "rawtr") {}
nit: here and elsewhere
Perhaps better renamed as output_key over internal_key
Tested ACK https://github.com/bitcoin/bitcoin/pull/23480/commits/9342970d7253abbf97c2bde6c242e29d9445c311.
This rawtr implementation is used in PR #24897 and has been successfully stored and spent on signet.
Perhaps the documentation here needs some disclaimer at least about the potential pitfalls of using it directly to construct a wallet.
I think the doc part is still unresolved?
This might fix the CI errors:
In test/functional/wallet_taproot.py (https://github.com/bitcoin/bitcoin/pull/23480/commits/9342970d7253abbf97c2bde6c242e29d9445c311):
0 from test_framework.key import H_POINT
1+ from test_framework.segwit_addr import encode_segwit_address
Rebased, and made a few changes:
