Live data from Hacker News

LibreOffice blogs about Blockchain, locks comments after negative user feedback

blog.documentfoundation.org

151–153 of 153 posts

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

#151

Earlier quoted context omitted.

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

Unless you go full self-hosted, your website is also under the control of your hosting provider and DNS registry. You implicitly trust those, until you don't. (See the Linode/Itch.io gaffe from the other day.)

And what if your use case requires you to prove to others that you (or your publisher) can't surreptitiously and arbitrarily alter the information you published?

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

#152

Earlier quoted context omitted.

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.

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

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

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

#153

Earlier quoted context omitted.

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

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

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

Post reply on HN