In a MAM stream, every message holds a reference to the next one. To follow the stream when there is a snapshot you must always keep the ref to the next message.
Currently, to read the beginning of the stream after a snapshot you have to connect to a permanode.
(Source : https://youtu.be/_ZO2ysgzKkM at 1h23)
As of now (November 2017) there is no "finished" software available that can just be installed and run as a permanode.
People who currently need a permanode (I think some block explorers have that) will have to collect databases from the latest milestones before each Snapshot (I think links some of them are shared on the Slack) and manually import them into ...
A full node contains the full data (that is, all transactions) generated after a snapshot.
The benefit is that nodes can have reduced hardware specs.
The drawback is that information that resides in transactions is lost after every snapshot, if the transaction is behind (older than) the snapshot, and has no balance on it.
A permanode contains all ...
Nodes can choose to take a local snapshot at any time, which would delete old transactions from their ledgers.
Therefore, to be sure that your zero value transactions are not deleted, you would need to run your own node that does not take local snapshots.
See the developer documentation for information on running a node.
Iota uses POW to protect the tangle against abusive spamming. Spamming the network consume CPU/GPU power because you need to find the appropriate nonce for the spam transaction.
Already today, it doesn't make economic sense to spam the tangle. Unfortunately, it is not enough to prevent abusive spamming completely.
Spam can't be avoided, and despite the ...
There are two ways I can think of to verify a (the orange) transaction.
1. With the Coordinator
If you don't know how IOTA transactions are confirmed by the coordinator, check out
How exactly are transactions verified and confirmed in IOTA
You get all information about the old Tangle through thetangle.org (or any other provider) ...
The issue is that a larger history will result in nodes being in need of more hard drive space and finally result in degraded performance as a larger database is slower than a smaller one.
There are a lot of smaller nodes running on VPS out there, which could not store the entire history. The database since the last snapshot is already almost 11 GB in size ...
Regarding incentive for running permanodes, from this meetup, permanodes will be incentivised by pay per query. The issue of whether permanodes can be trusted can be resolved by drawing a parallel with DPoS - in DPoS decentralisation is partly sacrificed to achieve scalability, similarly full nodes represent federated history maintenance for the sake of more ...