web3isgoing

Open source, public and permissionless infrastructure for the web. Very different than Venmo which is owned by PayPal and limited to USA, and not programmable, no interop.

about the OP’s thread: centralized services like PayPal, Venmo and Stripe can close your account. Nobody can close your private key, even if you are on a L2 for fast payments you can use the escape hatch to withdraw without possibility of censorship.

Venmo[1] does not have reversibility. Cash does not have reversibility.

If users really wanted credit card functionality at the expense of its costs, you could build that as a layer on top, without forcing everybody in the system to use it.

And consider, most disputes is not just about the quality of a product. That is handled with regular refunds. Credit card disputes are a lot of times because of fraud or card skimming, which is very often because the system is not very secure to begin with. Secure cryptography can remove a lot of this type of fraud.

[1] https://help.venmo.com/hc/en-us/articles/235171088-Cancel-Pa....

Yes, if the application and its users demand it. Reversibility is possible in peer-to-peer and decentralized payment systems. But not every app needs reversibility and the centralized intermediaries that come with that.

ZK rollup with validity proofs and trustless escape hatches should really be the dominant mode of bridging and storing assets in the future.[1]

To the OP: sorry to hear what you are going through.

[1] See https://vitalik.ca/general/2021/01/05/rollup.html and https://vitalik.ca/general/2022/11/19/proof_of_solvency.html

For some users and use cases, they are.

Your analogy makes no sense.

There are many users who just want to hold crypto and perform basic lending and exchanges, and would be willing to spend fractionally more in gas fees to achieve this with higher security guarantees.

Everybody at Barber CEX got a surprise head shaving the other week, meanwhile Barber DEX is still cutting people's hair normally even though it is more expensive and harder to find.

DeFi never claims to provide the exact same fiat and off-chain services as CeFi and CEX. It has specific goals, like replacing custody with non-custody, or replacing a centralized exchange with an automated market maker that no single party can control.

This has different risks and trade-offs, obviously, but users who opted for Uniswap instead of FTX as their crypto exchange are probably pretty happy with their decision.

The goals of DeFi and web3 is to create structures that do not rely on centralized service providers, and are able to resist control of single bad actors and provide certain clear and transparent security guarantees. In that they have so far succeeded.

I wouldn’t call it victory yet. We still have years of figuring out which blockchain, DEX and DeFi models work and which will fail, most of this new tech is only a couple years into development. But the long term 10+ year vision seems clearer.

Isn’t that the point? The protocols are built to resist changes by single entities and continue working as expected, handling user deposits non custodially, regardless of market activity. HN can declare a dozen crypto deaths with each new CEX and Uniswap will just keep filling orders for whoever is sending value through it.

The irony of this post criticizing DeFi and blockchain in the wake of FTX is that those decentralized applications are working just fine in this downturn. Aave and Uniswap aren’t failing, they are thriving.

> So are blockchains. However, blockchains are much harder to secure, since they need to preserve the order of the ledger (for Bitcoin that's a total-order; there are some chains which only require partial-order). That forces all transactions to jump through hoops, like proof-of-X; even if they're not under attack.

This hardness is what makes them tamper proof, and more resistant to sybil and eclipse attacks than a DHT.

> why impose a log (and hence a total-order of events)?

To quote my linked post:

>> Vitalik, or maybe a charitable non profit organization, signs two PDFs: one says "our new public key is X" and the other says "our new public key is Y." Both of these documents verify correctly, but how do you know which is the latest? One approach is to use Twitter as your append-only timestamped ledger, and broadcast a link to the latest file on IPFS. Another is to build a new centralized service and promise it is secure and will not get hacked or mutated. Another is to rely on a public distributed ledger that is verifiably secure and strongly resistant to modification.

> That's a heck of a hypothetical; and it's solvable without baking order-dependence into everything, e.g. we can embed the hash of one document inside another document; or we can provide hashes-of-hashes (Merkle trees), etc.

Key rotation, financial statements, exchange of assets, loans and borrowing, social messaging interactions, many things in our world are order and time dependent.

Using hashes-of-hashes as you suggest does create an order, but without the distributed consensus mechanism. If there is a fork split, like two key rotation documents both signed by vitalik.eth pointing to two different new addresses and creating two independent chain of hashes, how does the system know which new chain is correct?

To solve this you might store the chain of messages in an append only ledger, like posting on centralized Twittter, or posting on a decentralized blockchain. This is where the original conversation started from: what if instead of having a single centralized and mutable ledger to store these signed messages like keybase.io, you build on top of a decentralized and immutable ledger. Private versus public infra.

If you look at crypto's daily price action, the majority of it is attributable to trading and speculation. I think this is pretty common knowledge.

If you feel stocks and equities is gambling, then you might also feel that this sector of crypto is gambling.

But there are other sectors of crypto that don't register on this price graph, maybe because price is not the only metric of their success, or because their volume is lower. Smart contracts, non custodial wallets, ENS, trustless payments, DEXes like Uniswap, are all interesting and valid use cases of crypto and blockchain tech.

One failure of FTX and BlockFi is that users had no way to ensure that the centralized custodian was not running off with their on-chain deposits by directing them into unsound deposits. Vitalik is suggesting a cryptographic mechanism here that would provide better transparency as to on-chain activity of a CEX.

Day traders want to trade, no matter how much you try to tell them their trades are fictional or "have no use cases."

Partly UX, partly marketing, partly L1 fees and speed. Partly that a lot of people don’t know what Uniswap is. It gets a passing mention in the news if lucky, or more likely no mention, even though it’s the second largest crypto exchange on some days. Most crypto CEX investors are either unaware or too lazy to care.

A lot of crypto people do use Uniswap. The tone of Vitalik’s post is: what if we took some of the non custodial, on-chain, cryptographic proof things that work well in a DEX, and inject them into more CEXes so that even lazy users end up with better security guarantees.

Fiat assets was addressed in the post.

Stablecoins can be used to avoid price volatility, and work within the framework Vitalik is suggesting.

This math is not for end users of an exchange, it’s for developers and researchers building new exchanges. The UX does not need to feel that different than any regular app.

A lot of people like trading, just look at Robinhood. It would be good if an app like Robinhood existed that ensured cryptographic guardrails to prevent the platform owners from lying about their solvency.

Verifiable computation. See Pinnochio and RISC Zero.

https://eprint.iacr.org/2013/279.pdf

https://www.risczero.com/

Vitalik isn’t running any DEXes, he is not in a position where he can steal or move user funds locked into a DeFi contract. He could suggest a change that might do something malicious at protocol level, but the rest of the developer community would reject it.

I can’t think of anything else that China is attempting to restrict that the rest of the developed world is open to.

Edit: perhaps need a /s tag here.

Depends where you live. Most developed countries are moving away from cash. Some already have.

And how do you plan to host and distribute that? If not GitHub, maybe your own site, but neither is tamper proof or verifiably secure. In both cases the repo owner can delete commits and rewrite history, and viewers would not know. There needs to be some way to come to consensus about which SHA-1 head is valid. In a website, it is just whatever the website tells you is the correct chain. For it to be verifiably tamper proof you would need a consensus mechanism, which would spawn a blockchain.

Succinctness means the proof size is smaller than the witness, and that it can be verified quickly. So your proof size and verification time can remain small even with large inputs. Succinctness and SNARK is the basis for practical verifiable computation systems like Pinocchio[1], early applications like Zerocoin, and now is the basis for scaling blockchains with ZK rollups.

See for yourself[2]. Much of the recent developments of practical ZKP stems from SNARK. In the last few years there has been an explosion of new papers and tools around this - lots of it driven by blockchain and in some cases directly funded by it.

[1] https://eprint.iacr.org/2013/279.pdf

[2] https://en.wikipedia.org/wiki/Zero-knowledge_proof#Zero-Know...

A document is not a ledger. The blockchain is the distribution mechanism.

The problem I outline is not about a physical to digital link. It is essentially about decentralization and using a tamper proof append-only log to store key events and signatures.

Storing commits on GitHub is neither of those things; data is owned by a single company in the US, and previously published logs can be deleted to recreate a false history.

As I understand, DHT is vulnerable to sybil and eclipse attacks, and not really suited to the task of creating a tamper proof log. If the log and timestamping is not tamper proof, key rotations can be spoofed. Users in the network may need to come to consensus about the ordering of events, such as if signed documents A and B are order dependent. See:

https://news.ycombinator.com/item?id=33639578

Simpler than DHT is just a server hosted in the US somewhere, like what keybase.io is doing, but that goes against my goal of decentralization.

I don't think redundancy is a clean solve. It might give more confidence to the message time stamp to see the same message replicated across 10 different websites, but this does not scale. Eventually if you do aim for a distributed database you end up down the path of consensus mechanisms and blockchains.

What I outlined is unlikely to ever be realistic on a L1, but recursive zk rollups that post proofs to L1 do scale very well and have strong security and tamper-proof guarantees.

ZK is old tech but succinct, non-interactive and general purpose ZK is not. Look at SNARK and STARK, and every other research and advancement in the last 5 years. Funded by blockchain, developed for blockchain, with hash functions optimized for use in a blockchain. This modern form of ZK underpins most new blockchain bridges, light clients, and scalability solutions.

These new ZK proofs are much different than anything in the last decades, and can be used without a blockchain. But they also do fit elegantly within the context of blockchains, like having a ZKP verifier running on EVM instead of a single website like keybase.io, to further reduce points of centralization.

In this example it is key rotation, but you do not know when your key will expire, so you cannot put that in the message. Imagine you have a key, and later realize it may or may not be compromised, so you decide to rotate.

You can be in the habit of writing "I signed this message at date K" but if any of your old keys are compromised, the hacker can sign a new message with today's date to spoof a new rotation event. Without ordering these events by time, you cannot know which is the newest.

One solution is to have a log showing the timestamped key rotations. A company can store everybody's timestamped key rotations on a sqlite database and promise it won't ever be modified, or you can put these state changes in a distributed ledger. If the value of the key rotation events outweighs the cost of submitting transactions to the ledger, it may be worth it. This is unrealistic with Eth L1 but more realistic in something like a recursive zk rollup on L2.

Vitalik, or maybe a charitable non profit organization, signs two PDFs: one says "our new public key is X" and the other says "our new public key is Y." Both of these documents verify correctly, but how do you know which is the latest? One approach is to use Twitter as your append-only timestamped ledger, and broadcast a link to the latest file on IPFS. Another is to build a new centralized service and promise it is secure and will not get hacked or mutated. Another is to rely on a public distributed ledger that is verifiably secure and strongly resistant to modification.