Nano-node: By default, don't allow sends unless previous is confirmed?

[qwahzi]

Per the recent spam, it seems like one issue that causes compounding problems is nodes that send long chains of unconfirmed transactions that need to get resolved, but some of those transactions get lost in the backlog, or end up as forks that need (and struggle) to get resolved

Would it make sense to change the default node behavior to only send if "previous" is locally confirmed, unless overridden by a "force" option? That might help shrink backlogs, allow for easier fork resolution, and prevent potential work re-work

[Gyakusetsu]

And also from Algorand: https://www.algorand.com/resources/blog/algorands-core-technology-in-a-nutshell/

Algorand’s Non-Forkable Chain.
An additional advantage of Algorand’s technology is that its chain never forks. This is so because only one block can have the required threshold of committee votes. Accordingly, in Algorand all transactions are final. Once a block appears, you can count on it to be forever part of the chain. And if the new block contains a payment made to you, you may consider yourself paid and send the goods immediately.

And obviously it will prevent election backlogs in case of double-spend spam.

[bbedward]

I disagree with this idea, queuing transactions is something that should be handled by the node/protocol (as it currently is). It would be atypical to have this queuing be implemented at the application level and would complicate Nano integrations. With traditional blockchains you queue as many transactions as you want in the mempool.

[qwahzi]

I disagree with this idea, queuing transactions is something that should be handled by the node/protocol (as it currently is). It would be atypical to have this queuing be implemented at the application level and would complicate Nano integrations. With traditional blockchains you queue as many transactions as you want in the mempool.

This wouldn't remove queuing from the protocol - it would only change the default node behavior to local queuing _if_ "previous" is unconfirmed (to slow down the publishing of extended unconfirmed transaction chains, unless forced)

What's the benefit to publishing transactions if the required "previous" is unconfirmed and may get rolled back? Seems like you'd have to wait the same amount of time in either case, except default local queuing reduces potential forks (more costly for the network to resolve) and the compounding effect of a network backlog/slowdown. If "previous" is locally confirmed, then nothing changes anyways

[Gyakusetsu]

Hi @qwahzi can you propose and share this in nano forum, protocol design?

[qwahzi]

Hi @qwahzi can you propose and share this in nano forum, protocol design?

Done!

https://forum.nano.org/t/by-default-dont-allow-sends-unless-previous-is-confirmed/1888

[qwahzi]

Related to this - the default behavior for auto-receives should be not to happen for unconfirmed sends, no?