[web3isgoing]

You would think a message board called "hacker news" would be more open to blue sky thinking. Zero knowledge proofs and a tamper proof ledger of timestamped cryptographic signatures could open up new use cases that are different than relying on central authorities.

One idea, document signing: vitalik.eth signs a PDF, everybody can verify the PDF is signed by his private key. He has to broadcast his public key for this, and probably also a content hash of the document so that we can be sure we are verifying the correct PDF. He can broadcast this on Twitter, but that is not a secure and tamper proof ledger, and it is centrally owned, and it's not a great storage mechanism for this system to scale to thousands or millions of signatures. LibreOffice could create a new service like keybase.io but that is also centralized and we saw how that went. Another alternative is these messages are broadcast through a public and decentralized ledger.

How does this fit with zero knowledge proofs that the blog mentions? There may be signature attestations you can make that you want to be private from the receiver, but made in a way that the receiver can still verify the signature is valid.

EDIT: Since I am on a throwaway account, my replies are being throttled. This could be another application of ZKP: create a proof that my main account has significant karma to post, without sacrificing my privacy.

[piva00]

> You would think a message board called "hacker news" would be more open to blue sky thinking.

And as you can see all over HN, most of us are quite tired of this diatribe...

This appeal to HN requiring us to be open-minded about a technology that had more than a decade to prove itself in a real world application is tiresome. I mentioned in another comment just this week, I was really excited about Bitcoin in 2012 and kept watching the whole space for opportunities to try a product that could improve my life.

Nothing has appeared, in 10 years, worse, in 10 years it all became a space filled with mumbo-jumbo, grifters and scams. In 10 years I've not seen any of these pie-in-the-sky proposals of digital attestation come to fruition.

It's a technology looking for problems, when something more exciting than Cryptokitties or pure speculation of shitcoins pops up I can definitely give it a try. Unfortunately as each day passes and more scams appear it eclipses any dreams that people like you have to sell to me, it's been thoroughly tarnished over 10 years, the space is a mess in every aspect, including information. Nowadays if you search for anything blockchain/cryptocurrency-related you will only find piles and piles of trash, of shit articles trying to peddle yet-another-scam.

It's really hard to keep any optimism when there was absolutely nothing gained from the technology in the real world.

No, remittances from developing countries is not really a gain, I personally know people that emigrated from places like Venezuela and Iran and absolutely no one is using blockchains/cryptocurrencies anymore, the few ones that tried got burnt after yet-another-crash.

A decentralised ledger might have uses, no one has shown any so far, at least none that got any traction even close to the amount of money poured into this bullshit.

[miohtama]

It is incorrect to say nothing has happened during the last 10 years. Zero-knowledge proofs, as discussed in the potential research collaboration between Ethereum Foundation and LibreOffice, are more recent. The most useful, or compact, zero-knowledge proof systems have been created during the last few years. This can be partially contributed to the blockchain research.

You can more about the history of zero knowledge in this Wikipedia article:

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

[pclmulqdq]

Zero-knowledge proofs do not need a blockchain. They are "old crypto" (cryptography, not cryptocurrency) and actually predate blockchains by several decades.

[piva00]

Sensible, I'm gonna wait for real applications of ZKPs though, it's an interesting piece of technology, just like a decentralised ledger. When it gets applied I can form a better opinion if it was worth the US$ billions poured into blockchains that enabled more research of it :)

[sdiacom]

Most of us were very interested in cryptocurrencies at some point in our lives. At some point, we have to accept that things are not what we think they could or should be. They're just what they are.

If I build weapons for freedom fighters, but they're used to massacre civilians, I'm not bravely aiding the people's revolution, I'm just an arms dealer for a terrorist group.

If I build a decentralised cryptographically verified ledger to provide trustable alternatives to traditional banking, but it's used to trick people into spending millions on digital receipts for ugly monkeys, I'm not disrupting the corrupt banking oligarchies, I'm just running an elaborate technological grift.

[brabel]

Ideas like you suggest have been discussed on this forum uncountably many times. Blockchains in general as well, for well over 10 years now.

This stuff may look new and revolutionary to some, but if you've been here long enough you've already seen that stuff go through the hype cycle[1] and it has NOT emerged, at least so far, at the end of that curve looking good.

I am currently working on some stuff where blockchains are actually a potential solution (very related to public key cryptography, by the way), but the problems with it as a solution to anything except digital casinos are so numerous and the scams so prevalent in this space that it's next to impossible to come up with genuinely useful applications and services that rely on it. That's the reason why usages of this technology are currently extremely limited, not because there's some sort of conspiracy to stop it from succeeding!

[1] https://en.wikipedia.org/wiki/Gartner_hype_cycle

[criddell]

I've started to look at blockchains as a solution in search of a problem.

[kuramitropolis]

So was the Internet during the dotcom boom. And now the Internet is part of the problem. The Gartner cycle is an epicycle.

[criddell]

I don't quite get what you mean. The internet was designed and used to connect networks of computers. I started using it for email, gopher, and ftp in 1989 but it was 20 years old at that point.

[kuramitropolis]

I mean the Web.

[Macha]

Hacker News has historically been very open to blockchain ideas. I'd wager that without HN's contribution, it would not have been well known enough to get picked up by silk road which is really when it went from toy project to normal people caring. Even after that, I think many of the early blockchain for X startups got good press here and there is a decent chunk of HNers employed in the blockchain.

So I don't think negative reactions to blockchain articles on HN started as some sort of kneejerk conservatism, rather HN has seen the entire lifecycle of blockchain so far and what we've seen has exhausted the opening goodwill towards the concept for many users

[web3isgoing]

Most of the negative comments on this thread read like knee-jerk reactions. I'd wager that many of them see blockchain as Bitcoin, and they are not cognisant of newer developments like zero knowledge proofs, verifiable computation, and smart contracts running on a zk rollup.

[drdrek]

Zero knowledge proofs have nothing to do with blockchain, verifiable computation has nothing to do with blockchain. You can use Zero Knowledge proof with many things, one of them is blockchain. This inverses the relation of Zero knowledge proof and Blockchain, Its like saying supply chains are an advancement of blockchain. Just because you can do something (poorly) with blockchain does not make it part of blockchain.

This kind of inversion of relations stands in the base of why people with subject matter knowledge are opposing Blockchains/Crypto. Its a tower of badly constructed arguments standing on top of each other.

Private money is not a blockchain advancement, Supply chain management is not a blockchain advancement, Consensus algorithms are not a blockchain advancement... and zero knowledge proofs are not blockchain advancement. Each and every one of this things can be done better not using blockchain.

[web3isgoing]

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.

[drdrek]

"ZK is old tech but succinct, non-interactive and general purpose ZK is not." Do you work on SNARK? this is just their marketing language reiterated.

Zero knowledge proofs do not need to be "small". What kind of ZKP use-case do imagine that cannot bother to send 1kb of additional data? What does any of this have to do with decentralization? Why is decentralization a goal? Do you really believe that most research into ZK cryptography is funded by blockchain?

Try and expand your sources of information, I have a feeling that you are in an internet bubble :(

[web3isgoing]

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...

[pclmulqdq]

Zero knowledge proofs were first invented/described in the 90's. Verifiable computation is older than blockchains and zero-knowledge proofs. Neither of these have anything to do with blockchains.

[q-big]

> You would think a message board called "hacker news" would be more open to blue sky thinking.

On the other hand: a site called "Hacker News" will likely point out business scams involving technology. ;-)

If you desire this openness towards blue sky thinking, we should unmask all those cryptocurrency con men so that the only people who stay in the cryptocurrency ecosystem are those who really are into the mathematics behind it or love blue sky thinking.

[glacambre]

>He has to broadcast his public key for this [...] through a public and decentralized ledger.

Yes, but then he also has to broadcast the transaction linking his identity and public key. He could do this on twitter, but that is not a secure and tamper proof ledger. So he creates a second blockchain to advertise the transaction. But then he needs to advertise the second blockchain's transaction in order to link his identity and public key. He could do this on twitter, but that is not a secure and tamper proof ledger. So he creates a third blockchain to advertise the second transaction...

[pclmulqdq]

Herein lies the problem of linking the chain to the world. At some point, you have to trust someone to do something.

In my opinion, it is fine to publish those signatures on a website you are known to control (or Tweet them out or whatever).

[maccard]

> it is fine to publish those signatures on a website you are known to control (or Tweet them out or whatever).

Say I tweet, post on reddit and internet archive both of those pages. When somenoe goes to verify later on, the 4 values are different to the value you've provided to me. Which of the 5 values is trustworthy? This is the problem that a blockchain verifies, in theory.

Unfortunately, there's two different answers, depending on what we're actually sharing. If we're sharing something that confirms my identity, the only correct answer is "it doesn't matter, you are not who you say you are".

If we're sharing something that proves something happened, the answer is "I need to choose one of the N options to trust", and unfortunately going down this path should leave you to "it doesn't matter, I can't actually verify what happened without trusting _someone_". The reality of both situations is that it doesn't matter whether or not the trust is centralised or not centralised, the action you take in both cases is the same - you stop trusting and look elsewhere. And Blockchains can't solve that problem.

[pclmulqdq]

Like I said to someone else, the real answer is to not sign documents that are wrong. To avoid doing this, you might have to be more precise than "my public key is X." You probably should include a timestamp, an expiration for the key, a hash of the previous message so people can tell what is supposed to supercede what, etc.

That way, if people get multiple messages from you, they can actually verify which one is supposed to be the most recent and what your key actually should be.

That will solve your problems and let you disseminate public keys through Twitter.

[maccard]

> Like I said to someone else, the real answer is to not sign documents that are wrong.

If "don't make mistakes" was a viable solution, we just wouldn't have a whole family of problems.

> you probably should include a timestamp, an expiration for the key, a hash of the previous message so people can tell what is supposed to supercede what, etc.

An expiration for your current key doesn't _really_ help the problem of "I don't know where to get the next key from". A blockchain _in theory_ formalises the "disseminate your public key through this accessible place" (which you've defined as twitter, I might define as a CA registry that comes with browser and someone else might define as a blockchain), but this solution doesn't actually solve the problem of "the public key is different, which one do I use?" which _is_ what a blockchain does, except in reality, it's useless because when these things diverge you almost certainly look elsewhere for trust.

[pclmulqdq]

By the way, this chain of documents with precise information is a blockchain in itself. You don't need another one. Particularly not for disseminating information, where it doesn't really solve any problems. Publish those documents wherever you want, and include the appropriate information so that they are not wrong. That's a blockchain.

I will add that "don't make stupid mistakes" is a key tenet of cryptography in general - and blockchains in specific.

[chippy]

Lets try to understand this central point some more: blue sky thinking is a kind of enthusiastic faith in the future. The same kind of enthusiasm that scams, pumps and dumps require in order to succeed.

Thus we have a call for "just believe in the technology" which on it's own is fine, but it's a call that is required for all the scams that have occurred and keep on occurring to occur.

So people easily confuse the enthusiastic earnestness of blue sky thinking with crypto/blockchain with the enthusiastic earnestness of the fool that is rapidly parted with his money.

(As a note to this, I hope that the current massive crash of crypto happening right now might in a strange way increase the actual number of interesting technologists involved in it somehow, but I've not identified how)

[manholio]

> Another alternative is these messages are broadcast through a public and decentralized ledger.

Trouble is, the "decentralized ledger" can only reliably timestamp if there is a financial incentive that motivates peers to burn hashes, stake and vouch for blocks etc. Without that financial incentive the whole blockchain breaks down to something inferior to even the PKI distributed systems described by Lamport in the 70s and 80s.

That's the major fallacy of "blockchains" as a technology, they are always a disguise for token speculation, they require native minted tokens of speculative value to operate.

[kuramitropolis]

>they require native minted tokens of speculative value to operate.

Well, so does the rest of industry and civilization (fiat money). What's the distinction there?

[manholio]

The distinction is between something that costs money and competes in the maketplace based on that, versus something so insanely expensive the only way it can compete is to pretend it prints actual money and speculate on their future value.

If Bitcoin didn't have bitcoins, nobody in their right mind would pay to an electricity bill the size of Argentina just to keep it running as a distributed timestamping ledger. There is no imaginable practical application that would justify that resource waste.

[SCdF]

idk man, I was open minded on cryptocurrency backed blockchains for a decade, I'm kind of over it now.

Everything you're describing could be done with a git repo (also a cryptographically signed tamperproof ledger), 10x faster and with 1000x less baggage of a deeply scummy industry behind it.

The core problem to solve with your idea is proving that a piece of data that represents someone electronically (eg a public key) truly actually represents them physically. Cryptocurrency backed blockchain solves none of this any more than any other technological solution does, because it does nothing to tackle the actually hard problem, of making that physical->electronic link.

Keybase did it by not truly doing it, and instead providing a plethora of different ways that all somewhat do it, and left it up to the user as to whether they trusted that. So you can link your domain, your twitter, your reddit, your crypto wallet, etc. That still didn't actually prove the physical->electronic link, but it added evidence.

[web3isgoing]

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.

[SCdF]

> Storing commits on GitHub

I said git, not github

> previously published logs can be deleted to recreate a false history.

No it can't, that's the point of git. In git parlance that would be a rebase, which is instantly and unavoidably obvious, and people just wouldn't take anyone's rebases.

[web3isgoing]

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.

[kuramitropolis]

>Keybase did it by not truly doing it,

And got effectively assassinated for it.

[forgotpwd16]

>so that we can be sure we are verifying the correct PDF

Umm, what? Someone cannot create a PDF and sign with someone else's key. This would've defeat the purpose of public-key cryptography.

>it's not a great storage mechanism for this system to scale to thousands or millions of signatures

Not sure how recommending a system that scales not on signatures but on messages shared is better.

>Another alternative is these messages are broadcast through a public and decentralized ledger.

Okay. So suppose a message was distributed from an address. How you know to whom this address belongs? How will be different that you being shared their public key?

[web3isgoing]

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.

[pclmulqdq]

How about he doesn't sign the PDF that is wrong?

If you're imagining that this is part of some key rotation procedure, what about signing a document that says "until April 20th, 2022, 0:00 UTC our public key is X"?

And then if the central source gets hacked, people will be suspicious of the PDF for a few hours, but nobody will do anything disastrous.

Edit: you can also add chaining to the documents themselves: "until... the private key is X. This document supercedes the doument with hash Y."

[web3isgoing]

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.

[pclmulqdq]

The documents themselves are the log. You don't need "zk rollup on L2" to make a verified chain of documents. All that's left is the distribution method.

For that, you put them on your website, using proper security. You put them somewhere where you (and your users) have legal recourse if something goes wrong. That is the safest place to put your public keys.

Also, if your keys are compromised, a blockchain solution is completely and forever corrupted. A website is only corrupted for a few hours until you regain control.

[web3isgoing]

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

[propogandist]

> rely on a public distributed ledger

which brings us back to the point that the ETH foundation is trying to link LibreOffice to ETH cryptocurrency

[chriswarbo]

Why introduce a ledger into such a system? There's no need for global consensus on a total ordering of events.

Just use a DHT, like we've had for decades.

[web3isgoing]

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.

[chriswarbo]

> As I understand, DHT is vulnerable to sybil and eclipse attacks

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.

> not really suited to the task of creating a tamper proof log

That's my point; why impose a log (and hence a total-order of events)?

> 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.

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.

[web3isgoing]

> 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.

[theCrowing]

You never interacted with hackers right? Here in Germany most of the CCC members are quite the realists there isn't much bluesky thinking done without any merit.

[xigoi]

> Another alternative is these messages are broadcast through a public and decentralized ledger

Or, you know, the author's website?

[WinstonSmith84]

I like Hackernews as a place where you can read articles related to technology, which are sometimes really interesting. As for most of the users and most of the comments, this is just another highly toxic social media platform on par with Facebook