why cant we have multiple input more than 2 > s for merge , merge split etc

[nikhil478]

@paulsp94 @viralbhadeshiya @adityapanther-vaionex @cainnusti @BishopVNX

[cainnusti]

Hi @nikhil478 thanks for the question. The current templates only support two inputs for merging due to a limitation in the smart contract design. This restriction is based on script size, as the transaction size grows exponentially with the addition of more inputs. New script templates are being developed to remove this limitation, but there is no confirmed release date yet.

Using the two-input limit, we can create multiple merge transactions to consolidate them into a single UTXO. Although this process generates many transactions, the total size of the combined transactions remains smaller than the exponential growth that occurs when adding more inputs to a merge or merge-split transaction.

I will work on adding a bulk merging component to the library to assist developers in constructing the necessary transactions to consolidate UTXOs. This will involve providing a single STAS script and an array of objects representing each UTXO ({vout, satoshis, txid}). A fee module will also be included to calculate the fees for each transaction.

The output will be an array of transactions that can be bulk broadcasted to ARC or mAPI nodes. I have developed some proof-of-concept models that can bulk merge 500 UTXOs in a single broadcast event.

[nikhil478]

oh gotcha r u checking script size on web2 level or is this an script condition which we need to satisfy? @cainnusti

with bigger script size only cons is high fee right ?

[nikhil478]

or could you share your poc model is possible

[cainnusti]

oh gotcha r u checking script size on web2 level or is this an script condition which we need to satisfy? @cainnusti

with bigger script size only cons is high fee right ?

It is a script condition but as part of the design its more about size and practicality. The number of transactions is not the issue its more about the overall size to process the consolidation of UTXOs. The optimal method is using a layered approach to merging with transfers transactions to keep the overall size lower.

[cainnusti]

or could you share your poc model is possible

Here is an example of the model to follow in the image The general process for the most optimal method is as follows

1. All UTXOs previous transactions should be minimal size which is a transfer transaction.
2. All UTXOs can be in two sequential merge transactions before the UTXO is required to be "reset" which is just constructing another transfer transaction.
3. Repeat the process until reaching the single UTXO remaining.

Things to consider

• The initial transfer transactions for each UTXO are not required if you already have the previous transaction hex and if the previous transaction is a transfer transaction. It may be simpler to treat all UTXOs as needing to be transferred first if your logic does not maintain the previous transaction hex or transaction type.

• When dealing with an odd number of UTXOs that result in remainder UTXOs during the process, these can be added to the next layer of merging.

• Since all STAS scripts are the same for merge and transfer transactions, we can accurately estimate fee costs for each process. To avoid handling multiple change UTXOs from the fees of each transaction, I recommend using the zeroChange parameter in the merge and transfer functions. To make this practical, you need to know the number of merge and transfer transactions required, then create a pre-transaction that provides outputs in BSV for the process, using the fee estimate function to determine the correct amount for the fees for the transfer and merge transactions.

I will work to add a module for merging to the library in the meantime.

[nikhil478]

Hi @cainnusti thanks for explaining , i am having one query like why size of script increases so much while merging

[cainnusti]

Hi @cainnusti thanks for explaining , I am having one query like why size of script increases so much while merging

@nikhil478 the way the smart contract is defined requires the previous transaction pieces to be part of the unlocking script. After each merge transaction the unlocking script grows at an exponential rate, this is because the previous transaction grows each time with the addition of more data. To circumvent this we can add interval transfer transactions after each 2 sequential merge transactions for each UTXO, as mentioned in the method above.

I will provide a module for merging to the library as soon as possible. Thanks