unconfirmed transactions limit?
Okay, just wondered if anyone knows the answer to the following offhand before I start digging through Burst source code...
So, I'm running a node in a VM for testing a new Burst website idea. Just now, repeated calls to the API's getUnconfirmedTransactionIds command resulted in returns of an empty array. Must be a slow time of the day, I thought. But the Block Explorer showed full blocks. Turns out, BurstNation was/is making it rain. I restarted my node and called getUnconfirmedTransactionIds again. This time it behaved as expected, with 6215 unconfirmed transactions waiting in memory.
What in the above scenario would cause the API to return an empty array for unconfirmed transactions? Was it stuck verifying them and happened to finish between my restart? Does it reach a limit on unconfirmed and just empty the pool? Anyone know?
@FlippyCakes Thats a strange behavior, can not explain it after looking into the code ... possible reason would be that your peer just didn't not know/have the unconfirmed transactions at the time of the request ... and received them on reconnecting to other peers?!
Tried to find a exception or timeout handling, that returns a empty list, if takes too long but that would cause a error response as far as i could see. Also i did not find any max unconfirmed handling.
Beside that, i fund something i didn't know until now ... maybe interesting for others who wonder about it ... a block can only contain the max. of 255 transactions if not the max. block payload is reached before ... payload is 176*255 = 44880 byte. So on spam attacks, it depends on message length, how much transactions are included in one block.
@luxe Thanks for taking a look. Your guess that my connected peers just didn't get/pass along the transactions sounds most likely, I agree. I noticed during the "rain" that one or more empty blocks were mined, so I wonder if something similar happened to other nodes.
I also noticed that blocks were full with fewer than 255 transactions. Interesting to know why!
@FlippyCakes due to message attached to the spam it fills up those 44KB per block way faster ;)
@luxe Okay, seems this was definitely a peer (or maybe bandwidth/firewall?) issue. I just now experienced the same thing - API responded with an empty array. During that period my wallet was also behind about 8 blocks. Then all of a sudden I jumped from 3 active peers to 7 and everything caught up and the API began responding with unconfirmed transactions as expcted. I'll just assume that once in a proper data center with established peers things will be smoother.