@apoelstra @real-or-random @jonasnick @sanket1729 Perhaps the documentation here needs some disclaimer at least about the potential pitfalls of using it directly to construct a wallet. It's not intended for that purpose, only for things like representing otherwise incomplete knowledge in e.g. inference, but adding it to the descriptor language does make it available for all purposes. Can you help think about examples/pitfalls that could be listed?

Agreed that the documentation needs a disclaimer. The two drawbacks that I can think of.

1. This one is listed in the BIP 341: If people directly use output keys in aggregation using proofs of knowledge.(https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_ref-22-0)
2. In future protocol constructions, it might be desirable to prove that there is no script path given TxOut/ScriptPubKey/Address. This is not possible when using rawtr(), but is possible with tr() by revealing the internal key.

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()?

The only pitfall I see is the one mentioned by @sanket1729 : 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() over raw()?

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.

@apoelstra https://twitter.com/achow101/status/1459617340123926534 may or may not have been related. Arguably, not a good justification, but a use case nonetheless...

Not the worst usecase :) I use vanity addresses in Liquid test networks sometimes to make logs easier to read and having descriptor support in Core could plausibly make that better.

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.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #24897 ([Draft / POC] Silent Payments by w0xlt)

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.

@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:

# First address
"desc":    "tr([8324d0e9/0]03a669ea926f381582ec4a000b9472ba8a17347f5fb159eddd4a07036a6718eb)#05zmkxzl"
"desc": "rawtr([8324d0e9/0]03a669ea926f381582ec4a000b9472ba8a17347f5fb159eddd4a07036a6718eb)#5rk6yanl"

# Second address
"desc":    "tr([8324d0e9/1]bbf56b14b119bccafb686adec2e3d2a6b51b1626213590c3afa815d1fd36f85d)#0djkz4yx"
"desc": "rawtr([8324d0e9/1]bbf56b14b119bccafb686adec2e3d2a6b51b1626213590c3afa815d1fd36f85d)#56xhsw4x"

Shouldn't rawtr() generate just a single address ?

Different keys give rise to different addresses....

Rebased.

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'll get back to this soon.

This might fix the CI errors:
In test/functional/wallet_taproot.py (9342970):

  from test_framework.key import H_POINT
+ from test_framework.segwit_addr import encode_segwit_address

Rebased, and made a few changes:

• Added a warning to doc/descriptors.md, and some other changes, following Add rawtr() descriptor for P2TR with specified (tweaked) output key #23480 (comment) by @real-or-random.
• Fixed test failure, following Add rawtr() descriptor for P2TR with specified (tweaked) output key #23480 (comment) by @w0xlt.
• Renamed internal_key -> output_key following Add rawtr() descriptor for P2TR with specified (tweaked) output key #23480 (comment) by @sanket1729.

ACK 544b433