Proposal: Make send and receive blocks have several inputs/outputs

Protocol Design
#1

Hey!

I'm glad Nano finally has its own dedicated forum!

I'll start my contribution to this forum by coming with a protocol proposal and hear what you guys have to say about it.

My proposal is the following: Send and receive blocks should support multiple inputs/outputs.

With this I mean, for example, that one send block can contain a list of receivers and the corresponding amounts. So if I want to send 1 Nano to address A and 2 Nano to address B, the send block's account field will now be a list of A and B, and there can be a new field field called amounts for example which is a list of how much you want to send each address. So, in this case,

"account": [A, B],
"amounts": ['1', '2'] (should really be ['10^30', '2*10^30'] since you are sending raw)

Then one simply checks that the the balance of this block minus the balance of the previous block equals the sum of the amounts list.

Similarly, one could make receive blocks which receives multiple send blocks. Example: Your address has received two unpocketed transactions, so instead of making two receive blocks, you make one. This receive block will then have a list of links which are the hashes of the two send blocks. Then the new balance is simply the the sum of the previous block balance and the two send blocks you want to pocket.

This proposal will make it easier for exchanges and services since it requires less work to send and receive Nano. It would also be less information stored on the ledger since two or more blocks can be compressed into one (this block would of course be bigger than a normal block, but still smaller than multiple blocks).

So what do you guys think? Is there a reason why this can not be achieved. It would of course require some kind of fork which can be done through epoch blocks. Let me know what you think.

Edit: Spelling

4 Likes
#2

Good idea. As far as I know, blocks in Nano are designed so they fit in a single TCP packet, which mean they should be small enough. This doesn’t necessarily mean your proposal can’t be achieved, but simply that it would broke that constant.

On the other hand, multiple transactions with different receivers must be individually validated, which makes it harder to operate a node. Maybe this change could improve network health and speed.

One last thing that I see with your proposal is that it can be used to excessively spam the network by creating multiple accounts with a small amounts that can’t be pruned. A mitigation for this could be that the amount of PoW required to send a transaction with multiple recipients should be equal to the amount of PoW required to send that many individual transactions.

1 Like
#3

This would effectively be a transition to a UTXO system. One of the advantages in my opinion is that it makes it easier to build protocols like CoinJoin on the network. However, Nano's current consensus is somewhat incompatible with a transaction spending multiple inputs, as that could create more complex transaction conflicts. At the very least, it'd be a huge code change.

4 Likes