Feature request: support payload distribution option in tx Generator

[witter-deland]

Is your feature request related to a problem? Please describe.

In the Kaspa blockchain, when a large transaction exceeds the single transaction limit, it is split into multiple smaller transactions. Currently, if these transactions include a payload, only the final transaction in the sequence carries this payload. This behavior is problematic in scenarios where the payload serves as a memo for identifying deposits, as having the payload only in the final transaction may not meet the requirements of such use cases.

Describe the solution you'd like

Introduce an optional parameter, payloadDistribution, in the transaction generator settings. This parameter will enable developers to specify their preferred payload distribution strategy:
"FinalOnly": Attach the payload only to the final transaction in the sequence (default behavior).
"AllTxs": Attach the payload to every transaction in the sequence.

Describe alternatives you've considered

An alternative could be to manually handle payload distribution outside of the transaction generator, but this would require additional logic and complexity in the application code. Another option could be to modify the existing RPC API to handle payloads differently, but this might break compatibility with existing implementations.

Additional context

By offering this optional parameter, developers gain more flexibility in managing payload distribution, which can be crucial for applications relying on payloads for transaction identification. This solution maintains compatibility with existing RPC APIs while providing additional control over transaction construction, ensuring that the transaction generator remains versatile and developer-friendly.

[KaffinPX]

But final transaction will be the one reflecting your outputs passed into Generator? So other transactions are obsolete/unrelated with that exchange deposit scenario.

[witter-deland]

You've got a valid point, but let me clarify. This feature request is solely about determining where to include the payload within the transaction. It doesn't impact the original outputs' output logic at all.
Regarding the deposit scenario I described, the payload acts as a deposit identification code. In the case of a large-sized KAS transfer, if the size of a single transaction is too big, it will be automatically split into multiple smaller-sized transactions. Each of these transactions will carry this deposit identification code in its payload. This allows the Exchange to identify these transactions as part of the same deposit, even though they are split. So, the other transactions aren't obsolete or unrelated; they are just fragmented parts of the overall deposit operation, all linked by this common payload.

[KaffinPX]

Exchanges doesn't need to identify these transactions to make process work, these transactions are related with UTXO compounding/management. Also HD wallets are the only privacy measure in Kaspa and by that "distribution" you are revealing owner of addresses of your account(Can get linked by analysis)...

[witter-deland]

A Kaspa transaction can consist of multiple UTXOs from different addresses. These UTXOs come from various sources, and in our deposit scenario, we need to identify a unique source address. Therefore, we need to construct a specific payload deposit identifier for users to recognize which user made the deposit.

What I am describing is not the logic of a centralized exchange, but rather a Layer 2 solution (We have developed an independent Layer 2 solution) to address specific scenarios for the interoperability of underlying assets.

Thus, I submitted this PR. The default behavior of this PR remains consistent with the current code implementation, but it allows developers the option to attach this payload to each transaction (to avoid situations where some deposits are overlooked due to the absence of a deposit identifier in split scenarios).