@lKuzon It is true that IOTA nodes can be configured to prune old data that is no longer needed but this doesn't make the system less secure.
In fact Bitcoin has exactly the same option which is called "pruning mode" and which was introduced as part of Bitcoin Core 0.11 in 2014.
In fact Bitcoin has exactly the same option which is called "pruning mode" and which was introduced as part of Bitcoin Core 0.11 in 2014.
@lKuzon The reason why Bitcoin, Ethereum, IOTA and pretty much any major cryptocurrency that exists has such a feature in their node software, is due to the fact that it does not impact the security and nodes do not even access this old data anymore as part of their consensus mechanism.
@lKuzon It is true that IOTA will produce more data than a Bitcoin node so there will most probably be more people having this pruning mode enabled and less people that will maintain a full history of everything that ever happened.
Roman argues that this will make it harder to find ...
Roman argues that this will make it harder to find ...
@lKuzon ... bugs.
He says that if you would ever have something like an inflation bug then in Bitcoin you could check where and when it happened while in IOTA you might have lost the ability to track the origin of potentially malicious funds.
This is of course not entirely wrong ...
He says that if you would ever have something like an inflation bug then in Bitcoin you could check where and when it happened while in IOTA you might have lost the ability to track the origin of potentially malicious funds.
This is of course not entirely wrong ...
@lKuzon ... but even IOTA nodes will store the recent history of at least a few weeks or even months.
I don't think that finding a bug years later is of any use - nobody would agree to roll back the Bitcoin network to a state of i.e. 2018 if you would discover a bug in that time period.
I don't think that finding a bug years later is of any use - nobody would agree to roll back the Bitcoin network to a state of i.e. 2018 if you would discover a bug in that time period.
@lKuzon Ideally you reach resilience against bugs in the node software by having multiple different implementations by multiple teams so if one is broken, only the nodes using that software will fall out of sync.
You essentially need a "decentralization of node implementations".
You essentially need a "decentralization of node implementations".
@lKuzon This is btw. the reason why we will have "Bee" and "Hornet" nodes that have been implemented by completely different teams in completely different languages.
It is very unlikely that two teams will make the exact same mistake which makes the network resilient against bugs.
It is very unlikely that two teams will make the exact same mistake which makes the network resilient against bugs.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
