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

EDIT:

"A better solution to #3166 (don't send unless previous has been confirmed) has already been implemented here https://github.com/nanocurrency/nano-node/pull/4454 afaik. Instead of limiting legit services to wait for the previous confirmation, all the PRs in the network wait for the previous confirmation before publishing the block. So we have the best of both worlds. Reduced traffic and no artificial limits for legit services that want to publish all their blocks at once."

[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?

[SparK-Cruz]

+1 for this to be added:

• Not broadcasting blocks which prev is not confirmed
• Not broadcasting blocks which link is a block and is not confirmed (receives with unconfirmed sends)

Client handling their own block queue makes a lot of sense to me.

(I'd go as far as suggesting dropping those block all together but not broadcasting until they are ready is enough)

[darwin-brandao]

Agreed.

[SparK-Cruz]

@gr0vity-dev, you mentioned #4454 as a better solution for this on 4476, which I agree. But you also mentioned something about reps having a different behavior. Or did I read it wrong again?

[gr0vity-dev]

If I understand this proposal correctly, it wants to limit the sender to only publish blocks with a confirmed predecessor in order to reduce reduce traffic ? This alone doesn't really help mitigate spam. An attacker could either use their own scripts to publish all the blocks or use the "force" flag.

4454 addresses this in a more complete manner without limiting legit services.

You can still publish whatever blocks you want. However the representatives only gossip the checked blocks when the predecessor is confirmed. Representatives take care of the traffic, users are not limited in any way.