A suggestion is made to introduce a global field combining a 33-byte scan key with a set of indexes, aiming to simplify the system while accommodating dynamic modifications to inputs. This approach raises concerns about the reliance on the ordering of inputs, given that inputs can be added or removed when "Inputs Modifiable" is enabled. The risk highlighted is that any sequence-dependent operations could be jeopardized by inputs being incorrectly positioned, implying a need for careful management during construction.

Further, the communication touches upon the necessity for constructors to verify the absence of ANYONECANPAY sighashes in any inputs before proceeding with silent payments. This precaution extends to updaters who must also perform checks, although it's noted these verifications might not necessitate changes to the PSBT_GLOBAL_TX_MODIFIABLE field. The introduction of a "Has Silent Payments" flag within this context is justified by drawing parallels to the existing "Has Sighash Single" flag, underscoring the importance of distinguishing transactions accommodating silent payments.

The dialogue also references a discussion with @josibake, though details are somewhat vague. It revisits the stance on ANYONECANPAY sighashes, concluding that their presence does not inherently complicate transactions, provided certain conditions are met. Specifically, silent payment outputs should only be introduced when no inputs exist, the inputs lack signatures, or if the "Inputs Modifiable" setting is inactive. Moreover, as long as an input adheres to the SIGHASH_ALL protocol, the involvement of ANYONECANPAY is deemed non-problematic, suggesting a nuanced understanding of transaction dynamics and security implications.