Legacy

The biggest problem of any decentralized payment processing system, also known as cryptocurrency, is the problem of double spending: when someone sends two payments from the same origin to two different destinations, delivering the data to two different servers. When the information will have to be synchronized at some point, there will be a conflict, which will have to be resolved, and consensus will have to be found. Zold is no different, however…

In Zold we have the same problem, and we solve it by the merge operation, which takes into account the cumulative score of both transactions, which are in conflict. The one that is coming from a more trustable source—wins. The one that is coming from a less trustable one—gets deleted from the wallet.

However, since Zold has a different and much more light-weight architecture than Blockchain, it is also much more vulnerable to the 51% attack. An attacker can accumulate a large score on an isolated machine by running the calculator for a few weeks or months and pointing the score date into the future (more about it here). Then, when the right moment in the future occurs, the attacker sends a new transaction to the network, overwriting the one, which was previously made the the same person. But the new one will send the money to a different destination.

All nodes will accept this new transaction as a more authoritative one and will delete the previously accepted one, which would obviously be a mistake.

To prevent this from happening we introduced a new feature into the merge operation, which is protecting transactions, which are too old, from any modifications. Simply put, if the payment is older than 24 hours, it becomes immutable and no node will be allowing anyone to touch it.

You can turn this feature off by --skip-legacy command line argument of the merge operation. However, it is not recommended to do so, of course.