It's an exciting experience to hear for the second time the wisdom of @MichaelSuttonIL behind the endless lines of code that helped to stabilize and modernize the #kaspa network from the Genesis block until today.
#Kaspa#DAG#Rust
๐The #Kaspa meetup videos are rolling out!
Pt 1, @MichaelSuttonIL tells the story of the first 6 months of #Kaspa mainnet, what led to the proposal of the Kaspa #Rust project, and describes a new 4th crypto dimension - High Performance Computing.
https://t.co/iXcxuoYTRy
Big thanks to @fishtuna and @laudena for transcription/translation, & @ChadBallantyne for consultation and post-production work, as well as to everyone else who worked on the video and event.
Kudos for event planning, hosting and sponsorship - @KASHODLER, @avidanab, @ishziv, @Kaspa_HypeMan, @KaspaCrypto, and @rhubarbmedia. #CMF
Parts 2,3 & 4 will drop soon.
I had the honor to give a lecture yesterday on the blockchain field in relation to kaspa at the first Israeli Kaspa Currency conference with those amazing guys who became friends and family at this long journey of kaspa.
it was a real pleasure to participate on Q&A panel at the first Israeli Kaspa Currency conference with those amazing guys who became friends and family at this long journey of kaspa.
Hi $kas. So apparently, some people are concerned about the fact that we have some gaps in our ledger history. Some people asked whether this somehow implies there are issues with the security or transparency of the chain (and as usual, some trolls we all know went as far as arguing this "proves" we are "hiding" the "fact" that we "speedmined" the coin). Let me put your mind at ease: as I am about to explain, this is a complete non-issue.
0. Before we start you have to understand that pruning is crucial. Without pruning, at full capacity 10BPS, the ledger grows at a rate of almost 30TB A YEAR. This is extremely non-sustainable if we hope Kaspa is to remain decentralized.
1. The main concern, it seems, is that the lack of entire ledger data allegedly implies that the current state could not be verified from genesis (and in particular, that there is no proof that there was no pre-mine). This is not the case.
The genesis block itself is hardwired into the code of the node, as you can see here:
https://t.co/jyl4YCeAcV
In particular, the line (163) I linked to shows that the hardwired genesis block has an empty UTXO set, that is, there was no premine (the thorough reader can clone the repo and verify that EMPTY_MUHASH is indeed defined as the hash of an empty-set).
Among the data stored by the node is a proof-of-genesis. The proof-of-genesis is a short string that cryptographically proves that the current state indeed evolved from the hardwired genesis block, but has the magical property that forging such a proof requires as much work as was put into creating the entire ledger. That is, this string provides proof that the genesis block and current state are authentic, and this proof is just as sound as having the entire ledger.
The technique used to generate the proof is discussed here:
https://t.co/VT7leOQAXM
You can also refer to the "pruning block headers" section of the GHOSTDAG 101 workshop for a broad overview of the technique:
https://t.co/pfN3dZGi4N
The bottom line is that the data available for each node suffices to verify the current state from genesis.
Not running an archival node from day one might have been a bit short-sighted, but frankly there was so much to do post-launch that it got sidelined, mainly because we knew that it is not crucial for the security or integrity of the network, so it wasn't highly prioritized.
2. The ledger data is mostly not very interesting, I really don't understand what most users expect to find there.
That being said, there are reasons to want the entire ledger data, the main ones being:
a. Aesthetics. I.e. I wouldn't have to even explain all this if the entire data was available.
b. Statistics and research: these data could be used to investigate trends and global phenomena.
c. User needs: some users might need this data, e.g. for tax audit reasons (for example, in Israel, there are different tax rates for mining profits vs. trading profits, hodling miners need to pay tax on the mined coin according to its value at mining time, so they should be able to prove at what time they mined it, etc.).
For this reason, we are making an effort to piece together the entire history (so in particular, if you happen to have old datadirs, please give us a shout out in the #datadir-exchange channel on our Discord server).
3. As mentioned, some bored fudders in dire need of a better hobby tried to leverage this as "a proof" that we have "speed mined" or whatever. This is a stupid argument for two reasons:
a. It is impossible for ANYONE on ANY (permissionless) coin to prove that they DON'T have more money than they claim they have. It is simply not possible. Anyone who wants to hide coins could store them in a separate address they keep secret. Proving that two addresses belong to the same person ranges from extremely difficult to impossible. When the coins in questions are mined by that person, this is strictly impossible, since the miner can just mine the excess to a separate address, and there is no history showing these coins are linked to the known address. This remains true even with the entire ledger data available.
b. Even in the hypothetical, extremely unrealistic case, that somewhere within the history there is some "smoking gun" proving wrongdoing by someone. The current state of affairs is that we are piecing together the history from data retained by users. In particular, any user can verify that the datadir they own was included (so it could not be conveniently omitted). Hence, no single person has any control over where the gaps in history actually are. So what is the argument here actually? That the full ledger data hides some terrible secret, and we are counting on blind luck that the particular portion containing this secret will never turn up? Give me a break.
So in summary, the pruning mechanism is designed such that Kaspa is safe, secure and retains its integrity even without any archival node whatsoever. The lack of archival nodes does not make it easier in any way to hide funds. There are some drawbacks to the gaps in the history, but they are mostly about research data and user convenience and they do not compromise the transparency and security of the network in any way whatsoever.
(P.S., not an extremely crucial point but you have to admire the irony: some of the trolls pushing this FUD are proponents of a particular privacy coin. The entire promise of privacy coins is that the ENTIRE LEDGER is concealed, and there is no way to know who paid who and how much. So according to these people's flawed logic, that the entire ledger is inaccessible is "a feature", but some small gaps in the history are "lack of transparency". This is a particularly colorful example of morons drawing targets around poorly shot arrows).