Bitcoin scalability - unite transactions transaction.

[ivantosov]

On my bitcoin address 1000 input transactions, 0.001 btc each, - 1 btc summary. The new out transaction lists them all, and it's size is 100 kilobytes. I have 10 of such addresses, and to send 10 btc on new address, I need to generate 1Mb transaction! So I have a very biiig fee ... 2 btc, or 25% (((
But bitcoin address size is 33 bytes! So why doesn't bitcoin provide special unite transactions, listing only 10 inputs addresses, without listing 10000 transactions? It would reduce transaction size tremendously, would allow to optimize states with very low, almost fixed fees, and would solve the problem of transactions with amount of coins less than current fee.

[1715135189]

1715135189

[1715135189]

1715135189

[ranochigo]

The blockchain isn't a balance system. It keeps track of the transactions, not the balance. Nodes do not have to see the entire balance of the address to validate the transaction.

Bitcoin transaction works by using unspent outputs of addresses. Each nodes keeps a list of such outputs. When a transaction is spent, the transaction states the transaction unspent outputs that are used in it. Next, the node removes the outputs from their list and no one else can send another transaction sending it and have that node relaying it.

It's way easier to track the unspent output than to index each and every address for their balance.

[ivantosov]

It does not require balance calculation for address/all addresses. It just requires finding all transactions of the address(es), listed in such transaction in specified block number. And I guess it should not be difficult to implement.?

[achow101]

It does not require balance calculation for address/all addresses. It just requires finding all transactions of the address(es), listed in such transaction in specified block number.

... You are contradicting yourself. Balance calculation means "finding all transaction of the addresses". So for your idea to work, you would need to calculate the balance for a given address.

And I guess it should not be difficult to implement.?

That is incorrect. It would be both difficulty to implement, and completely unsafe. Making it safe would make this even harder to implement.

First of all, on the technical level, addresses don't exist. What exist are transaction outputs, and transaction outputs themselves don't have addresses, they have output scripts. An address only encodes what a wallet should use as an output script, but there are infinitely many output scripts that are not related to any address whatsoever.

Furthermore your idea is completely unsafe. What you propose is to use accounts and balances, but such systems are known to be unsafe in the context of a cryptocurrency. For example, suppose you want to pay me and you do so by constructing one of these special transactions. Now later, you receive money to the same addresses, and once the balances are high enough, I broadcast the special transaction again and send your money to myself.

[ivantosov]

... For example, suppose you want to pay me and you do so by constructing one of these special transactions. Now later, you receive money to the same addresses, and once the balances are high enough, I broadcast the special transaction again and send your money to myself.

Union transaction must contains the block number that must be used to determine all address transactions.
- if later I receive money, this new transaction will have a larger block number, and must not be used in the union transaction.
- if I spend money later (related to union transaction), there will be a "double spend" transaction. This situation is common for transactions. Only one transaction will be selected, so this is not a problem.

First of all, on the technical level, addresses don't exist. What exist are transaction outputs, and transaction outputs themselves don't have addresses, they have output scripts. ...

I mean a special transaction, a separate type. As message transaction, for example.

Balance calculation means "finding all transaction of the addresses". So for your idea to work, you would need to calculate the balance for a given address.

All transactions contain address. So it's need only + one index for array search.
Conventional transactions contain a list of input transaction numbers. They also have to be searched. For each transaction there will be a separate search. There are always more transactions than addresses. Search by address should be faster.

In current situation, the network has lost a lot of coins in small transactions (~< 0,002 BTC), since the commission for their transfer (0.00913 BTC/KB) is larger than the number of coins in this transactions. This is a big problem. The network needs a unite transaction.

[ranochigo]

Union transaction must contains the block number that must be used to determine all address transactions.
- if later I receive money, this new transaction will have a larger block number, and must not be used in the union transaction.
- if I spend money later (related to union transaction), there will be a "double spend" transaction. This situation is common for transactions. Only one transaction will be selected, so this is not a problem.

It's confusing. The current blockchain system works by only allowing each inputs to only be spent once. How is your implementation going to help?

I mean a special transaction, a separate type. As message transaction, for example.

There isn't a message transaction. Unless you are referring to OP_Return which contributes to Blockchain bloat.

All transactions contain address. So it's need only + one index for array search.

Conventional transactions contain a list of input transaction numbers. They also have to be searched. For each transaction there will be a separate search. There are always more transactions than addresses. Search by address should be faster.

Basically, for the "conventional" transaction, to validate a transaction, nodes basically have to see which UTXO is being spent and search it in their UTXO database which is relatively small. If we were to switch to a balance method, for each address, the node will have to search and validate each of the transactions and then calculate the total balance. Obviously, some attacker would spam invalid transactions for the node to waste resources to DDOS any nodes.