Idea: Batch recieve Block

since one of the ideas people try to use or get people to use Nano is Micropayments (or maybe eben nano-payments, lol), with one implementation idea in particular easily allowing like 20 payments in a minute by a single user alone, and the fact that each transaction exists twice, once as send and once as recieve, this can add up quickly.

so I would like to bring the idea of a batch recieve block, which basically does not just have one source element but an array of sources.

to keep pruned nodes happy and the size of the frontier small an additional "normal" recieve block with the batch block as the source (or something other to just have a normal sized block as frontier) could be sent right along.

the advantages are pretty high in my opinion.

Lower the need for revieve blocks by batching an arbitrary number of transactions into 2 resulting in at least 33% less blocks (for combining 3 transactions)

In result the amount of votes can be equally reduced creating less strain on the total network

lower the amount of total space used by recieving by only needing one set of block metadata.

make nano even better for the environment as only PoW is needed twice instead of potentially hundreds of times.

Thanks for sharing the idea. This has been discussed before and there is actually some potential in the upcoming state block design to allow exploring support for this type of option in the future.

One approach could be agreeing on a format for bundling up receive hashes to attach to a block as an extension and then generating a hash of that package which would be included in the link field on the block. The block can then be marked as a multi-receive block and as long as the balance is correct and the linked package is valid, the node could drop all those pending entries on confirmations.

Store of the received hashes would still need to be done in the database in a way that minimizes storage and doesn't hinder hash searches, but those are likely solvable problems.

A tricky part of the implementation is how to handle cases where someone packs in many hashes that are valid receive blocks, but includes one that is unknown. The amount of node resource to validate the existence of the blocks and reconcile the hash it doesn't having a pending entry for could open up new DoS vectors if not carefully designed.

that also sounds pretty good. didnt know extensions are a thing.

oh. totally true. that would be bad.

They aren't currently a part of the protocol iirc, but limited use of them has been discussed before in a more standardized way, such as here: Proposal for State Blocks v7 · Issue #1100 · nanocurrency/nano-node · GitHub, but there are lots of considerations as noted in the comments.