Live data from Hacker News

LibreOffice blogs about Blockchain, locks comments after negative user feedback

blog.documentfoundation.org

131–140 of 153 posts

Re: LibreOffice blogs about Blockchain, locks comments after negative user feedback

#131
post #66

Earlier quoted context omitted.

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

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 anythi…

"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 :(

Re: LibreOffice blogs about Blockchain, locks comments after negative user feedback

#132
post #54

Earlier quoted context omitted.

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 k…

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.

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

Re: LibreOffice blogs about Blockchain, locks comments after negative user feedback

#134

Earlier quoted context omitted.

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

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.

I mean the Web.

Re: LibreOffice blogs about Blockchain, locks comments after negative user feedback

#135
post #92

Earlier quoted context omitted.

> 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 "…

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 g…

>Publish those documents wherever you want

And where would one publish such documents, so that they would not be under the control of any single party?

Re: LibreOffice blogs about Blockchain, locks comments after negative user feedback

#136

Earlier quoted context omitted.

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 g…

>Publish those documents wherever you want And where would one publish such documents, so that they would not be under the control of any single party?

I publish them somewhere I have control, like my website, and ask archiving services to archive that page. I don't need them to be under nobody's control.

If someone compromises my blockchain keys, it's about as bad as if someone compromises my website (in terms of the actual attack vectors).

Re: LibreOffice blogs about Blockchain, locks comments after negative user feedback

#137

Earlier quoted context omitted.

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…

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

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.

Re: LibreOffice blogs about Blockchain, locks comments after negative user feedback

#138

Earlier quoted context omitted.

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

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…

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

Re: LibreOffice blogs about Blockchain, locks comments after negative user feedback

#139
post #131

Earlier quoted context omitted.

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 anythi…

"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…

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

Re: LibreOffice blogs about Blockchain, locks comments after negative user feedback

#140
post #132

Earlier quoted context omitted.

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.

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

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.
Post reply on HN