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@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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to