Hacker News Reader

> Weird that it would be a boon for both forensic accountants and fraudsters. How do you reconcile that sentence?

It is very common to track people by the tokens they hold and target them for theft and fraud.

One example is to airdrop a backdoored token, and when the user tries to move it they wind up authorizing movement of their other valuable tokens. Or to just use the airdrop to lead a curious user to the airdrop event's website, which is then a phishing campaign that achieves the same result.

Tracking partial identity through tokens is actually a very common concept amongst the newer blockchain platforms which also have addressed such topics as the drawback you describe. While said attack is theoretically possible it only is applicable to tokens managed by the same contract and only on platforms which do manifest tokens as script state (think erc20). Platforms with native assets (Cardano and some others) are immune to such attacks.

where can I learn more about that approach? I just assumed the eUTXO model would be more like the UTXO model where assets could still be tracked to a single address, like with the old Counterparty or OMNI model in Bitcoin.

What would you consider Solana's approach to assets? I was surprised to find that each address has another unique address for its balance and possession of any asset issued on that network.

The key is not in eUTXO (allthough eUTXO is a great piece of work, especially because it solves a multitude of scaling issues in the long run), it is in the ledger's capability of handling custom assets natively. This way a wallet exactly shows you which tokens you own are affected by a contract invocation.

I don't know how solana handles assets but I personally stay clear from that ecosystem. Too much VC hype for my likes and way too little decentralization of funds.

Looking at the token standards[1], I can't see how you could create a "backdoored token" that would authorize movement of other tokens but that sounds like a scary threat vector. Could you explain how that would work please?

I've heard about ERC20 tokens that allowed the issuer to pull them back (that's the SoarCoin thing[2]) but not a token that allowed other tokens to be transferred.

[1] https://eips.ethereum.org/EIPS/eip-721 https://eips.ethereum.org/EIPS/eip-998 https://eips.ethereum.org/EIPS/eip-1155 [2] https://iterative.capital/erc20-backdoor-allows-you-to-steal...

The standards only really define what should be done at the interface or what the function inputs and outputs should be, but don't really define the internals of the functions. For example inside of a malicious approve function call, you could hardcode a list of popular addresses that also approved those tokens if the msg.sender is holding (balanceOf calls) them and even potentially then have transfer functions calls inside of the approve function call for the malicious token.

For me, its only scary if one regularly interacts with tokens they haven't bothered to look up for the source code for. People really shouldn't be interacting with contracts if their first time hearing of it is from looking at who randomly airdropped them a token with a domain name in it. But hey, people regularly do stuff in crypto that i just think "wtf arw the thinking", so w/e.

Both of you are wrong. ZK fundamentally does not allow to hide the rules (the code). It only allows to hide particular executions. So yes, while you can have an ERC20 interface and some censorious garbage inside (I look at you, USDC), you can't hide that fact from observers.

The issue is that there are people blindly interacting with malicious contracts, which is more of a social problem and not a technical one. There are people now who for example, don't approve random token addrs that they haven't decompiled or which had the source available… i know, shocking…

Did you respond to the right chain of comments, none of us mentioned anything related to ZK solutions (chains line mina or rollups or otherwise)?

"It's not safe to use web3 unless you're comfortable analyzing decompiled source code" is a super good sign for the future of the ecosystem.

> "It's not safe to use web3 unless you're comfortable analyzing decompiled source code" is a super good sign for the future of the ecosystem.

Plenty of people don't de-compile or read the source, don't engage with random tokens credited to their address, and the ecosystem around using "smart" contracts has grown since 2015. Not my problem if people want to use/trust something else (others audits for example) without putting in any work to learn/observe themselves and engage with random stuff. That's their problem, not mine. Some learn better after going through school of hard knocks anyways.

As a society, we have expected more and more people to learn how to read and write for basic literacy over hundreds of years. Those who know how to read and write code will have a leg up for that expanding literacy set for engaging with digital things and those who don't will be left behind esp as more aspects of life are governed/mediated through code and this goes beyond the whatever is being branded as "web3".

If you don't wanna use it, you are free not to (unless in the case someone hacks your devices from across the world, you don't engage in backups, and the only way to unlock it is to buy some tokens to pay them off; then its just hard choices to make).

> As a society, we have expected more and more people to learn how to read and write for basic literacy over hundreds of years. Those who know how to read and write code will have a leg up for that expanding literacy set for engaging with digital things and those who don't will be left behind esp as more aspects of life are governed/mediated through code and this goes beyond the whatever is being branded as "web3".

We have. We've also extended protections for people lagging behind, for example by putting restrictions on what kinds of contracts can legally be entered into and voiding contracts that one party could not have reasonably been expected to understand, or entered into under duress or undue influence.

None of these protections exist under "smart" contracts, which is exactly why we can't and won't allow code to govern or mediate life as web3 envisions. Your dystopian vision of "oops, you lost your retirement savings because you didn't decompile that contract before interacting with it, too bad", or "oops, you lost your retirement savings because someone beat your wife with a baseball bat until you handed over your private key, sucks to be you"--in short, the dystopia of "code is law"--flies in the face of thousands of years of jurisprudence and civilization. Once the goldrush hype wears off people will realize how heinous the fundamental idea is and dump it in the gutter of history where it belongs.

> We've also extended protections for people lagging behind, for example by putting restrictions on what kinds of contracts can legally be entered into and voiding contracts that one party could not have reasonably been expected to understand, or entered into under duress or undue influence.

And are constantly bypassed in practice by those with more resources than others wrt engaging with the various legal systems (or corruption thereof) around the world.

> None of these protections exist under "smart" contracts

Not true, some people buy off chain legal insurance for a particular juridiction and only deal with protocols they have some legal recourse over. Some use multisig accounts with trusted parties.

> which is exactly why we can't and won't allow code to govern or mediate life as web3 envisions.

There is no shared we though, some individuals (and governments) will adapt to it, some wont, some contracts/cryptocurrencies will survive, some wont, and people will make the convenience trade-offs like they always have had as things change. If you are only willing to try to force someone else to do your dirty work of imposing on peoples freedoms, you'll be behind those who are willing to put you in the ground themselves to defend such irrespective of any particular jurisdictions laws.

> Your dystopian vision of "oops, you lost your retirement savings because you didn't decompile that contract before interacting with it, too bad", or "oops, you lost your retirement savings because someone beat your wife with a baseball bat until you handed over your private key, sucks to be you"--in short, the dystopia of "code is law"--flies in the face of thousands of years of jurisprudence and civilization.

Bad things will continue to happen to some people even with out smart contracts or cryptocurrencies (bad things which don't happen to most people in the course of their lifetime btw), but if you want to live your life in fear as an excuse to not learn and adapt in face of bad things that may happen, that's on you.

> Once the goldrush hype wears off people will realize how heinous the fundamental idea is and dump it in the gutter of history where it belongs.

Yeah, like when people stop being motivated by greed, like when central banks and governments stop debasing their currencies like they have through out history, like when large private banks and service providers stop blocking people from using their platforms, etc. Could happen, I'm not holding my breath.

You can easily overload the transfer() method with approvals of an array of token contract addresses and the subsequent transfers

Its not really a technical problem its a user got phished problem

It's a technical problem in that this shows the the VM for smart contracts is a mess. It should not be so easy to do such things.

Okay, if that’s what you want to see

To me it shows that the user experience for wallets doesn’t catch up

Or that the standard classes for tokens leaves more to be desired, there are competing standards

the VM never asked anyone to make token classes and it is phenomenal that people made those classes

Consumer protection can come in other parts of the stack

> One example is to airdrop a backdoored token, and when the user tries to move it they wind up authorizing movement of their other valuable tokens.

Do you have an example of where something like this was actually deployed? How would a user moving one token would result in another token being moved?

I can only imagine a situation where a user might be induced to install a compromised wallet, and then to give that wallet keys to the their account. But this is not an attack strategy that depends on there being a "backdoored token" of any kind.

Is there some way to code an ERC20 token that would somehow give you access to a user's other tokens?

To me this is like asking if I have an example of a phishing site, not off the top of my head?

Just embed approval methods for a predefined external token contract address into the transfer() method of the airdropped token

Then you can also chain the transfer within it or you can wait and transfer them all yourself

Doing too much in one transaction will alert more users because the gas price will be unexpectedly large

Ah, am I right that you are referring to something similar to what is discussed in this article?

https://blocksecteam.medium.com/unlimited-approval-in-erc20-...

But is it not the case that the approve() method must be invoked directly by the sender (i.e. by the account that holds the tokens that are the target of the theft)? Wouldn’t the invocation be rejected by the ERC20 token if it is made indirectly, i.e. if the invocation were made from within another method (provided that the target ERC20 token is coded properly)?

> With the recent introduction of zk rollups on Ethereum, it's now possible to have the best of both worlds, in my opinion (see https://aztec.network/index.html). Transactions that need to be private will be conducted on zero-knowledge rollups built for privacy. Mastercard is working on this with Consensys for Ethereum (https://www.coindesk.com/business/2021/12/16/consensys-colla...).

I can’t find any real technical documentation on this system but from what I understand about ethereum, this kind of use case effectively needs to be run off the main ethereum blockchain?

I just don’t understand what the purpose of the blockchain really is when most of the interesting ways to scale add features rely on processing transactions OFF the chain.

This is a misunderstanding. The goal of cryptocurrencies is not to process transactions. The goal is to order transactions. The order is the hard part. (Notice that if I have one ETH, and I submit a transaction to send alice an ETH and to send Bob an ETH, alice and bob are both very interested in the order - only one transaction can go through, and which one is determined by which one comes first in the chain).

Fundamentally the order doesn’t really matter, as long as it doesn’t change retroactively. Once you have agreement on the order, anyone can process the transactions and know they’ll get the same final result as anyone else.

I’m not sure about this specific one, but most “rollup”s use the main chain for agreement on the order, and then outsource the actual processing to someone outside the chain. Some use cryptography from verifiable computing, so the off-chain person can also submit a proof that their processing is right and there’s no possibility of fraud. (the proof can then be verified extremely quickly.)

I think the point regarding centralization is that with the blockchain the ledger is central (assuming a single coin ends up winning) whereas right now we have many different ledgers that may not entirely agree. Including single individuals having their own ledgers.