Stream Smart Filter: Is the file still kept in storage if invalid?

Question

A stream filter is only applied by nodes subscribed to a stream, and so is more efficient, but cannot prevent malicious nodes from publishing invalid data (which will subsequently be ignored by stream subscribers). Note also that transaction filters cannot perform validation of off-chain data, since that data does not appear inside the transaction itself, whereas stream filters can validate both on-chain or off-chain data.

 

Am I right to assume that "ignored by stream subscribers" means that files deemed invalid by stream rules would be deleted upon arrival by the nodes? 

Answer 1

No, the files are kept on disk by the node – they are just not reported as regular items in the stream listing APIs. For on-chain data there is not much choice about this because the files are part of the blockchain itself. For off-chain data we could consider improving this behavior in future – it's an interesting idea.

Is this a significant concern in your particular application and if so can you explain why you believe users will be motivated to publish data to the chain that is not valid according to a stream filter? They would need to modify MultiChain's codebase and recompile it in order to do this.

Comments

Thank you for the reply, you always provide interesting and thoughtful comments! It puzzles my mind as to how Multichain doesn't have more attraction inside the Crypto Community. As far as I can tell, it's the best platform available today.

> why you believe users will be motivated to publish data to the chain that is not valid according to a stream filter?

Anyone can write to the stream and its purpose is to keep track of a few important things, so it would be an easy obfuscation and bloat attack to fill the blockchain with non-conformity items. However, I didn't know that in order to bypass local filters (being: filters for stream of off-chain data), you would need to recompile Multichain. I honestly was more worried of user-error than an attack, and that pretty much solves it!

About my suggestion, I think it makes sense: if an item is deemed invalid to be transmitted/streamed, the node shouldn't waste time storing it.