By default, don't allow sends unless previous is confirmed?

Copy/pasted from GitHub for more discussion:

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

Copy/pasting bbedward's rebuttal:

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.

Copy/pasting my response:

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


Doesnt look like a good idea. It is just shifting the waiting queue from nodes to the user which imo is a bad UX.

This suggestion also does not fix anything with the current spam since the spammer mostly sends once from an account and forgets about it. So what problem is this suggestion trying to solve?

If the global default behavior is to only send after your previous transaction is confirmed, it can help save the network from spiraling out of control in a mass congestion scenario. Otherwise the backlog keeps growing, nodes go out of sync more easily, more duplicate vote/block traffic occurs, more (and more complex) forks occur, more disk space is used, more i/o happens, etc. It also helps prevent users from sending unconfirmed transactions all over the place, which they might accidentally fork/reverse

It's similar to stopping (or at least reducing) traffic jams before they happen and get out of control


disclaimer: I'm a regular user that does not understand completely how all of this works.

Wallets could check this automatically and inform users if there are unconfirmed blocks and give the user the choice to still make the transaction or not.

@CalicoCat yes it just moves the waiting from node to user, but users will not worry anymore where are their funds. The regular user doesn't really understand the mechanism behind and not knowing where your funds are is also bad UX.

Natrium developers tried something with their latest update but it could have been done better I think. It should check for unconfirmed blocks for each wallet and clearly state in the UI, with RED preferably: "This address has unconfirmed blocks related to it. We recommend you to not make any transaction until this problem is solved" and when they check and all the blocks have been confirmed a message in GREEN: "All your transactions are completed. You can again enjoy the beauty behind the nano protocol"

I know everybody involved is overwhelmed with messages from all of us but there is a saying: "help me help you!" :slight_smile:


I agree with this idea. I would remove the "force" option though. Allow for a per account backlog limit. Thus, anything submitted beyond this limit is simply rejected until queue subsides. This limit may only impact exchanges and services that rely on single account to high volume usage.

1 Like

What if my last receiver is offline at the moment and I'd like to send another transaction to someone else?
As I understand the receiver must be online in order to sign the block.

The only thing might be helpful is to prevent the receiver from sending unconfirmed nano futher to prevent the ledger bloat.

The receiver doesn't have to be online for a send transaction to be confirmed. A pending transaction isn't the same thing as an unconfirmed transaction. You can have confirmed or unconfirmed pending transactions:

When you send a transaction, the network confirms that send (making it a pending transaction), then (under the proposed change) you'd be able to make your next send (or you could "force" it to send the next transaction even if your send isn't confirmed yet). The transaction still sits as pending until the receiver publishes a receive