Election-halving

I have always thought that having a 'send' and 'receive' block per transaction is a stroke of genius in the block lattice structure but the fact that the network requires voting for both seems to be a bit of an overkill.

My proposal is to halve the number of elections by combining the two voting procedures into one combined election when the corresponding 'receive' block is published. How would it work? A published and valid send block would be stored in a in-memory cache ('mempool') until the corresponding and valid 'receive' block is published to network. Both blocks would only be written to the ledger when the combined election is successful. 'Send' block would be subsequently cleared from the cache. An automatic purging process would make sure that a pair-less 'send' block would not stay in the cache for too long - which means that non-received transactions would be reimbursed to the sending account.

Ok, now it's time to shoot me. Let me know if this is incredibly stupid or something to consider.

From a UX perspective, this would basically kill asynchronous transfers. I couldn't send you money today for you to accept in 3 weeks when you happen to (boot your computer/do whatever where your app/wallet is) since memory in the sendcache wouldn't persist forever.

From a security perspective, the sendcache would likely be DoS'able by an attacker that just creates an enormous amount of unreceived sends. It may also be prone to desyncing -- some nodes would see that a user has 10 Nano, other nodes (that came up later or have smaller sendcaches) would see that they have 5 Nano + 5 pending to send to somebody.

If you didn't care about the asynchronous problem and wanted to lean heavily into it, it's possible to venture down a rabbit hole that could ultimately lead to a single transaction for both send+recv together that gets voted on. However, you'd be making so many changes and needing to address so many novel cans of worms that it'd be, IMO, so divergent from the core of Nano's current design and philosophy that you'd be effectively creating a new coin.

1 Like
  • It's nothing to do with asynchronicity: Nano's asynchronous nature would stay the same. Yes, you wouldn't be able to send to a long time offline address (wallet/node). In reality it's probably only problematic for paper wallets.
  • All blocks would be propagated and validated the very same way like today, the only difference is that send blocks wouldn't be written to ledger immediately. In other words, all nodes could compute the balance of sending address.
  • It's no different from security perspective from the current state, you can create an enormous amount of send blocks today, too - the current anti-spam solutions would remain the same. Yes, you would need a sizeable RAM, but given the block-size, it's not an issue.
  • Different coin? Perhaps. But not so much.

Erm, no. In your very initial post you write

which basically synchronizes send and receive blocks.

This is not how I read your proposal.
I understand that send blocks aren't being voted on immediately and put in a mempool instead to be voted on together with receive blocks.
No voting on which send blocks are being put in the data base (in case there are conflicting ones) means they aren't as reliable as send blocks today are.
What happens once the mempool is full?

I understand the people that want receive blocks to happen automatically or without a signature (who would issue them? the sender? how would it not fork someone else's wallet?)
But breaking the irreversible nature of send blocks and requiring people to be online to receive is just a downgrade. Next thing you know we are using "watchtowers" and "channels" for a block structure that does not require those LN second layer jerry-rigged atrocities!

It is worth noting that a send-receive pair of blocks was suggested in this thread. It wouldn't be a replacement of the current process of voting on send blocks immediately, and subsequently voting on receive blocks, but instead provide it as an option to allow a single election process if the pairing was used. An incentive to use the pairing option instead of the asynchronous option would likely be needed, to justify the additional coordination for making this happen in many cases. But it may be worth considering.

2 Likes

Thanks, Zach. I didn't notice this proposal.

Not sure if you saw this related thread, but Colin has also expressed interest in auto-receives of some sort, if it can be done safely:

Also, from Discord recently:

1 Like

I thought requiring a separate signature for receive was a feature. Why does the NF wanna do it, if the only advantage is tps, as there is no theoretical limit to the tps in the network?

It would give more TPS 'bang' per dollar of hardware. TPS scales with hardware.

Not sure if you are trolling

one way one might stop injection could be that a recieve block wouldnt immediately auto confirm but for example on a timeout giving the user enough ways to say "nope, I take prio here"