Re: Bad Code Has Lost $500M of Cryptocurrency in Under a Year
The recent (and a really good) example of bad code here: http://www.tangleblog.com/wp-content/uploads/2018/02/letters.pdf
Quote
Dom, David and the rest of the IOTA team,
We have found serious cryptographic weaknesses in the cryptographic hash function
curl used by IOTA, curl. These weaknesses threaten the security of signatures
and PoW in IOTA as PoW and Signatures rely on curl to be pseudo random and collision
resistant.
...
We have found serious cryptographic weaknesses in the cryptographic hash function
curl used by IOTA, curl. These weaknesses threaten the security of signatures
and PoW in IOTA as PoW and Signatures rely on curl to be pseudo random and collision
resistant.
...
This is not bad code. It is DIY crypto. Worse, DIY crypto for a primitivea DIY hash! Worse still, DIY crypto by a corporate outfit which never showed any evidence of being inhabited by world-class cryptographersdespite their claim in a spin-job piece that the IOTA Foundation has already subcontracted a team of 5 world-class cryptographers, as well as 3 independent ones to come up with a final design of Curl and then start the long peer-reviewed process, as was always the plan. N.b. that even world-class cryptographers need their primitive designs to undergo extensive peer review before fielding them with Other Peoples Moneywhether its the final design, or otherwise!
One of the people who broke IOTA had some damning words for it, in Cryptographic vulnerabilities in IOTA:
Quote from: Neha Narula (2017-09-07)
You might think that IOTA, a cryptocurrency worth over a billion dollars, and working with organizations like Microsoft, University College London, Innogy, and Bosch, BNY Mellon, Cisco, and Foxconn (through the Trusted IOT Alliance) would not have fairly obvious vulnerabilities, but unfortunately, thats not the case. When we took a look at their system, we found a serious vulnerability and textbook insecure code.
In 2017, leaving your crypto algorithm vulnerable to differential cryptanalysis is a rookie mistake. It says that no one of any calibre analyzed their system, and that the odds that their fix makes the system secure is low, states Bruce Schneier, renowned security technologist, about IOTA when we shared our attack.
In 2017, leaving your crypto algorithm vulnerable to differential cryptanalysis is a rookie mistake. It says that no one of any calibre analyzed their system, and that the odds that their fix makes the system secure is low, states Bruce Schneier, renowned security technologist, about IOTA when we shared our attack.
Anybody who buys into such ill-conceived crypto-junk as IOTA deserves to lose their money, on grounds of foolishness.
As these events occur again and again we get to reflect on code developers and their skills. Should they even be allow to release these coins?
Whos going to stop me from releasing code? You? Some government?
N.b. that anybody who could forcibly stop code monkeys from releasing bad code would also have the practical power to ban Bitcoin.
Even though most of the coin source code is found in github, do people really go through them? They are usually provided with no clear explanation as to what is going on within the code. Much of the system is copied (forked) from previous projects and re-used. It takes quite some time and effort to figure out what is going on.
I see many people signing up for bounty programs for new coin announcements even though much of the business and/or technical details are missing. The only thing the announcements seem to boast are the bounty programs. These coins still raise millions of USD.
By looking at some meetups activities, it looks like the waves of new coins will continue if not pick up more speed. With such a madness to release coins so quickly, the coding errors are inevitable. But prior to talking about code bugs, the requirement errors should be first identified. I wonder if all these rapid releases even understand their own requirement.
I see many people signing up for bounty programs for new coin announcements even though much of the business and/or technical details are missing. The only thing the announcements seem to boast are the bounty programs. These coins still raise millions of USD.
By looking at some meetups activities, it looks like the waves of new coins will continue if not pick up more speed. With such a madness to release coins so quickly, the coding errors are inevitable. But prior to talking about code bugs, the requirement errors should be first identified. I wonder if all these rapid releases even understand their own requirement.
Well, next time somebody tries to argue with my statement that 99.9% of altcoins an 100% of ICOs are pure make-money-fast scamsmay I refer to your above statement?
Nullius, thanks again for the heads up on Simplicity. I looked over the white paper and asked the Google his thoughts and am excited to give it a test drive in future. Especially the different combinators and convenants.
Ironically though, you sort of reinforced the point I had proposed earlier, in that by possibly using a functional language (Simplicity is functional), you lessen the chances of bad code due to the nature of functional languages having immutable state. In fact, Simplicity takes it a step further as they don't allow loops (page 1 of white paper) and use functions written in Haskell, another functional language (pg.24 of white paper) to generate Simplicity.
Ironically though, you sort of reinforced the point I had proposed earlier, in that by possibly using a functional language (Simplicity is functional), you lessen the chances of bad code due to the nature of functional languages having immutable state. In fact, Simplicity takes it a step further as they don't allow loops (page 1 of white paper) and use functions written in Haskell, another functional language (pg.24 of white paper) to generate Simplicity.
Its all about the right tool for the job. Simplicity is domain-specific, with very particular requirements. The code used for creating Simplicity will inherit some second-order version of the same requirements.
Whereas for general-purpose programming, my own point was that there is no magic bullet. If some Haskell experts think that Haskell is the right tool for their job, then they will probably get good results. But their results will not necessarily be superior to those of C++ experts writing C++. More to the point, Haskell would not be a magic bullet for fixing the trash code churned out by idiots; and on the flipside, there is no sound reason for, say, Core to switch to Haskell.
I observe, Simplicity will not be able to prevent people from writing insecure smart contracts. Again: No magic bullet! Its purpose is to let smart people formally verify their contracts.
Most of the Bad code is a result of companies using proprietary software. In the Open source environment, proper Peer review are done, before the code is submitted and applied. Some of these companies are in such a rush to be "first to market" that they skip beta testing and review. They want to be "first to market" and then patch like cowboys in a live environment. 
This is why Bitcoin is so secure. Nothing is rushed, proper testing is done on a TestNet and submitted for Peer review.
This is why Bitcoin is so secure. Nothing is rushed, proper testing is done on a TestNet and submitted for Peer review.
Open source is not a magic bullet, either. You didnt say as suchbut many people do. Thus why I added boldface to the important parts, which are facilitated and enabled by open source.
We saw what happened with rush implementation with Bitcoin XT. 
XT had severe bugs in its wetware layer.
On the other hand, I could say that people/users can be blame too for this inexplicable continuous hacking & bad news. Why?
Simply because most of them don't want projects that are slow on production. They only think about the "hype" without realizing that there is a proper flow for conducting new features. They passively pushes the developers/coders to do an early releases that have greater chances for bugs and errors. This is a very common thing on some projects here in bctalk
Simply because most of them don't want projects that are slow on production. They only think about the "hype" without realizing that there is a proper flow for conducting new features. They passively pushes the developers/coders to do an early releases that have greater chances for bugs and errors. This is a very common thing on some projects here in bctalk
This is what RISKS-subscriber types used to call dancing pigs. People will not pay for correct, reliable, secure things. People will not wait for them, either. They want their dancing pigs, and they want them now!
And in crypto pretty much every bit of code is critical while most devs still seem to be in happy-go-lucky start-up land, instead of in finance.
Your post gave me an inspirational idea. Would having programmers who previously worked for banks be preferred since they'll be particularly aware and sensitive to the nature of finance?
Banks code quality is oftentimes abysmal. Of course, it depends on the institutionand such questions as, consumer banking vesus institutional investment. But overall, I think that much banking code is WTF-riddled stuff which ultimately relies on transactions being revocable. At best, you cant rely on code being good just because its from a bank!
Moreover, persons from banks have been immersed in an institutional culture which is inimical and antithetical to the culture of Bitcoin. Individuals will differ, of course; but Id start out wary of anybody who had worked for a bank.
Ultimately, with people as with languages, there is no magic bullet. If you look to the backgrounds of the best (non-anonymous) Core developers, I think youll find some vast differences. So as for past history. The common factor in the present is that they are smart, serious, responsible people who are devoted to Bitcoin. In some cases, zealously.
Also regarding the "wild west", regulations will be happening. They already are in some legal jurisdictions.
Good luck regulating me. Or discerning which jurisdiction I am in.
Bitcoin is cypherpunk money. Though I am sensitive to needs by others to comply with legal régimes, I am fundamentally opposed to any Bitcoin regulation of any kind. Also, I myself will always ignore it in my personal affairs.
Moreover, regulations dont work. Highly regulated fields such as (cough) government and military contract work do tend to be bug-riddled abominations. Banking code in many cases, as aforesaid. Healthcare-related code, quite often. And transportation... Everything is broken. Regulations dont fix it.
Another area that needs a close look is the way that KYC is conducted in ICO/ITO offerings. In my view, the risk of giving out your information to some project on the Internet is just as high, if not higher, than the risk of losing funds from the venture. Identities can be stolen, either by a hack or by malicious ICO projects. This is something that the industry could establish a decentralized solution that would balance the legal requirements with practical requirements of the crypto model. These rules were written for banks, and while there is some overlap, there is also a different set of considerations that need to be taken into account when dealing with decentralized entities.
I have an easier solution: Dont ever do KYC. Avoid anything and everything which requires it.
For Bitcoin-related purposes, I have never submitted to any KYC identity-rape. No, really. Nobodys records show I own even a single satoshinobodys, as in nullius.
Ohyou said ICO. Well, those are scams which should be avoided, regardless.