Currently, Firo’s max transaction limit size is 100 kB though some people are hitting this limit especially when dealing with many masternode or mining payouts. The error that pops up is 'Transaction is too large". The limit is there to prevent DDoS and ensure transactions can propagate properly. We’re also pushing a different text to be more informative rather than Transaction is too Large. Thanks to @Zed for bringing it up.
Core team is thinking about increasing this limit to at least 250 kB. This would be a hard fork so wanted to solicit opinions on this change.
In a perfect world - when you use a crypto wallet you shouldn’t need to know anything about the technology being used to send/receive your coins.
But in reality, there are limitations in the technology being used - and - as Reuben has pointed out - there are risks (potential DDoS attacks if transaction sizes are unlimited).
The issue some people are currently having is if they collect a lot of mining or Master Node rewards and then try to send too many of these as part of a transaction they get an error message saying the ‘transaction is too large’ (meaning the size of the transaction exceeds 100KB when all of the unspent inputs are placed into the transaction block). This has been an issue for many people for quite a while - and we see people complaining in the support channel from time-to-time. Many of us who do Firo mining or runs Firo Master nodes have found (inelegant) ways around the issue by consolidating small valued inputs into larger ones by sending Firo to yourself. This is not a user friendly process, slows down making transactions, and is just a pain in the butt. Increasing the tx size will certainly help - but under ‘normal conditions’ even 250KB will only solve the issues for some people. If someone has been collecting Master node payments (3.125 Firo and likely half of that after the halving) and they were to anonymize them as they came in, they would have 320 inputs when they were ready to create a new Master node - which would be about twice as many inputs as would fit into a 250KB transaction. This would be much worse for mining rewards (many people set their mining reward payments on the pools to 1.0 Firo - or some (who are overly eager to get payments) may even set it to 0.1 Firo - making the situation even worse when they try to use the rewards). So - ‘normal use’ would still not function without knowing they need to do something special to be able to consolidate inputs.
Changing the message to be more informative will certainly help usability. I have also suggested to look at taking things one step farther and maybe there should be a built-in aggregation tool made available when the message comes up - to consolidate inputs of a certain size into larger and fewer inputs. Not sure if that would be doable or not - just a suggestion.
In summary:
increasing the transaction size is likely a very good idea - as to the optimal safe size we likely need to leave this to the core team to figure out.
improving the message when the maximum transaction size is reached is certainly a good idea.
looking at the possibility of an aggregation/consolidation tool may be a good idea - if it’s doable and not too difficult/expensive.
for now - in the mean time - people who run into these issues need to send Firo to themselves whenever they have accumulated about 50 to 60 small valued transactions before they try sending Firo in large amounts (like creating a Master Node collateral amount). Personally I have gotten into the habit of consolidating rewards whenever I get about 50 of them (which can take quite a while).
As a master node hoster for several years now, I know this pain all too much. A better message IMO should happen regardless of anything else and asap. But as long as there is no downside to having a larger limit, I vote for that too.
yes, the limit is very anoying. good thing is, only exerienced users with many masternodes have to deal with it, the normal user will not run into this.
I can`t estimate the DDos risk, but would love to see the limit increase to 1MB
