My quick reading of it: there's this chain of chains that tries to make it possible to interoperate the various blockchains. The way they do it is they have a gatekeeper on each chain that locks up funds on one chain and releases them on another. Someone found a way to replace this gatekeeper with their own version, leading to havoc.
The technical details are fascinating and super complex. And IME comically badly documented.
>Someone found a way to replace this gatekeeper with their own version
The gatekeeper function was "protected" by hash of its name and parameter types and this is the $600M quote:
"You don't need to find a full hash collision, you're only checking the first four bytes. "
And it is all in the environment where mountains of hardware with highly optimized software are combined in huge networks with the only purpose of calculating few basic types of hashes :)
If I understood it correctly, there was one contract (EthCrossChainManager) which could call arbitrary methods on other contracts, the methods being identified by a 4-byte hash. There was another contract (EthCrossChainData) which had a method the attacker wanted to call, since it allowed to change relevant public keys, but which had a check on the identity of the caller. However, that check allowed the former contract to call the later. So the attacker only had to find a method name which led to the same 4-byte method identifier, and trick one contract into calling the other; the first one though it was calling an arbitrary function on an unrelated arbitrary contract, while the second one thought it was a legitimate internal call from the related first contract.
As another comment mentioned, this is a classic "confused deputy" vulnerability.
Ethereum smart contract functions (i.e. methods) are addressed based on a four-byte hash of the signature, within the context of the smart contract itself (a smart contract is analogous to a Java or Python class instance, having state and logic). So, after compilation, a function will be addressed like <smart contract address>.<method hash>, if you can imagine.
This is distinct from other languages where methods and functions are addressed unambiguously by the full signature as a string (like in Python), or by a specific memory address (like in C).
In most situations this addressing scheme works very well, because in practical terms there will never be a hash collision inside of a smart contract, and if there were such a collision, the compiler would catch it and fail to compile, and the EVM would reject any bytecode containing such a conflict. Regardless, this is not a problem within Ethereum.
The thing is, Poly Network is a separate thing from Ethereum, and although it does integrate with Ethereum, it does so with its own separate software. The way it interfaces with Ethereum is via several Ethereum smart contracts, including one (smart contract #1) that holds the tokens that it manages on the Ethereum blockchain (valued in the hundreds of millions of dollars), and another (smart contract #2) that permits users of the Poly Network software to invoke arbitrary functions on arbitrary smart contracts already deployed on Ethereum. The Poly Network software talks directly to these smart contracts.
Poly controls these smart contract with a permissions system implemented inside the smart contracts themselves, whereby the invocation of any function of the smart contracts is verified against a list of public keys (i.e. account addresses) that are authorized to make any such invocation. Only users that hold the private keys that correspond to these authorized public keys may invoke the smart contracts' functions; in practice, these keys are controlled by the Poly Network software. Each smart contract stores this list within its own data (analogous to private instance data inside a Java object).
The problem is that the Poly Network proprietary software uses the same authorized key pairs to move funds in and out of smart contract #1 and also to invoke smart contract #2. This means that a user of the Poly Network software can use smart contract #2 to invoke smart contract #1, which is very bad.
What happened is that the hacker figured this out, and used smart contract #2 to update the authorized public key list inside contract #1, which was allowed to happen because he routed the message through the Poly Network software, which dutifully signed the message with its own secure private keys. In other words, the Poly network signed a message from the hacker authorizing the Poly smart contracts to replace the authorized public key list with the hacker's public key, giving the hacker control over contract #1.
It wasn't as simple as this, though. Apparently, although the Poly Network allows any function name to be invoked by the end user, that function is required to be invoked with a signature that includes a particular set of arguments, specifically "(bytes,bytes,uint64)". The hacker wouldn't be able to call "putCurEpochConPubKeyBytes" directly from the Poly Network software, because "putCurEpochConPubKeyBytes" accepts only one argument, not the three arguments that the Poly Network software uses to construct the signature for function invocations sent from contract #2.
So, the hacker had to discover another function name that when combined with the three arguments would result in a four-byte hash that corresponded to the four-byte hash of the function he wanted to invoke. By brute force the hacker discovered that "f1121318093(bytes,bytes,uint64)" has the same four-byte hash as "putCurEpochConPubKeyBytes(bytes)". So the hacker used an invocation to "f1121318093(bytes,bytes,uint64)" to invoke "putCurEpochConPub...
So my understanding of contracts (and particularly cross chain ones) is low. But how likely is the compare-four-bytes-only to be a deliberate weakness? Is this an inside job?
Cynic mode: Putting sighash in things you shouldn't is incredible common cargo culting in cryptobro areas, it's much more likely that the people involved didn't even understand its implications.
So as someone very critical of the whole DeFi / Smart Contracts philosophy (purely in terms of practicality, not the high-level concepts behind it) - please explain to me how the impacts of those bugs are going to be mitigated going forward.
At will and ex-post broadcasting "oops, we had a bug - please roll back or block the bad actors" doesn't strike me as a solid solution, nor a fair & automated one. I was under the impression this hyped up space learned from the DAO fiasco but i might be wrong.
You can't really mitigate this entirely as you can't really write software without bugs.
There will always be a need for this eventual "please roll back or block the bad actors". And more money you put into the game more it will be demanded when someone gets hurt.
I don't like crypto but this way of fixing things is pretty normal and standard in software and orher industries also. You simply can run into situations which weren't planned. So i don't think there is a problem with these fixes
> I don't like crypto but this way of fixing things is pretty normal and standard in software and orher industries also. You simply can run into situations which weren't planned. So i don't think there is a problem with these fixes
It's normal in most industries, but it also defeats the main selling point of crypto - "code is law" doesn't actually work, you always end up in a world of humans and politics.
Yes i agree and i don't think there is actually a problem with that. We are humans and we should be able to solve problems like this. I try to view it just as another way of bug fixing technique. Sometimes you can just explain that you messed up and others will understand
You always need to rely on some external authority. You can't crypto/decentralize everything.
And relying on external authorities is a good thing actually. Because it's way way more effective than software solutions. Now of course the external authority can compromise sometimes but for this we also already have solutions for like thousands of years - diversification. If people just would learn not to put all their eggs into pne basket and expect eventual compromise that wouldn't be a problem. I think some 101 finances and practical real world problem solutions classes or something like this would get us way further than decentralisig everything with software
Sounds to me like there's a decentralized, trustless incentive to make sure your software is secure. Yelping NO FAIR! and central-bank-style rolling back the oopsie does not seem very radical and libertarian and crypto.
This is plain silly. Even centralized payment settlement systems do depend on thousands of lines of closed source code that contain bugs. Banking backends have bugs. Cars have bugs. Even buildings may have fuck ups that need to be dealt with after construction.
If you think it through you simply can not rely 100% on anything humans build. But still societies as a whole thrive and human progress is real.
DeFi is no exception. It’s designed to make banking cheaper. But it’s new technology and will take some time to mature.
Personally, I believe banks won’t exist in the traditional sense anymore 20 years in the future if you like it or don’t. I mean, I love steam locomotives but I don’t expect them to be a common means of transportation ever again. ;-)
Ethereum contracts are not 100% immutable. They need to maintain state like a token‘s balance. That’s why Ethereum‘s VM supports contract variables.
You can also use variables to store addresses to other contracts and call external methods indirectly using these pointer like structures. If I understood the bug correctly, the hacker was able to modify such a pointer and redirect all transactions to a wallet contract she controlled.
So this is how you can upgrade contracts: There is the „implementation contract“ pattern. Basically, you define a user-facing proxy contract defining the interface but all it does is delegate user calls to the actual implementation contract by maintaining a variable pointing to it. Using a privileged call you can update that address even after deploying the proxy.
I bet that we will see insurance companies emerge in the market. Contracts will send a portion of the transaction to an insurance company. The insurance company would mandate "layers" to validate the contract. Users can then claim damages if there was a bug in the contract.
Once all this is done, the transaction fees will be equal or higher than traditional banking systems :-p
There are a number of "smart contract" insurance companies already, Nexus Mutual is one of the main ones, and the rate of return after paying for insurance on a number of platforms exceeds what normal banks would pay you.
At least up to this point, the amount of growth in the industry from moving fast and having buggy software (as opposed to moving slow and having fully verified software) has more than made up for all the hacks. For every $600 million dollar hack, there's been $6 billion dollars in gains from growth in the industry. Moving slower means fewer hacks, but it also means lower growth, and the growth is the more important multiple right now.
As the growth slows down there will be an increased focus on best practices for smart contracts, on auditing, and on formal verification. There are also a lot of startups that are looking into insurance for smart contracts and crypto balances in general.
In general, the best experts in the space could probably write smart contracts with >100x fewer bugs than your typical smart contract. Especially with something as complex as the EVM it's difficult to assert that any piece of software is truly bug-free, but there are a lot of steps that can be taken to make them significantly more rare. It's just that these mitigating steps are more expensive than the growth at this time.
There are several issues with this. The main one is how can people trust a product that will let them lose money in the name of growth.
The second one is that the more money, the more incentives to hack. And given that transactions are irreversible, you only need each bug once, you don't care that it's fixed later. So if a bug can report a hacker millions of dollars, there's going to be quite a lot of hackers researching, probably with more effort there than the effort put in best practices, audit and formal verification.
Over time, there will be old smart contract code that is trusted because it has been used for so long, and there will be new code that is less trusted because it is new. Time will ensure that smart contract code that is flawed will be discarded and forgotten, or blacklisted, so it will be safe to assume that any old code that is still popular is trustworthy. Time will also ensure that popular code is well understood by experts who would be in a position to detect and understand any problems in the code.
The problem of buggy software will continue to exist for new smart contracts that are introduced and manage to capture value quickly, but as the ecosystem matures and more niches are filled, new code will be less likely to attract large numbers of users, so the scope and impact of any bugs in that code will be much less.
Eventually an equilibrium will be reached whereby survival of the fittest ensures that the smart contracts most people rely upon can be trusted. Effectively, some smart contracts will build brand value, and people will be able to rely on the reputations of these smart contracts. Some people may take a risk on a new smart contract and loose (or win), but most people who follow the heard will not have a problem.
The problem is that it is totally possible for there to be a hidden bug in an old smart contract that everyone trusts. And only a single bug like that can destroy the entire ecosystem. It's not enough for trusted smart contracts to be less buggy, they have to be so secure that they don't have any bugs ever
Yes, the process I described above would not be sufficient to ensure that smart contracts are perfectly safe, with zero exceptions ever.
It is also important that scrutiny be applied to these protocols, and I imagine that at some point DeFi protocols may be be subject to regulator audit and approval before they are opened up and made available for use by retail customers. If the right people pay enough attention to the implementation of these protocols, then it should be possible to trust them. Also, if you yourself are risking significant funds, it wouldn't be a bad idea to personally review and understand the smart contract code.
That being said, over extended periods of time (decades), long-lived smart contracts will tend to be safer, and insecure smart contracts will tend to be identified as such. If enough value is at risk, and if enough time has passed, then it is extremely unlikely that an exploitable bug will exist that has not already been exploited.
Keep in mind that as a general rule smart contract implementations are immutable, so any bug that exists within a protocol is typically a bug introduced to the protocol when it is first deployed. There are never any "new" bugs that are introduced to an existing smart contract; if a bug emerges after a long period of time has passed, it is a bug that existed at the beginning but had not been previously identified.
At a certain point the passage of time will have reduced this risk below a tolerable threshold that is more than outweighed by the value that people get from using the software. So in practical terms, in the aggregate, such long-lived systems could reasonably be treated as secure.
Cryptocurrencies are fascinating but the irreversibility is not a feature but a bug.
I don't get the appeal for irreversibility. A legitimate trade always occurs between willing partners, why would you be so afraid that the transaction would be cancelled?
The only legitimate use that comes to my mind are complex financial instruments where things mostly happens with an assumption that the underlaying assets are very well defined, so you want assets be stable.
Is there a company or cryptocurrencies focusing on solving the human part in the transactions? Huge part of the value with working in traditional systems is their resiliency against human errors. Sometimes mistakes happen(a faulty system, a design bug or straight out human error and people who are trying to take advantage of those), most of the time these are correctable.
> why would you be so afraid that the transaction would be cancelled?
The transaction will likely be for goods, services and/or money. If one or more parties don't provide said goods, services or money then the other parties may well want the transaction cancelled. That's different from them all being willing to transact in the first place.
That's not a justification for irreveribility. The opposite in fact. But if you were planning on screwing your customer, say, the irreversibility is a bonus.
> A legitimate trade always occurs between willing partners
Charge back fraud (also called friendly fraud) is a big problem in commerce, where the buyer will buy something, receive it and then cancel the payment. The merchant will often have to swallow the cost.
But that is an illegitimate trade and cuts BOTH WAYS. When the buyer is fraudulent the merchant swallows the cost AND when the merchant is fraudulent the buyer swallows the cost.
That's actually why credit cards come with protection against fraudulent merchants and you need a good enough credit score to actually get a credit card. On top of that, payment processors run fraud detection systems that block suspicious actions.
Irreversibility turns the trade into a competition over who is the better fraud. The only thing that the crypto guarantees is that the winner keeps the prize.
> Irreversibility turns the trade into a competition over who is the better fraud. The only thing that the crypto guarantees is that the winner keeps the prize.
I think it's more complicated than that. It moves the fraud risk to one specific spot (the consumer) which VASTLY simplifies the checkout process + the costs associated with online purchasing. Right now online payments are a giant mess - every single merchant has to implement anti-"fraud" tools to try and ascertain the identity of the consumer and determine if it matches the owner of the card.
As a consumer, I would happily take this trade for lower prices.
One thing I don't understand is this. The vast majority of people will use credit cards (or equivalent) to purchase things. If I wanted to pay with Bitcoin I would get a crypto credit card.
Payment processing just isn't the same thing as a currency. It's like expecting the dollar bill to do payment processing. Is lightning network supposed to be that fancy decentralized payment processing platform that is going to kill credit cards or will people stick with visa and mastercard?
The end question is "why bother" with cryptocurrencies if you have a central authority that handles transaction disputes.
It makes sense if you have a small group of trusted entities that want to have a ledger between themselves (like inter-bank ledgers for various purposes) but if you have somebody in the middle handling disputes... don't you just have paypal? Then cryptocurrency is just an extra complicated step that doesn't really matter.
If only there was some kind of extensible system that would allow for people to enter into contracts with the protections they desire. One might even call these contracts "smart", and could include the ability for a trusted third party (or collection of third parties) to provide a trusted role in approving the transaction. If only such technology existed.
The appeal for irreversibility is the complete removal of counterparty risk. It's a sharp edge and you need to be structured/careful, but for certain types of transactions, the cost of being careful is 100x cheaper than the cost of finding and using a trustworthy counterparty.
A strong example of where the irreversibility of crypto is very useful is in the online sale of expensive electronic goods. Especially for things like speakers, TVs, and projectors, fraud rates are extremely high and boutique shops struggle to effectively support online customers, because such a large percentage of their sales get chargebacks after they've shipped the goods.
If you accept crypto, you have a 100% guarantee that when the money has hit your wallet, the money is good and will stay in your wallet. You don't need to deal with an anti-fraud firm, you don't need to check whether this person is trying to have the goods shipped to a sketchy country, and you don't need to fear that your $6,000 item is going to sail away from you without payment.
Yes, this means that the consumer has to fully trust the merchant, but in the case of online sales, the merchant is the known quantity with a reputation. Every consumer is a random, unknown person to the merchant and so it's much harder (and therefore more expensive) for the merchant to establish trustworthyness.
> in the case of online sales, the merchant is the known quantity with a reputation
This is absolutely not true. There’s plenty of risk buying expensive goods online, lots of problematic merchants. I don’t understand why merchants are inherently more trustworthy than customers?
It's not that merchants are inherently more trustworthy, it's that the buyer has ample opportunity to research the merchant and establish credibility. If there's a merchant that only accepts crypto and the buyer can't get comfortable that the merchant is trustworthy, the buyer can walk away instead of making a purchase.
The merchant has much less to go on. There aren't review websites detailing the reputation and history of every random buyer that enters a credit card onto your website.
I don't quite buy that. The ability to claw back credit card payments to fraudulent merchants enables commerce before credibility is established. This is in the merchant's interest too, especially when they're starting out.
It's only in the interest of the merchant if they are selling items that have a low enough chargeback rate. Credit cards and clawbacks work great in-person and for low value online merchandise but it's non-viable for online high resale value merchandise.
>it's non-viable for online high resale value merchandise.
What does that mean?
The phrase "high resale value merchandise" sounds like it refers to the stuff that, in physical stores, is kept in a locked case so you have to ask someone to open it.
But that stuff is readily available online, isn't it?
The chargeback returning the money to the rightful owner doesn't help the merchant who shipped $6,000 of hardware to some stranger. Certain types of electronic sales simply can't be done online because of the high rates of fraud. When you add crypto, these sales become possible.
Yes, they become possible at the cost of putting the counterparty risk onto the consumer, but that's better than the sale being entirely non-viable.
I don’t understand your line of reasoning at all. Like the others have said, moving risk from sellers to customers is not a solution.
Especially when the risk of customers committing fraud is incredibly low. Why would you start with an assumption that this is something so rampant it needs to be solved in a way that harms literally all honest customers?
I operated an online store selling $2,000 pieces of computer hardware, and both credit card companies and banks alike refused to service us because fraud rates were extremely high.
If you think fraud rates are extremely low, you've never tried to sell $2,000 electronics online as a boutique electronics store.
It’s not that I don’t believe there is fraud, I’m saying the vast majority of customers are well-intentioned. If this is not the case, could you point me to some sources and not just your anecdote?
Regardless, how does Bitcoin solve this? There’s a lot of illegitimate users of crypto, how are you solving fraud with irreversible transactions?
> If this is not the case, could you point me to some sources and not just your anecdote?
It's difficult to find sources, but generally speaking you are going to go 'on warning' at around 1.5% and if you go too much over 2% chargeback rate you just get dropped by the credit card company as a customer. Credit card companies don't like dealing with high fraud customers and won't support you.
Bitcoin helps in two ways. The first is that it gives you a way to accept money at all. As stated above, if your chargeback rate is above 2% for any extended period of time, all of your payment processors - including your banks - are going to drop you as a customer. You may be willing to pay 5% overheads for a higher chargeback rate, but your credit card company doesn't want that as a statistic and they just won't support you.
The other way Bitcoin helps is that once your wallet (use BTCPay) says "2 confirmations" you've got a 99.97% guarantee that the money is yours and won't be reverted. And that's true whether you are receiving $2,000 or $2,000,000. Regardless of whether that money came from "an illegitimate user", you as the merchant can be confident shipping hardware out because you know that the payment is not going to be clawed back.
Fraud is a cost of business. Prices can be raised to take it into account; different markets have different rates of fraud, but fundamentally it can be priced in.
Merchants are in a much better position to price this in than consumers. Merchants structurally execute a lot more transactions within a market vertical than consumers ever do.
If the merchant can't do that, because deals are simply too high value or aren't frequent enough, then insurance companies or intermediaries (e.g. payment processors) can pool risk across merchants, using actuarial techniques to assign a price to the insurance. For example, professional indemnity insurance for property transactions.
If you raise your prices, you drive away legitimate customers but don't drive away fraudsters, since the fraudsters aren't actually paying with real money. So raising your price increases the percentage of fraud you see, which means you probably need to raise your prices further, which further increases the relative amount of fraud.
To counteract this negative feedback loop, assuming the increased prices don't drive away all of your real customers, you can spend the increase on transaction analysis, and turn away customers based on their likelihood of fraud, so you've added inefficiency into the system to help deal with a criminal element, and also likely turned away real sales due to false positives in your analysis.
It's no surprise that these types of merchants are looking for a disruptive technology to remove this inefficiency. Doing so would allow them to charge less and outcompete as well as capture the entire market of people marked as false positives by other merchants.
Completely true. Irreversibility and lack of consumer protections might just about fly for small transactions with pocket change which people on both sides of the transaction don't mind losing, but isn't going to be acceptable to most people for larger transactions. If I'm buying a house, for example, I don't want the risk of it being stolen because of an unfixable bug in a smart contract, or sold to the wrong person by an irreversible mistake entering the address. Scaling up further, if you look at the back office for any investment bank, a big chunk of people power is spend on trade reconciliation and essentially fixing human errors - this is a good thing for both parties making such transactions.
Irreversibility is one of its best features. Imagine a scenario in 50 years when 80% of token holders are dead... This could result in a non-trivial % of tokens being lost forever; this greatly reduces the remaining circulating supply of tokens and thus makes everyone else who still remembers their keys wealthier (less supply, same demand translates to higher price).
On the other hand, stocks are more susceptible to demographic collapse; for example, if a lot of shareholders die and all their relatives inherit their stocks, you can expect a selloff to occur which could crash the stock price. With stocks, shares are never lost forever; they just get passed down to an increasing number of increasingly lazy and incompetent heirs. That's not to say that cryptocurrencies cannot be passed down (they can) but the fact that they are tied to a secret passphrase (instead of the legal system) makes it more likely that they can get lost. The negative economic effects of wealth inheritance are not as strong in crypto space.
The idea that negligent people may lose their tokens is highly meritocratic as it transfers wealth from negligent people to careful people.
Wait until the majority of boomers start retiring and/or dying, watch how that affects stock prices and/or the value of the USD relative to Bitcoin (if the Fed continues to prop up stocks artificially with more money printing), then we can talk.
> Sometimes mistakes happen(a faulty system, a design bug or straight out human error and people who are trying to take advantage of those), most of the time these are correctable.
These errors are correctable if the counter-parties trust each other, or at least have a relationship that they don't want to undermine by being petty.
Immutable blockchain systems are valuable in part because they allow entities to transact with each other even if they don't trust each other at all, don't know each other at all, or are even antagonistic with each other. Yes, if something goes wrong, a transaction won't be reversed, but without the blockchain these potentially antagonistic entities wouldn't have the capacity to do business with each other in the first place.
Blockchains allow these entities capture the value of transacting with each other—value that wouldn't otherwise be realized—at the expense of irreversibility.
You can potentially imagine that if antagonistic entities tried to do business in a more malleable environment, a request to reverse an error by one entity might not be honored by the other entity, or one entity might maliciously attempt to reverse a transaction that was not performed in error, but was simply disadvantageous in hindsight.
The possibility that a transaction may need to be reversed—or that a reversal request may need to be litigated—increases transaction costs, especially when counter parties are antagonistic. The certainty of irreversibility creates a context by which certain entities are willing to do business with each other, when they might not otherwise do business at all.
How do they transact if they don't trust each other? You have the guarantee that the money your received is not going back but what kind of guarantee does the receiver of product/service has?
Yes - so far, it worked well for extortion with ransomware but is that something that we want to have? Can you think of a legit business case where the merchant providing the promised service is guaranteed and all you need is a method to receive the payment? All that when the merchant and the buyer don't trust each other at all and on't have a conflict resolution mechanism. What do they trade exactly?
Irreversibility in the core protocol is a feature, and a necessary one at that.
If you start with irreversible payments and you need payments to be reversible with some kind of review/appeal process you can add reversibility through escrow. The classic arrangement is a 2-of-3 multi-key system where the payment is made to an escrow address where it can be either finalized or refunded only when at least two key holders concur; the third key, held by a neutral third party, is used to settle disputes when the payer and payee cannot come to an agreement on their own.
There are, however, situation were reversible payments are a liability, and there is no way to build an irreversible payment system on top of a reversible one. For example, you can't build a reliable escrow system on top of reversible payments since the payer can trivially circumvent the escrow by unilaterally revoking their payment to the escrow account.
“Find a hash matching these digits” is roughly Bitcoin’s proof of work system. Maybe another way of looking at this is that these weren’t hackers, they were just miners who found a more lucrative coin to mine.
> Who thought an amazing new P2P invention would improve the image of normal money and traditional banks?
Shady stuff that happens in the banking system usually happens behind the closed doors and we don't hear about it for years, if ever. Crypto/DeFi is new and exciting - it gets a lot of attention from press. It is still way easier for me to trust code than to trust people. Call it a character trait / flaw if you want.
This is perhaps the most confusing element of it all, to me. I can hardly imagine a legitimate reason to do this. Defeats entirely the purpose of a hash.
Checking whole hash was probably too slow, you can imagine they put in a check for first four bytes, if that matched then check the whole hash - probably merge conflict and lost the second bit - doesn’t seem too far fetched!
If I understood it correctly, the purpose of this hash is just to shorten the method signature (name+types) to a 4 byte identifier. Unless a contract has thousands of methods, the chance of collision is very low (and the compiler could detect any collision, since it can see all methods). The "legitimate reason" for shortening the method signature is probably just to save space; bytes on distributed blockchain transactions are expensive.
This blew me away. That's 2^32. They took a cryptographic hash, with good preimage/second-preimage/collision resistance, and then discarded 7/8 of it before comparing to ensure some user-provided input is valid. What in the world?!
There's a serious fundamental problem with DeFi that can't be solved with blockchains.
Someone starts a blockchain company and hires a bunch of devs who make, idk, $40 to $100 per hour to build the thing. Maybe more, it doesn't really matter. Even just one dev or a few devs can make all the contracts needed for this.
One day that dev notices a vulnerability in the smart contract he's writing! He has two choices: (a) patch the vulnerability, which will get him a pat on the back, or (b) convince himself he didn't notice anything, quit his job, wait a month, go to a coffee shop with a hoodie on, boot into whonix, connect to the internet with a 4g dongle, run a few lines of code, and get $600 million dollars.
Most people would choose (a)! And law enforcement is a thing! But a lot of people will choose (b), and if they do a merely decent job they will get away with it, and 600 million dollars is stolen®.
Actually, it's worse than that, because unlike normal banks, the code used by these digital banks is open source, and anyone in the world can go bug hunting.
A lot of these contracts, and especially those owned by first-tier cryptocurrency companies, are reviewed by 3rd party auditors. Of course that doesn't completely remove the risk, but certainly at least ensures that no obvious bugs are missed.
It’s very hard to take this claim seriously in this thread, which details a huge (and somewhat obvious) security vulnerability in a currency worth at least $600m (an amount anyone would assume is “first-tier”).
Yeah I can understand that. Once you dive into crypto however, you quickly realize that $600m is just not that much money (especially not if we are talking about digital assets valued at current ticker price). And that lots of money isn't necessarily the right measure of quality of the project.
That is literally what that means. Market caps are what they are because everyone who thinks it is worth less has sold and everyone who thinks it’s worth that or more will buy. There’s some outliers but in general these coins are trading their entire market cap over the course of maybe a month or less. Liquid generally means short term, if you can sell it for cash in under a year then it is liquid. Sure if you tried to sell all coin today in the same minute you won’t find a buyer but over a month this happens all the time.
I had never heard of this bridge before the attack. The fact that a project manages to attract half a billion in capital unfortunately doesn't say all that much, since so much capital is flowing in so fast to every project with a pulse.
And the bug wasn't really obvious, although the lack of input sanitation is something an auditor (given enough time) would probably point out.
It has $175 M locked in the protocol, it is also featured on https://ethereum.org/en/dapps/, and is one of the oldest DeFI projects. By my definition, it is both "first tier" and "high quality". We can of course have the philosophical debate of objectivity and if such thing even exists, not sure if it's needed here though.
You are right, it's not mentioned, but they do in fact spend hundreds of thousands every few months for audits. You'll find more info here: https://gov.pooltogether.com/
Not sure what you mean by source, but its fairly easy to find out if any official audits were done as this is always announced and documented by the involved parties (for example, I couldn't find any detailed audit info for Poly).
It's not like the audit is mandated by law, its initiated by the SC owners to put the investors at ease. A lot of companies like Certik, Consensys, ZK Labs, etc. provide auditing services for this purpose explicitly.
As this space evolves, I think there will be insurance and basic best practice safety measures. Also considering that almost all blockchains are open by design, it's no trivial task to liquidate a large sum of stolen tokens. So its not exactly a straight path from writing a script at Starbucks to making hundreds of millions of dollars.
I agree. There are already some insurance protocols in place - see Cover Protocol or Unslashed Finance. Its still very early in this space, but things are definitely developing!
Now say you're a company hired to do an audit. Same incentives.
The hilarious thing is nearly all of these high profile hacks happen even after being audited.
There was one company I remember being called out as a suspect, but I can't find the name.
Also given (a) anonymity (b) ability to take cover amid so many other hacks, you could do this for a few years, slow down, and remain a top tier firm claiming the lowest hack rate.
but is it that simple though? Even in enterprise company we have to do 2-3 review on PR before merging.
I think proper DeFi company should have their own system on deploying contracts. Further, they should have their own security team that audit everything.
> Actually, it's worse than that, because unlike normal banks, the code used by these digital banks is open source, and anyone in the world can go bug hunting.
An argument that open source is less secure, and on Hacker News! Now I've seen it all.
There is an argument to be made for having some things remain closed, and obscured from public view. If a company/group has an experienced and large internal audit team that reviews systems, and they are building something that is likely to be placed under extreme amounts of targeted attacks (military crypto, banking systems, etc.) it sometimes makes sense to not allow just anyone to see/poke at the whole thing.
Military cryptographic systems, IBM mainframes, and many other products use this approach as a layer in their security framework and it is actually pretty successful.
If I asked you to break into the a PFSense box you could just Google "PFSense version X.X.X CVEs" and you would probably get a way in if the box was enough out of date, but if you tried to find the same thing for something like the General Dynamics TACLANE you would have a hard time even finding where to start.
I wonder if there's some way to make a "thief monkey". Some program that searches your code for vulnerability patterns and rips you off if it can. (Obvs, a tame monkey will then give you the money back).
Humans might be motivated to sit on a bug until they can reach the cybercafe. Bots, not so much.
More than that, there's a minority perspective in DeFi that the code is the law. If the code allows it (e.g., withdrawals under an unintended circumstance), it's therefore legal. If it were illegal, the code wouldn't allow it.
I think this could make sense if it is applied in a small community of tinkerers that understand and accept the risks (cf. accredited investor), or I suppose a community of dissidents that trust the police even less than they trust the code, but for wider society it would not be appropriate.
I think the bigger problem is people who are intentionally being malicious rather than people who stumble upon a bug. Just look at how many people fall for wire transfer or gift card scams. Crypto allows scammers to do that much more easily, since there is no human in the pipeline to flag transactions, and since there aren't the same limits that banks put in place on transactions. If someone finds a way to exploit a particular pattern/transaction type/etc. it's not like you can just immediately patch it when you have a decentralized currency. Ex. in an Bitcoin wallet malicious actors could show any text they wanted in an update popup [0]. So of course this was immediately used to steal millions.
With crypto all it takes is one piece of malicious software, or to fall for a single phishing email, and you've lost everything.
> quit his job, wait a month, go to a coffee shop with a hoodie on, boot into whonix, connect to the internet with a 4g dongle, run a few lines of code, and get $600 million dollars.
Think again. In the wild wild west that is cryptocurrency the first thing people assume is an inside job.
People with a lot of money and a cut-throat ethic will send death threats to your front door merely for small bugs you accidentally commited to github or for a governance dispute on a forum where you posted pseudonymously.
If you dare steal money as an insider you had better make sure you know how to use it to quickly get high-end personal security for you, your family, and friends. This of course simultaneously outs you as guilty.
Any hack occurs and you are immediately woken up in the middle of the night to be interrogated by people you've never seen before let alone heard of, stomping through your apartment. Your life becomes a movie.
Angry vicious actors with few scruples and long memories will loudly and expensively hunt for you for the rest of your life so you can make them whole. LEOs aren't even your biggest concern at that point.
Being an insider or former insider after a large hack sucks whether or not you're guilty.
Is the disincentive with lack of security going to be so strong with crypto projects that people finally take it serious enough to make it a first priority?
I don’t like loss or theft ,obviously, but I have to think if regular IT/apps/software/networks etc.. had this big of a material threat, we would see far more secure systems and organizations.
So it would reason that as block chains and crypto eat the world they will raise the bar.
> So someone realized that they could send an cross-chain message directly to the EthCrossChainData contract.
> By sending this cross-chain message, the user could trick the EthCrossChainManager into calling the EthCrossChainData contract, passing the onlyOwner check. Now the user just had to craft the right data to be able to trigger the function that changes the public keys.
Could this bug have been avoided by extra safety features in the language used to write the contracts like a better type system? Or the code wasn't using all the language features it could? I found the cause of the bug hard to understand to be honest.
I currently work in the crypto space (views are my own). For the life of me, I cannot understand why we do not have a foundation built on something like TLA+ or the Z3 theorem prover instead of paying another human to try and poke your code for thousands of dollars. Maybe formal methods wouldn't be a silver bullet, but it seems a lot better and less error prone than manual review. Or maybe adopt existing knowledge from safety critical environments (e.g. programming brakes on a locomotive).
I always feel like we're making mistakes that tangential areas of software engineering must have already solved. I guess devs tend to also not like math or writing proofs either, which is ironic given this is "crypto" lol.
The "bug" is that some developers think of matching function signatures as some form of authN / authZ.
A few years back I wrote https://medium.com/coinmonks/lashing-out-at-a-spank-channel-... about a similar hack where a contract "trusted" a given (user input) contract based on nothing other than verifying a function signature. This latest hack was smarter but ultimately it still exploited a 4 bytes hash "security" feature...
125 comments
[ 2.5 ms ] story [ 1746 ms ] thread[EDIT] Okay not 5... maybe like 25 but not in crypto tech.
The technical details are fascinating and super complex. And IME comically badly documented.
The gatekeeper function was "protected" by hash of its name and parameter types and this is the $600M quote:
"You don't need to find a full hash collision, you're only checking the first four bytes. "
And it is all in the environment where mountains of hardware with highly optimized software are combined in huge networks with the only purpose of calculating few basic types of hashes :)
As another comment mentioned, this is a classic "confused deputy" vulnerability.
This is distinct from other languages where methods and functions are addressed unambiguously by the full signature as a string (like in Python), or by a specific memory address (like in C).
In most situations this addressing scheme works very well, because in practical terms there will never be a hash collision inside of a smart contract, and if there were such a collision, the compiler would catch it and fail to compile, and the EVM would reject any bytecode containing such a conflict. Regardless, this is not a problem within Ethereum.
The thing is, Poly Network is a separate thing from Ethereum, and although it does integrate with Ethereum, it does so with its own separate software. The way it interfaces with Ethereum is via several Ethereum smart contracts, including one (smart contract #1) that holds the tokens that it manages on the Ethereum blockchain (valued in the hundreds of millions of dollars), and another (smart contract #2) that permits users of the Poly Network software to invoke arbitrary functions on arbitrary smart contracts already deployed on Ethereum. The Poly Network software talks directly to these smart contracts.
Poly controls these smart contract with a permissions system implemented inside the smart contracts themselves, whereby the invocation of any function of the smart contracts is verified against a list of public keys (i.e. account addresses) that are authorized to make any such invocation. Only users that hold the private keys that correspond to these authorized public keys may invoke the smart contracts' functions; in practice, these keys are controlled by the Poly Network software. Each smart contract stores this list within its own data (analogous to private instance data inside a Java object).
The problem is that the Poly Network proprietary software uses the same authorized key pairs to move funds in and out of smart contract #1 and also to invoke smart contract #2. This means that a user of the Poly Network software can use smart contract #2 to invoke smart contract #1, which is very bad.
What happened is that the hacker figured this out, and used smart contract #2 to update the authorized public key list inside contract #1, which was allowed to happen because he routed the message through the Poly Network software, which dutifully signed the message with its own secure private keys. In other words, the Poly network signed a message from the hacker authorizing the Poly smart contracts to replace the authorized public key list with the hacker's public key, giving the hacker control over contract #1.
It wasn't as simple as this, though. Apparently, although the Poly Network allows any function name to be invoked by the end user, that function is required to be invoked with a signature that includes a particular set of arguments, specifically "(bytes,bytes,uint64)". The hacker wouldn't be able to call "putCurEpochConPubKeyBytes" directly from the Poly Network software, because "putCurEpochConPubKeyBytes" accepts only one argument, not the three arguments that the Poly Network software uses to construct the signature for function invocations sent from contract #2.
So, the hacker had to discover another function name that when combined with the three arguments would result in a four-byte hash that corresponded to the four-byte hash of the function he wanted to invoke. By brute force the hacker discovered that "f1121318093(bytes,bytes,uint64)" has the same four-byte hash as "putCurEpochConPubKeyBytes(bytes)". So the hacker used an invocation to "f1121318093(bytes,bytes,uint64)" to invoke "putCurEpochConPub...
https://twitter.com/kelvinfichter/status/1425217046636371969
https://threadreaderapp.com/thread/1425217046636371969.html
At will and ex-post broadcasting "oops, we had a bug - please roll back or block the bad actors" doesn't strike me as a solid solution, nor a fair & automated one. I was under the impression this hyped up space learned from the DAO fiasco but i might be wrong.
There will always be a need for this eventual "please roll back or block the bad actors". And more money you put into the game more it will be demanded when someone gets hurt.
I don't like crypto but this way of fixing things is pretty normal and standard in software and orher industries also. You simply can run into situations which weren't planned. So i don't think there is a problem with these fixes
It's normal in most industries, but it also defeats the main selling point of crypto - "code is law" doesn't actually work, you always end up in a world of humans and politics.
What's to stop these actions being taken for reasons other than theft?
And relying on external authorities is a good thing actually. Because it's way way more effective than software solutions. Now of course the external authority can compromise sometimes but for this we also already have solutions for like thousands of years - diversification. If people just would learn not to put all their eggs into pne basket and expect eventual compromise that wouldn't be a problem. I think some 101 finances and practical real world problem solutions classes or something like this would get us way further than decentralisig everything with software
If you think it through you simply can not rely 100% on anything humans build. But still societies as a whole thrive and human progress is real.
DeFi is no exception. It’s designed to make banking cheaper. But it’s new technology and will take some time to mature.
Personally, I believe banks won’t exist in the traditional sense anymore 20 years in the future if you like it or don’t. I mean, I love steam locomotives but I don’t expect them to be a common means of transportation ever again. ;-)
A bug in a DeFi contract? Sorry nothing we can do! Bug in Wells Fargo account settlement code? Ah we’re sorry, let’s roll that back for ya!
You can also use variables to store addresses to other contracts and call external methods indirectly using these pointer like structures. If I understood the bug correctly, the hacker was able to modify such a pointer and redirect all transactions to a wallet contract she controlled.
So this is how you can upgrade contracts: There is the „implementation contract“ pattern. Basically, you define a user-facing proxy contract defining the interface but all it does is delegate user calls to the actual implementation contract by maintaining a variable pointing to it. Using a privileged call you can update that address even after deploying the proxy.
Formal verification
Once all this is done, the transaction fees will be equal or higher than traditional banking systems :-p
As the growth slows down there will be an increased focus on best practices for smart contracts, on auditing, and on formal verification. There are also a lot of startups that are looking into insurance for smart contracts and crypto balances in general.
In general, the best experts in the space could probably write smart contracts with >100x fewer bugs than your typical smart contract. Especially with something as complex as the EVM it's difficult to assert that any piece of software is truly bug-free, but there are a lot of steps that can be taken to make them significantly more rare. It's just that these mitigating steps are more expensive than the growth at this time.
The second one is that the more money, the more incentives to hack. And given that transactions are irreversible, you only need each bug once, you don't care that it's fixed later. So if a bug can report a hacker millions of dollars, there's going to be quite a lot of hackers researching, probably with more effort there than the effort put in best practices, audit and formal verification.
The problem of buggy software will continue to exist for new smart contracts that are introduced and manage to capture value quickly, but as the ecosystem matures and more niches are filled, new code will be less likely to attract large numbers of users, so the scope and impact of any bugs in that code will be much less.
Eventually an equilibrium will be reached whereby survival of the fittest ensures that the smart contracts most people rely upon can be trusted. Effectively, some smart contracts will build brand value, and people will be able to rely on the reputations of these smart contracts. Some people may take a risk on a new smart contract and loose (or win), but most people who follow the heard will not have a problem.
It is also important that scrutiny be applied to these protocols, and I imagine that at some point DeFi protocols may be be subject to regulator audit and approval before they are opened up and made available for use by retail customers. If the right people pay enough attention to the implementation of these protocols, then it should be possible to trust them. Also, if you yourself are risking significant funds, it wouldn't be a bad idea to personally review and understand the smart contract code.
That being said, over extended periods of time (decades), long-lived smart contracts will tend to be safer, and insecure smart contracts will tend to be identified as such. If enough value is at risk, and if enough time has passed, then it is extremely unlikely that an exploitable bug will exist that has not already been exploited.
Keep in mind that as a general rule smart contract implementations are immutable, so any bug that exists within a protocol is typically a bug introduced to the protocol when it is first deployed. There are never any "new" bugs that are introduced to an existing smart contract; if a bug emerges after a long period of time has passed, it is a bug that existed at the beginning but had not been previously identified.
At a certain point the passage of time will have reduced this risk below a tolerable threshold that is more than outweighed by the value that people get from using the software. So in practical terms, in the aggregate, such long-lived systems could reasonably be treated as secure.
I don't get the appeal for irreversibility. A legitimate trade always occurs between willing partners, why would you be so afraid that the transaction would be cancelled?
The only legitimate use that comes to my mind are complex financial instruments where things mostly happens with an assumption that the underlaying assets are very well defined, so you want assets be stable.
Is there a company or cryptocurrencies focusing on solving the human part in the transactions? Huge part of the value with working in traditional systems is their resiliency against human errors. Sometimes mistakes happen(a faulty system, a design bug or straight out human error and people who are trying to take advantage of those), most of the time these are correctable.
The transaction will likely be for goods, services and/or money. If one or more parties don't provide said goods, services or money then the other parties may well want the transaction cancelled. That's different from them all being willing to transact in the first place.
That's not a justification for irreveribility. The opposite in fact. But if you were planning on screwing your customer, say, the irreversibility is a bonus.
Charge back fraud (also called friendly fraud) is a big problem in commerce, where the buyer will buy something, receive it and then cancel the payment. The merchant will often have to swallow the cost.
That's actually why credit cards come with protection against fraudulent merchants and you need a good enough credit score to actually get a credit card. On top of that, payment processors run fraud detection systems that block suspicious actions.
Irreversibility turns the trade into a competition over who is the better fraud. The only thing that the crypto guarantees is that the winner keeps the prize.
I think it's more complicated than that. It moves the fraud risk to one specific spot (the consumer) which VASTLY simplifies the checkout process + the costs associated with online purchasing. Right now online payments are a giant mess - every single merchant has to implement anti-"fraud" tools to try and ascertain the identity of the consumer and determine if it matches the owner of the card.
As a consumer, I would happily take this trade for lower prices.
Payment processing just isn't the same thing as a currency. It's like expecting the dollar bill to do payment processing. Is lightning network supposed to be that fancy decentralized payment processing platform that is going to kill credit cards or will people stick with visa and mastercard?
It makes sense if you have a small group of trusted entities that want to have a ledger between themselves (like inter-bank ledgers for various purposes) but if you have somebody in the middle handling disputes... don't you just have paypal? Then cryptocurrency is just an extra complicated step that doesn't really matter.
A strong example of where the irreversibility of crypto is very useful is in the online sale of expensive electronic goods. Especially for things like speakers, TVs, and projectors, fraud rates are extremely high and boutique shops struggle to effectively support online customers, because such a large percentage of their sales get chargebacks after they've shipped the goods.
If you accept crypto, you have a 100% guarantee that when the money has hit your wallet, the money is good and will stay in your wallet. You don't need to deal with an anti-fraud firm, you don't need to check whether this person is trying to have the goods shipped to a sketchy country, and you don't need to fear that your $6,000 item is going to sail away from you without payment.
Yes, this means that the consumer has to fully trust the merchant, but in the case of online sales, the merchant is the known quantity with a reputation. Every consumer is a random, unknown person to the merchant and so it's much harder (and therefore more expensive) for the merchant to establish trustworthyness.
This is absolutely not true. There’s plenty of risk buying expensive goods online, lots of problematic merchants. I don’t understand why merchants are inherently more trustworthy than customers?
The merchant has much less to go on. There aren't review websites detailing the reputation and history of every random buyer that enters a credit card onto your website.
What does that mean?
The phrase "high resale value merchandise" sounds like it refers to the stuff that, in physical stores, is kept in a locked case so you have to ask someone to open it.
But that stuff is readily available online, isn't it?
I assume that most chargebacks happen for purchases made with stolen credit cards. So the chargeback just returns the money to the rightful owner.
If the consumer used bitcoin, and someone stole their credentials to buy something, then they would have no way to get their money back.
Yes, they become possible at the cost of putting the counterparty risk onto the consumer, but that's better than the sale being entirely non-viable.
Especially when the risk of customers committing fraud is incredibly low. Why would you start with an assumption that this is something so rampant it needs to be solved in a way that harms literally all honest customers?
If you think fraud rates are extremely low, you've never tried to sell $2,000 electronics online as a boutique electronics store.
Bitcoin was the only option.
Regardless, how does Bitcoin solve this? There’s a lot of illegitimate users of crypto, how are you solving fraud with irreversible transactions?
It's difficult to find sources, but generally speaking you are going to go 'on warning' at around 1.5% and if you go too much over 2% chargeback rate you just get dropped by the credit card company as a customer. Credit card companies don't like dealing with high fraud customers and won't support you.
https://chargeback.com/average-chargeback-rates-how-does-you... https://chargebacks911.com/chargeback-rate/
Bitcoin helps in two ways. The first is that it gives you a way to accept money at all. As stated above, if your chargeback rate is above 2% for any extended period of time, all of your payment processors - including your banks - are going to drop you as a customer. You may be willing to pay 5% overheads for a higher chargeback rate, but your credit card company doesn't want that as a statistic and they just won't support you.
The other way Bitcoin helps is that once your wallet (use BTCPay) says "2 confirmations" you've got a 99.97% guarantee that the money is yours and won't be reverted. And that's true whether you are receiving $2,000 or $2,000,000. Regardless of whether that money came from "an illegitimate user", you as the merchant can be confident shipping hardware out because you know that the payment is not going to be clawed back.
Merchants are in a much better position to price this in than consumers. Merchants structurally execute a lot more transactions within a market vertical than consumers ever do.
If the merchant can't do that, because deals are simply too high value or aren't frequent enough, then insurance companies or intermediaries (e.g. payment processors) can pool risk across merchants, using actuarial techniques to assign a price to the insurance. For example, professional indemnity insurance for property transactions.
To counteract this negative feedback loop, assuming the increased prices don't drive away all of your real customers, you can spend the increase on transaction analysis, and turn away customers based on their likelihood of fraud, so you've added inefficiency into the system to help deal with a criminal element, and also likely turned away real sales due to false positives in your analysis.
It's no surprise that these types of merchants are looking for a disruptive technology to remove this inefficiency. Doing so would allow them to charge less and outcompete as well as capture the entire market of people marked as false positives by other merchants.
Completely true. Irreversibility and lack of consumer protections might just about fly for small transactions with pocket change which people on both sides of the transaction don't mind losing, but isn't going to be acceptable to most people for larger transactions. If I'm buying a house, for example, I don't want the risk of it being stolen because of an unfixable bug in a smart contract, or sold to the wrong person by an irreversible mistake entering the address. Scaling up further, if you look at the back office for any investment bank, a big chunk of people power is spend on trade reconciliation and essentially fixing human errors - this is a good thing for both parties making such transactions.
On the other hand, stocks are more susceptible to demographic collapse; for example, if a lot of shareholders die and all their relatives inherit their stocks, you can expect a selloff to occur which could crash the stock price. With stocks, shares are never lost forever; they just get passed down to an increasing number of increasingly lazy and incompetent heirs. That's not to say that cryptocurrencies cannot be passed down (they can) but the fact that they are tied to a secret passphrase (instead of the legal system) makes it more likely that they can get lost. The negative economic effects of wealth inheritance are not as strong in crypto space.
The idea that negligent people may lose their tokens is highly meritocratic as it transfers wealth from negligent people to careful people.
These errors are correctable if the counter-parties trust each other, or at least have a relationship that they don't want to undermine by being petty.
Immutable blockchain systems are valuable in part because they allow entities to transact with each other even if they don't trust each other at all, don't know each other at all, or are even antagonistic with each other. Yes, if something goes wrong, a transaction won't be reversed, but without the blockchain these potentially antagonistic entities wouldn't have the capacity to do business with each other in the first place.
Blockchains allow these entities capture the value of transacting with each other—value that wouldn't otherwise be realized—at the expense of irreversibility.
You can potentially imagine that if antagonistic entities tried to do business in a more malleable environment, a request to reverse an error by one entity might not be honored by the other entity, or one entity might maliciously attempt to reverse a transaction that was not performed in error, but was simply disadvantageous in hindsight.
The possibility that a transaction may need to be reversed—or that a reversal request may need to be litigated—increases transaction costs, especially when counter parties are antagonistic. The certainty of irreversibility creates a context by which certain entities are willing to do business with each other, when they might not otherwise do business at all.
Yes - so far, it worked well for extortion with ransomware but is that something that we want to have? Can you think of a legit business case where the merchant providing the promised service is guaranteed and all you need is a method to receive the payment? All that when the merchant and the buyer don't trust each other at all and on't have a conflict resolution mechanism. What do they trade exactly?
If you start with irreversible payments and you need payments to be reversible with some kind of review/appeal process you can add reversibility through escrow. The classic arrangement is a 2-of-3 multi-key system where the payment is made to an escrow address where it can be either finalized or refunded only when at least two key holders concur; the third key, held by a neutral third party, is used to settle disputes when the payer and payee cannot come to an agreement on their own.
There are, however, situation were reversible payments are a liability, and there is no way to build an irreversible payment system on top of a reversible one. For example, you can't build a reliable escrow system on top of reversible payments since the payer can trivially circumvent the escrow by unilaterally revoking their payment to the escrow account.
Who thought an amazing new P2P invention would improve the image of normal money and traditional banks?
Shady stuff that happens in the banking system usually happens behind the closed doors and we don't hear about it for years, if ever. Crypto/DeFi is new and exciting - it gets a lot of attention from press. It is still way easier for me to trust code than to trust people. Call it a character trait / flaw if you want.
"Exciting" or not.
Either I want something to match, in which case check it all, or I don't care if it matches, in which case don't check at all.
Why would you ever check 4 bytes?
To me it smells like a way to prevent fuzzers stumbling on a deliberate loophole.
Someone starts a blockchain company and hires a bunch of devs who make, idk, $40 to $100 per hour to build the thing. Maybe more, it doesn't really matter. Even just one dev or a few devs can make all the contracts needed for this.
One day that dev notices a vulnerability in the smart contract he's writing! He has two choices: (a) patch the vulnerability, which will get him a pat on the back, or (b) convince himself he didn't notice anything, quit his job, wait a month, go to a coffee shop with a hoodie on, boot into whonix, connect to the internet with a 4g dongle, run a few lines of code, and get $600 million dollars.
Most people would choose (a)! And law enforcement is a thing! But a lot of people will choose (b), and if they do a merely decent job they will get away with it, and 600 million dollars is stolen®.
Actually, it's worse than that, because unlike normal banks, the code used by these digital banks is open source, and anyone in the world can go bug hunting.
And the bug wasn't really obvious, although the lack of input sanitation is something an auditor (given enough time) would probably point out.
Regardless, this quote from your link stands out: “it should never be expected that 100% of the deployed code has been formally audited.”
The audits of this protocol is also continuous.
Also, they specifically state that not everything is audited? Nowhere do they mention continuous audits.
Uniswap: https://uniswap.org/audit.html
Sushi Swap: https://github.com/peckshield/publications/blob/master/audit...
Alpaca Finance (high complexity in my opinion): https://docs.alpacafinance.org/transparency
A lot of projects provide their source and you can verify that what you're interacting with matches the source.
The hilarious thing is nearly all of these high profile hacks happen even after being audited.
There was one company I remember being called out as a suspect, but I can't find the name.
Also given (a) anonymity (b) ability to take cover amid so many other hacks, you could do this for a few years, slow down, and remain a top tier firm claiming the lowest hack rate.
https://rekt.news/deathbed-confessions-c3pr/
I think proper DeFi company should have their own system on deploying contracts. Further, they should have their own security team that audit everything.
An argument that open source is less secure, and on Hacker News! Now I've seen it all.
Military cryptographic systems, IBM mainframes, and many other products use this approach as a layer in their security framework and it is actually pretty successful.
If I asked you to break into the a PFSense box you could just Google "PFSense version X.X.X CVEs" and you would probably get a way in if the box was enough out of date, but if you tried to find the same thing for something like the General Dynamics TACLANE you would have a hard time even finding where to start.
Humans might be motivated to sit on a bug until they can reach the cybercafe. Bots, not so much.
More than that, there's a minority perspective in DeFi that the code is the law. If the code allows it (e.g., withdrawals under an unintended circumstance), it's therefore legal. If it were illegal, the code wouldn't allow it.
With crypto all it takes is one piece of malicious software, or to fall for a single phishing email, and you've lost everything.
[0] https://www.zdnet.com/article/bitcoin-wallet-trick-has-nette...
Think again. In the wild wild west that is cryptocurrency the first thing people assume is an inside job.
People with a lot of money and a cut-throat ethic will send death threats to your front door merely for small bugs you accidentally commited to github or for a governance dispute on a forum where you posted pseudonymously.
If you dare steal money as an insider you had better make sure you know how to use it to quickly get high-end personal security for you, your family, and friends. This of course simultaneously outs you as guilty.
Any hack occurs and you are immediately woken up in the middle of the night to be interrogated by people you've never seen before let alone heard of, stomping through your apartment. Your life becomes a movie.
Angry vicious actors with few scruples and long memories will loudly and expensively hunt for you for the rest of your life so you can make them whole. LEOs aren't even your biggest concern at that point.
Being an insider or former insider after a large hack sucks whether or not you're guilty.
Never trust user input.
I don’t like loss or theft ,obviously, but I have to think if regular IT/apps/software/networks etc.. had this big of a material threat, we would see far more secure systems and organizations.
So it would reason that as block chains and crypto eat the world they will raise the bar.
Am I thinking about this right?
> By sending this cross-chain message, the user could trick the EthCrossChainManager into calling the EthCrossChainData contract, passing the onlyOwner check. Now the user just had to craft the right data to be able to trigger the function that changes the public keys.
Could this bug have been avoided by extra safety features in the language used to write the contracts like a better type system? Or the code wasn't using all the language features it could? I found the cause of the bug hard to understand to be honest.
I always feel like we're making mistakes that tangential areas of software engineering must have already solved. I guess devs tend to also not like math or writing proofs either, which is ironic given this is "crypto" lol.
A few years back I wrote https://medium.com/coinmonks/lashing-out-at-a-spank-channel-... about a similar hack where a contract "trusted" a given (user input) contract based on nothing other than verifying a function signature. This latest hack was smarter but ultimately it still exploited a 4 bytes hash "security" feature...
Full stop; I’m stuck here. Why does it need to do this?