Tapret tweak in change output for witness transfers

[St333p]

When creating tapret transfers towards a witness beneficiary, the tapret host is always set on the change output. I imagine this is to avoid the complexity of adding the taproot tweak to the descriptor on the receiver side.

Is this a protocol-level restriction or is it possible to support transfers with a tapret tweak on a receiver's witness output?
Is all the data required to reconstruct the taproot tweak already available to the receiver or would this require changes to the consignment structure?

[dr-orlovsky]

I imagine this is to avoid the complexity of adding the taproot tweak to the descriptor on the receiver side.

Correct. Also the receiving part may not be a taproot wallet and can't accept an output with tapret tweak.

Is this a protocol-level restriction or is it possible to support transfers with a tapret tweak on a receiver's witness output?

It is not a consensus-, consignment- or persistence-level restriction or a limitation. It is just the only way of implementation which makes sense. But someone else may write a different implementation of they need to.

Is all the data required to reconstruct the taproot tweak already available to the receiver or would this require changes to the consignment structure?

Yes, they are there: the tweak can be always deterministically reconstructed by the receiver from the anchor data he receives anyway with the consignment. At the end of the day the receiver has to validate all hostorical opret and tapret tweaks, including the last one, so indeed he has all information to reproduce them.

[St333p]

Yes, they are there: the tweak can be always deterministically reconstructed by the receiver from the anchor data he receives anyway with the consignment. At the end of the day the receiver has to validate all hostorical opret and tapret tweaks, including the last one, so indeed he has all information to reproduce them.

Thanks for confirming it's possible. I think I managed to reconstruct the tweak from the consignment data, but RgbDescr::add_tapret_tweak takes a Terminal in input and I'm not able to reconstruct that on the receiver side. Could you give me a hint, please?

[dr-orlovsky]

There are two different layers, consensus and wallets, which need tapret tweak ingormation.

Consensus has it (and use in validation), but wallet doesn't have access to it directly - at least in a simple unconvoluted way. It was easier to get wallet to track relevant taptweaks independently from the consensus, to simplify all the APIs. Thus, wallet needs terminal info to do that.

[St333p]

While trying to implement the required logic to tweak an output other than the change, I bumped into an issue that seems to derive from taproot specification details.
Let's say A wants to send assets to a witness beneficiary B, so B shares a taproot address t with A. Since B doesn't know that A wants to add a script path to it, t includes a dummy tweak (t=t0+h(t0)) according to taproot specification:

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(hashTapTweak(bytes(P)))G.

A then proceeds to build a transaction sending some coins to t, for instance in vout 0. This output is then chosen to include the tapret tweak, so coins now go to address t'=t=h(t||Mr). To be able to recognize t' as his own, B should apply the two tweaks sequentially, as t'=t0+h(t0)+h(t0+h(t0)||Mr), which deviates from the taproot standard and seems to be currently not supported by the wallet tooling.

Alternatively, this could be also solved by B also sharing the internal key t0 together with the address t (e.g. within the invoice?), which means that A can now use it directly in case it need to include the tapret tweak on its output. This would be cleaner, but it introduces a communication burden which might not be desirable.

[dr-orlovsky]

To be able to recognize t' as his own, B should apply the two tweaks sequentially, as t'=t0+h(t0)+h(t0+h(t0)||Mr), which deviates from the taproot standard and seems to be currently not supported by the wallet tooling.

No, it does not. This won't work this way; the party A must share not an address but an internal (untweaked) key.

Alternatively, this could be also solved by B also sharing the internal key t0 together with the address t (e.g. within the invoice?), which means that A can now use it directly in case it need to include the tapret tweak on its output.

Exactly

This would be cleaner, but it introduces a communication burden which might not be desirable.

This is the only way anyway. Two tweeks would contradict Taproot standard and BIPs