bug – How can i respond to a transaction request in NDC protocol

Currently i’m working on NDC central i am able to load the screens and states but now i’m struggling with transaction reply.

Currently im sending this message:

x00x0c4x1c000x1c555x1c035x1c0101x1c65652035x1c000x0cx00x0c

last 3 chars is ending the printer data field var and providing the trailer but the ATM return an error (non-decimal digits)

can any one who has worked with similar projects provide me a transaction reply message or at least explain it to me field by field

I have the manual (from the ATM CD) but i have problems understanding transaction reply section

signature – How to verify if a transaction is signed correctly?

Pubkey script alone is not enough to verify a transaction, you’ll need:

  1. Pubkey script, to evaluate the scripts
  2. Amount, in order to check if the sum of inputs is bigger than or equal to sum of outputs
  3. Index (in TxOut list) and tx hash of the transaction being spent
  4. Block height so that you can set the consensus rules

After gathering all the above (should be found in the node’s UTXO database) you can start evaluating if the provided script is valid which isn’t limited to signature verification but running/evaluating the script that includes checking correctness of the script, OP codes, OP count, script size,…
A lot of the verification can be found in validation.cpp file.
This is also how I do it in Bitcoin.Net library.

Blockchain transaction change output

I’m very new to this.
It’s hard to know for sure, but what’s most likely the case with the below transaction:

enter image description here

  1. Someone sent 25.99 bitcoin to another person/organization
  2. Someone sent 1 bitcoin to another person/organization
  3. Someone sent 26.99 bitcoin to another person/organization

Blockchain transaction unspent [duplicate]

This is a bitcoin transaction as shown in a blockchain explorer. What does ‘2 confirmations’ mean here? Sorry for the picture quality.
Which one is the best answer?

enter image description here

  1. 2 confirmations by miners are required for this transaction to be accepted by the network
  2. 2 other blockchain nodes have confirmed this transaction
  3. The transaction is included in one block (of the blockchain) whose hash is included in the previous block

utxo – What happens if 2 transaction spend to the same output?

I’m looking though the blockchain, and I’ve found 2 transactions in different blocks, which have the same hash:

block 91812:

    "result": {
        "hash": "00000000000af0aed4792b1acee3d966af36cf5def14935db8de83d6f9306f2f",
        "confirmations": 545294,
        "strippedsize": 616,
        "size": 616,
        "weight": 2464,
        "height": 91812,
        "version": 1,
        "versionHex": "00000001",
        "merkleroot": "49991d7653bec6efebee7d11f27ca2dffcc35ebe95ee5eebd602916b2f2fa665",
        "tx": [
            {
                "txid": "d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599",
                "hash": "d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599",
                "version": 1,
                "size": 133,
                "vsize": 133,
                "weight": 532,
                "locktime": 0,
                "vin": [
                    {
                        "coinbase": "0456720e1b00",
                        "sequence": 4294967295
                    }
                ],
                "vout": [
                    {
                        "value": 50.00000000,
                        "n": 0,
                        "scriptPubKey": {
                            "asm": "046896ecfc449cb8560594eb7f413f199deb9b4e5d947a142e7dc7d2de0b811b8e204833ea2a2fd9d4c7b153a8ca7661d0a0b7fc981df1f42f55d64b26b3da1e9c OP_CHECKSIG",
                            "hex": "41046896ecfc449cb8560594eb7f413f199deb9b4e5d947a142e7dc7d2de0b811b8e204833ea2a2fd9d4c7b153a8ca7661d0a0b7fc981df1f42f55d64b26b3da1e9cac",
                            "type": "pubkey"
                        }
                    }
                ],
                "hex": "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff060456720e1b00ffffffff0100f2052a010000004341046896ecfc449cb8560594eb7f413f199deb9b4e5d947a142e7dc7d2de0b811b8e204833ea2a2fd9d4c7b153a8ca7661d0a0b7fc981df1f42f55d64b26b3da1e9cac00000000"
            },
            {
                "txid": "777ed67c58761dcaf3762e64576591c8d39317bcbebf0cb335e138d6ea438ce2",
                "hash": "777ed67c58761dcaf3762e64576591c8d39317bcbebf0cb335e138d6ea438ce2",
                "version": 1,
                "size": 402,
                "vsize": 402,
                "weight": 1608,
                "locktime": 0,
                "vin": [
                    {
                        "txid": "f98b11a5f11d08c3ac31c465092bb5d4c09bd2c815fa23959d654ef9b91414f1",
                        "vout": 0,
                        "scriptSig": {
                            "asm": "3044022068b2a587ec9374325c17c79f9102358fdd0574eeb3bebea08affab3e07afd93c0220248ac15de4e2b6391ff12c348ba6cc024448dba20611a40a35f8b67b6f966cd5[ALL] 046d337916441e20c469623303b47fd0c23326956a183e3274801f1a863e04b7f1dc2bee3388292571955955f8a24445ae35781dd9e39e8472bff623d3375f490e",
                            "hex": "473044022068b2a587ec9374325c17c79f9102358fdd0574eeb3bebea08affab3e07afd93c0220248ac15de4e2b6391ff12c348ba6cc024448dba20611a40a35f8b67b6f966cd50141046d337916441e20c469623303b47fd0c23326956a183e3274801f1a863e04b7f1dc2bee3388292571955955f8a24445ae35781dd9e39e8472bff623d3375f490e"
                        },
                        "sequence": 4294967295
                    },
                    {
                        "txid": "0c4d26699fbd1dd2ecc564ee3f02afd2e5f1837e03044fffa838b1283a2f7cb3",
                        "vout": 0,
                        "scriptSig": {
                            "asm": "304402206ccc7e10f33ed2e73c000780e972c479cf0a74d4a5825d74eebb8ec87d31da3202207a945ff0062c9df5d7a9c51483f0d8fc9d0cad1670319c8fbebde2198f8eea22[ALL] 0450a6524d0f7519571e8fb761ac8285f88c5ad9976454ee2148db5e0d13caa534f6bc56678a328dab8319fd62feabc977e478776c9cf0e705575be61dccdf8383",
                            "hex": "47304402206ccc7e10f33ed2e73c000780e972c479cf0a74d4a5825d74eebb8ec87d31da3202207a945ff0062c9df5d7a9c51483f0d8fc9d0cad1670319c8fbebde2198f8eea2201410450a6524d0f7519571e8fb761ac8285f88c5ad9976454ee2148db5e0d13caa534f6bc56678a328dab8319fd62feabc977e478776c9cf0e705575be61dccdf8383"
                        },
                        "sequence": 4294967295
                    }
                ],
                "vout": [
                    {
                        "value": 20.00000000,
                        "n": 0,
                        "scriptPubKey": {
                            "asm": "OP_DUP OP_HASH160 dda4521a9cd99e92323ae4762467dab928b65f45 OP_EQUALVERIFY OP_CHECKSIG",
                            "hex": "76a914dda4521a9cd99e92323ae4762467dab928b65f4588ac",
                            "reqSigs": 1,
                            "type": "pubkeyhash",
                            "addresses": [
                                "1MCwBbhNGp5hRm5rC1Aims2YFRe2SXPYKt"
                            ]
                        }
                    }
                ],
                "hex": "0100000002f11414b9f94e659d9523fa15c8d29bc0d4b52b0965c431acc3081df1a5118bf9000000008a473044022068b2a587ec9374325c17c79f9102358fdd0574eeb3bebea08affab3e07afd93c0220248ac15de4e2b6391ff12c348ba6cc024448dba20611a40a35f8b67b6f966cd50141046d337916441e20c469623303b47fd0c23326956a183e3274801f1a863e04b7f1dc2bee3388292571955955f8a24445ae35781dd9e39e8472bff623d3375f490effffffffb37c2f3a28b138a8ff4f04037e83f1e5d2af023fee64c5ecd21dbd9f69264d0c000000008a47304402206ccc7e10f33ed2e73c000780e972c479cf0a74d4a5825d74eebb8ec87d31da3202207a945ff0062c9df5d7a9c51483f0d8fc9d0cad1670319c8fbebde2198f8eea2201410450a6524d0f7519571e8fb761ac8285f88c5ad9976454ee2148db5e0d13caa534f6bc56678a328dab8319fd62feabc977e478776c9cf0e705575be61dccdf8383ffffffff0100943577000000001976a914dda4521a9cd99e92323ae4762467dab928b65f4588ac00000000"
            }
        ],
        "time": 1289757588,
        "mediantime": 1289756309,
        "nonce": 1166692788,
        "bits": "1b0e7256",
        "difficulty": 4536.353723275037,
        "chainwork": "00000000000000000000000000000000000000000000000001b349c8e6a815b0",
        "nTx": 2,
        "previousblockhash": "000000000002afe839294d4e038b5c831bc09632fd717c0980f8f216dc2b360f",
        "nextblockhash": "0000000000006626b8604240c5bb5305830e67fcfa8bae10d64cea0e2eb121d4"
    },
    "error": null,
    "id": "183626"
}

and block 91842

{
    "result": {
        "hash": "00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec",
        "confirmations": 545263,
        "strippedsize": 214,
        "size": 214,
        "weight": 856,
        "height": 91842,
        "version": 1,
        "versionHex": "00000001",
        "merkleroot": "d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599",
        "tx": [
            {
                "txid": "d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599",
                "hash": "d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599",
                "version": 1,
                "size": 133,
                "vsize": 133,
                "weight": 532,
                "locktime": 0,
                "vin": [
                    {
                        "coinbase": "0456720e1b00",
                        "sequence": 4294967295
                    }
                ],
                "vout": [
                    {
                        "value": 50.00000000,
                        "n": 0,
                        "scriptPubKey": {
                            "asm": "046896ecfc449cb8560594eb7f413f199deb9b4e5d947a142e7dc7d2de0b811b8e204833ea2a2fd9d4c7b153a8ca7661d0a0b7fc981df1f42f55d64b26b3da1e9c OP_CHECKSIG",
                            "hex": "41046896ecfc449cb8560594eb7f413f199deb9b4e5d947a142e7dc7d2de0b811b8e204833ea2a2fd9d4c7b153a8ca7661d0a0b7fc981df1f42f55d64b26b3da1e9cac",
                            "type": "pubkey"
                        }
                    }
                ],
                "hex": "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff060456720e1b00ffffffff0100f2052a010000004341046896ecfc449cb8560594eb7f413f199deb9b4e5d947a142e7dc7d2de0b811b8e204833ea2a2fd9d4c7b153a8ca7661d0a0b7fc981df1f42f55d64b26b3da1e9cac00000000"
            }
        ],
        "time": 1289768691,
        "mediantime": 1289767893,
        "nonce": 3778549762,
        "bits": "1b0e7256",
        "difficulty": 4536.353723275037,
        "chainwork": "00000000000000000000000000000000000000000000000001b55d6596dd0790",
        "nTx": 1,
        "previousblockhash": "00000000000a1e92acbcbdf594cac25d1095544d5fbf5113bfec85a9eb4b1120",
        "nextblockhash": "0000000000016ca756e810d44aee6be7eabad75d2209d7f4542d1fd53bafc984"
    },
    "error": null,
    "id": "183686"
}

Both have coinbase transactions, which spend to d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599-0. Also, first transaction output is not spent by the time second transaction is added to blockchain.

What does this mean? If d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599-0 is ever one of the inputs, how much bitcoin does it contain? 50 or 100?

signature – How to verify if a transaction is correctly signed?

Given an arbitrary signed raw transaction, how can we easily verify if all inputs are correctly signed (assuming all inputs are existent/unspent and the fee is higher than zero)? Bitcoin core’s RPC command testmempoolaccept will check if all inputs are available to be spent in the mempool/blockchain so it’s impossible to test transactions that have parents not yet broadcasted.

I am aware that for this kind of check, the scriptPubKeys of all inputs needs to be known and therefore only the signed raw transaction by itself is not enough for this kind of check. Still, the scriptPubKeys could be passed to the transaction instance or verify method. I was looking for some nice way to do this in python/javascript but was surprised how difficult this task is:

performance – Is a transaction time of

Appreciate this is a rather odd question, so I will try to clarify as much as possible. Please also be assured this is a question purely for my own education, I’m not about to rush off and do crazy things in our software on the back of it.

I have a customer requirement for a transaction time of <10ms on a system that is based around an SQL database – in our specific implementation it is Oracle DB. I’m aware that this is not a useful or meaningful requirement, so with my business hat on I’ll be dealing with that. I fully expect that the requirement will be revised to something more useful and achievable.

However, I am curious on a technical level. Could you squeeze transaction time on an SQL DB down below 10ms? Lets be generous and say this is pure SQL execution time, no comms, no abstraction layers etc. Right now, running select 1 from dual on one of our systems gives a reported execution time of 10-20ms and I’d assume that’s about the simplest query possible. What if anything might you do to reduce that time (a) within Oracle/SQL or the server environment (b) by making a different tech choice? I’d assume maybe a higher clock speed on the CPU might help, but I wouldn’t bet on it.

signature – Signing transaction offline – manual way vs. Electrum

Being inspired by the thread (Redeeming a raw transaction step by step example required) I wanted to understand transaction signatures on the byte level.
So I created my own Linux scripts that:

  • generate key pairs
  • accumulate all the necessary bytes that a raw transaction needs
  • leverage OpenSSL to sign the transactions

Everything that deals with private keys I do on an offline computer, while I look at the blockchain explorer on the screen of a different, online system.
For my test transaction, I wanted to redeem one utxo of an address that I control on mainnet, and send some satoshis (just above the ‘dust‘ level) to some other addresses using P2PKH. Here is the transaction that I created and signed manually:

{
    "version": 1,
    "locktime": 0,
    "ins": (
            {
                    "n": 1,
                    "script": {
                            "asm": "304402200c441b33dc180ec93e1df07df575399f74112dbf4a0a200151c9c4f1afc7c71e02200fc2fcf42847d5c504f06edef7b8fa81b092e7b8b00169d7f8868a02da6ad12401 02dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2",
                            "hex": "47304402200c441b33dc180ec93e1df07df575399f74112dbf4a0a200151c9c4f1afc7c71e02200fc2fcf42847d5c504f06edef7b8fa81b092e7b8b00169d7f8868a02da6ad124012102dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2"
                    },
                    "sequence": 4294967295,
                    "txid": "127ea67612d6e217f99b2b28cc9f8347eb518f99c45102f925774ad8f4958d0f",
                    "witness": ()
            }
    ),
    "outs": (
            {
                    "script": {
                            "addresses": (
                                    "1HangpEdoDsSe5i3n7DQNbYie65PGGmPcq"
                            ),
                            "asm": "OP_DUP OP_HASH160 b5e5e05c83c470ffd21c3330fb99a6a0101351ad OP_EQUALVERIFY OP_CHECKSIG",
                            "hex": "76a914b5e5e05c83c470ffd21c3330fb99a6a0101351ad88ac"
                    },
                    "value": 800
            },
            {
                    "script": {
                            "addresses": (
                                    "1HaXuSmR7PXhR4GCcyvGC7USYDuDjw6FHw"
                            ),
                            "asm": "OP_DUP OP_HASH160 b5d9896cc07a30e1d739097df0c1d47181cbbe75 OP_EQUALVERIFY OP_CHECKSIG",
                            "hex": "76a914b5d9896cc07a30e1d739097df0c1d47181cbbe7588ac"
                    },
                    "value": 900
            }
    ),
    "hash": "18d7100c870deb63dec258282f5ff150ebc64e4497d107073503fb4343f4810d",
    "txid": "18d7100c870deb63dec258282f5ff150ebc64e4497d107073503fb4343f4810d"
}

… which corresponds to hex representation
01000000010f8d95f4d84a7725f90251c4998f51eb47839fcc282b9bf917e2d61276a67e12010000006a47304402200c441b33dc180ec93e1df07df575399f74112dbf4a0a200151c9c4f1afc7c71e02200fc2fcf42847d5c504f06edef7b8fa81b092e7b8b00169d7f8868a02da6ad124012102dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2ffffffff0220030000000000001976a914b5e5e05c83c470ffd21c3330fb99a6a0101351ad88ac84030000000000001976a914b5d9896cc07a30e1d739097df0c1d47181cbbe7588ac00000000

Electrum has a menu item to ‘load transaction by text‘, what I did with my hex string. It displayed the result correctly as a “transaction unrelated to your wallet” because I had not imported the private key yet. Electrum offered me the option to broadcast the transaction, but I decided not to (*) because I wanted to compare the manually created transaction with the transaction that Electrum would generate when I use their UI features.
(*) I later broadcast my manual transaction via blockchain.com
So, in order to be able to compare, I imported the private key into Electrum and created a transaction with identical parameters (using the ‘Pay to many’ feature). Here is the transaction that Electrum created:

{
    "version": 2,
    "locktime": 636848,
    "ins": (
            {
                    "n": 1,
                    "script": {
                            "asm": "3045022100fa7033d292275ebcd4d8fdf38d6b76461ba4a9330df3b21cf5e72f25f08938c802207268e19442c1d3e0ff9850cd6f500985260c250e18d71976093475bd61180ebb01 02dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2",
                            "hex": "483045022100fa7033d292275ebcd4d8fdf38d6b76461ba4a9330df3b21cf5e72f25f08938c802207268e19442c1d3e0ff9850cd6f500985260c250e18d71976093475bd61180ebb012102dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2"
                    },
                    "sequence": 4294967294,
                    "txid": "127ea67612d6e217f99b2b28cc9f8347eb518f99c45102f925774ad8f4958d0f",
                    "witness": ()
            }
    ),
    "outs": (
            {
                    "script": {
                            "addresses": (
                                    "1HangpEdoDsSe5i3n7DQNbYie65PGGmPcq"
                            ),
                            "asm": "OP_DUP OP_HASH160 b5e5e05c83c470ffd21c3330fb99a6a0101351ad OP_EQUALVERIFY OP_CHECKSIG",
                            "hex": "76a914b5e5e05c83c470ffd21c3330fb99a6a0101351ad88ac"
                    },
                    "value": 800
            },
            {
                    "script": {
                            "addresses": (
                                    "1HaXuSmR7PXhR4GCcyvGC7USYDuDjw6FHw"
                            ),
                            "asm": "OP_DUP OP_HASH160 b5d9896cc07a30e1d739097df0c1d47181cbbe75 OP_EQUALVERIFY OP_CHECKSIG",
                            "hex": "76a914b5d9896cc07a30e1d739097df0c1d47181cbbe7588ac"
                    },
                    "value": 900
            }
    ),
    "hash": "0f33ae7fc5ca788351a4b571083cf0fa8cbb37afe0206260b02c4c889c05c099",
    "txid": "0f33ae7fc5ca788351a4b571083cf0fa8cbb37afe0206260b02c4c889c05c099"
}

… which corresponds to hex representation 02000000010f8d95f4d84a7725f90251c4998f51eb47839fcc282b9bf917e2d61276a67e12010000006a47304402200dd93baf0a38e4a352a7029c2a37a9bb8ef06bc32ab33fabb8278c6733193e4a02203393c4f5b73345a2a76694de9dff429d65b4de77581601ccc748c642a0dac308012102dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2feffffff0220030000000000001976a914b5e5e05c83c470ffd21c3330fb99a6a0101351ad88ac84030000000000001976a914b5d9896cc07a30e1d739097df0c1d47181cbbe7588ace5b70900

And here comes my question:
When I compare the 2 decoded transactions, I get the following differences:

~/$ diff tx-manual tx-electrum 
2,3c2,3
<   "version": 1,
<   "locktime": 0,
---
>   "version": 2,
>   "locktime": 636848,
8,9c8,9
<               "asm": "304402200c441b33dc180ec93e1df07df575399f74112dbf4a0a200151c9c4f1afc7c71e02200fc2fcf42847d5c504f06edef7b8fa81b092e7b8b00169d7f8868a02da6ad12401 02dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2",
<               "hex": "47304402200c441b33dc180ec93e1df07df575399f74112dbf4a0a200151c9c4f1afc7c71e02200fc2fcf42847d5c504f06edef7b8fa81b092e7b8b00169d7f8868a02da6ad124012102dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2"
---
>               "asm": "3045022100fa7033d292275ebcd4d8fdf38d6b76461ba4a9330df3b21cf5e72f25f08938c802207268e19442c1d3e0ff9850cd6f500985260c250e18d71976093475bd61180ebb01 02dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2",
>               "hex": "483045022100fa7033d292275ebcd4d8fdf38d6b76461ba4a9330df3b21cf5e72f25f08938c802207268e19442c1d3e0ff9850cd6f500985260c250e18d71976093475bd61180ebb012102dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2"
11c11
<           "sequence": 4294967295,
---
>           "sequence": 4294967294,
38,39c38,39
<   "hash": "18d7100c870deb63dec258282f5ff150ebc64e4497d107073503fb4343f4810d",
<   "txid": "18d7100c870deb63dec258282f5ff150ebc64e4497d107073503fb4343f4810d"
---
>   "hash": "0f33ae7fc5ca788351a4b571083cf0fa8cbb37afe0206260b02c4c889c05c099",
>   "txid": "0f33ae7fc5ca788351a4b571083cf0fa8cbb37afe0206260b02c4c889c05c099"

Who can explain me the differences (or point me to the appropriate BIP) and why does Electrum use them? I’m aware of the fact that the signatures are not deterministic and must consequently differ, and thus the hash/txid must differ as well. But what about version, locktime and the significance of the e5b70900 suffix after the last scriptpubkey (see hex representation of the Electrum tx)?

utxo – How can I create a transaction that spends an anyonecanspend output using btc-lib?

I managed to create an UTXO that only contains “OP_TRUE” as script:

{
"value": 0.00000546,
"n": 1,
"scriptPubKey": {
    "asm": "1",
    "hex": "51",
    "type": "nonstandard",
    "isTruncated": false
}

I have the txid and the vout number. Now I would like to create a tx that spends this utxo but I can’t manage to do it using btc-lib.

this is what I tried:

    var utxodata = {}
    utxodata.txid = mytxid
    utxodata.vout = 1
    utxodata.script= "0x51"
    utxodata.satoshis = 546
    var tx = new btc.Transaction().from(utxodata)
    tx = tx.to(myaddress, 546)
    tx = tx.sign(myprivateKey)

Can you provide some help please?

coin selection – Is there a way to determine the optimal size of a batched transaction to save on fees?

I’ve been looking at other questions about fees and batching, but it seems no one asked if there is some way to determine the optimal size of a transaction to save on fees (assuming all inputs are spending from segwit native UTXOs for simplicity).

To expand a bit on what I have in mind: I need to pay various amounts to different people (let’s consider their number can be anywhere between 1 and infinite), and I guess that by making one “big” transaction paying them all at once instead of 1 transaction for each of them I can save on fees. But is it the more people I can add up in the same transaction the better, or would I save less at some point if my transaction keeps getting bigger? Is there some model to calculate the “optimal” size for my batched transaction, or maybe it doesn’t make sense?

Here’s my best guess for now: adding more people means really adding outputs, which makes the transaction grow linearily (assuming all ouputs are pretty standard and roughly of the same size), so assuming the fees are split between each receivers the more people you can onboard on the same transaction the cheaper it gets for everyone.

But at some point the sum of the amounts of the ouputs will grow bigger than the one input I added at first and I’ll need to add another input. If I have relatively big ouputs to spend this is probably ok, but if I only have small outputs and/or I’m adding relatively big amounts in the outputs at some point adding one more output could need to add one or maybe more inputs, making the growth in size transaction not worthing the save in fees, so I’d rather just stop it and send the batch at this point.

(EDIT) I came across this article that seems to confirm what I was thinking, and that all things being equal it will always save fees to add a new output.