6 ms·

Is a Merkle tree needed or is good old basic double ledger accounting in a central database sufficient? If a key requirement is not a distributed ledger then it

by trog 2y ago

Is a Merkle tree needed or is good old basic double ledger accounting in a central database sufficient? If a key requirement is not a distributed ledger then it seems like a waste of time.

Onavo 2y ago
Merkle tree is to prevent tampering, not bad accounting practices
- nly 2y ago
  It only prevents tampering if the cost of generating hashes is extremely high. Internally in your company you're not going to spend millions of $'s a year in GPU compute just to replace a database.
  - xorcist 2y ago
    "Prevents tampering" lacks specificity. git is a blockchain that prevents tampering in some aspects, but you can still force push if you have that privilege. What is important is understand what the guarantees are.
  - limit499karma 2y ago
    ? If I use something like Blake3 (which is super fast and emits gobs of good bits) and encode a node with say 512 bits of the hash, you are claiming that somehow I am vulnerable to tampering because the hash function is fast? What is the probable number of attempts to forge a document D' that hashes to the very same hash? And if the document in structured per a standard format, you have even less degrees of freedom in forging a fake. So yes, a Merkel tree definitely can provide very strong guarantees against tampering.
    - oconnor663 2y ago
      Fwiw, increasing the BLAKE3 output size beyond 256 bits doesn't add security, because the internal "chaining values" are still 256 bits regardless of the final output length. But 256 bits of security should be enough for any practical purpose.
      - limit499karma 2y ago
        Good to know. But does that also mean that e.g. splitting the full output to n 256 chunks would mean there is correlation between the chunks? (I always assumed one could grab any number of bits (from anywhere) in a cryptographic hash.)
        oconnor663 2y ago
        You can take as many bytes from the output stream as you want, and they should all be indistinguishable from random to someone who can't guess the input. (Similar to how each of the bytes of a SHA-256 hash should appear independently random. I don't think that's a formal design goal in the SHA-2 spec, but in practice we'd be very surprised and worried if that property didn't hold.) But for example in the catastrophic case where someone found a collision in the default 256-bit BLAKE3 output, they would probably be able to construct colliding outputs of unlimited length with little additional effort.
  - benlivengood 2y ago
    Certificate transparency logs achieve tamper-resistance without expensive hashes.
- agentultra 2y ago
  Write-Once, Read Many drives also prevent tampering. Not everything needs crypto.
  - chaboud 2y ago
    In a distributed setting where a me may wish to join the party late and receive a non-forged copy, it’s important. The crypto is there to stand in for an authority.
    - trog 2y ago
      > In a distributed setting where a me may wish to join the party late and receive a non-forged copy, it’s important. The crypto is there to stand in for an authority. Yeh, but that's kinda my point: if your primary use case is not "needs to be distributed" then there's almost never a benefit, because there is always a trusted authority and the benefits of centralisation outweigh (massively, IMO) any benefit you get from a blockchain approach.
      - chaboud 2y ago
        100% agreed there. A central authority can just sign stuff. Merkle trees can still be very valuable for integrity and synchronization management, but burning a bunch of energy to bogo-search nonces is silly if the writer (or federated writers) can be cryptographic authorities.
jchanimal 2y ago
We launched Fireproof earlier this month on HN. It’s a tamperproof Merkle CRDT in TypeScript, with an object storage backend for portability. See our Show HN: https://news.ycombinator.com/item?id=42184362 https://news.ycombinator.com/item?id=42184362 We’ve seen interest from trading groups for edge collaboration, so multi-user apps can run on-site without cloud latency.
- nearting 2y ago
  This doesn't address the question in any way except to note that you also use Merkle Trees. Do you reply to any comment mentioning TypeScript with a link to your Show HN post as well?
- hluska 2y ago
  What disrespectful marketing. We don’t care that you use Merkle trees because that’s irrelevant. I guess I can add Fireproof to my big list of sketchy products to avoid. It’s embarrassing.
  - jchanimal 2y ago
    I figured the responses would be more interesting. Questions about CRDT guarantees etc. Perhaps worth seeding the convo with a remark about finality.
    - hluska 2y ago
      While your intentions may have been around discussion, I don’t want to be marketed to when I’m trying to understand something unrelated. I have a business degree so I intimately understand that HN is technically free and it’s nice to get free eyeballs, but we are people too. I’m so much more than a credit card number, yet you’ve reduced me to a user acquisition in the most insulting way possible. Perhaps instead of your ideas, it’s worth seeding your own personal make up with a firm statement of ethics?? Are you the kind of person who will hijack conversations to promote your product? Or do you have integrity? Just purely out of concern for your business, do you have a cofounder who could handle marketing for you? If so, consider letting her have complete control over that function. It’s genuinely sad to see a founder squander goodwill on shitty marketing.

by trog 2y ago

Is a Merkle tree needed or is good old basic double ledger accounting in a central database sufficient? If a key requirement is not a distributed ledger then it seems like a waste of time.

Onavo 2y ago

Merkle tree is to prevent tampering, not bad accounting practices

nly 2y ago
It only prevents tampering if the cost of generating hashes is extremely high. Internally in your company you're not going to spend millions of $'s a year in GPU compute just to replace a database.
- xorcist 2y ago
  "Prevents tampering" lacks specificity. git is a blockchain that prevents tampering in some aspects, but you can still force push if you have that privilege. What is important is understand what the guarantees are.
- limit499karma 2y ago
  ? If I use something like Blake3 (which is super fast and emits gobs of good bits) and encode a node with say 512 bits of the hash, you are claiming that somehow I am vulnerable to tampering because the hash function is fast? What is the probable number of attempts to forge a document D' that hashes to the very same hash? And if the document in structured per a standard format, you have even less degrees of freedom in forging a fake. So yes, a Merkel tree definitely can provide very strong guarantees against tampering.
  - oconnor663 2y ago
    Fwiw, increasing the BLAKE3 output size beyond 256 bits doesn't add security, because the internal "chaining values" are still 256 bits regardless of the final output length. But 256 bits of security should be enough for any practical purpose.
    - limit499karma 2y ago
      Good to know. But does that also mean that e.g. splitting the full output to n 256 chunks would mean there is correlation between the chunks? (I always assumed one could grab any number of bits (from anywhere) in a cryptographic hash.)
      - oconnor663 2y ago
        You can take as many bytes from the output stream as you want, and they should all be indistinguishable from random to someone who can't guess the input. (Similar to how each of the bytes of a SHA-256 hash should appear independently random. I don't think that's a formal design goal in the SHA-2 spec, but in practice we'd be very surprised and worried if that property didn't hold.) But for example in the catastrophic case where someone found a collision in the default 256-bit BLAKE3 output, they would probably be able to construct colliding outputs of unlimited length with little additional effort.
- benlivengood 2y ago
  Certificate transparency logs achieve tamper-resistance without expensive hashes.
agentultra 2y ago
Write-Once, Read Many drives also prevent tampering. Not everything needs crypto.
- chaboud 2y ago
  In a distributed setting where a me may wish to join the party late and receive a non-forged copy, it’s important. The crypto is there to stand in for an authority.
  - trog 2y ago
    > In a distributed setting where a me may wish to join the party late and receive a non-forged copy, it’s important. The crypto is there to stand in for an authority. Yeh, but that's kinda my point: if your primary use case is not "needs to be distributed" then there's almost never a benefit, because there is always a trusted authority and the benefits of centralisation outweigh (massively, IMO) any benefit you get from a blockchain approach.
    - chaboud 2y ago
      100% agreed there. A central authority can just sign stuff. Merkle trees can still be very valuable for integrity and synchronization management, but burning a bunch of energy to bogo-search nonces is silly if the writer (or federated writers) can be cryptographic authorities.

jchanimal 2y ago

We launched Fireproof earlier this month on HN. It’s a tamperproof Merkle CRDT in TypeScript, with an object storage backend for portability. See our Show HN: https://news.ycombinator.com/item?id=42184362 https://news.ycombinator.com/item?id=42184362 We’ve seen interest from trading groups for edge collaboration, so multi-user apps can run on-site without cloud latency.

nearting 2y ago
This doesn't address the question in any way except to note that you also use Merkle Trees. Do you reply to any comment mentioning TypeScript with a link to your Show HN post as well?
hluska 2y ago
What disrespectful marketing. We don’t care that you use Merkle trees because that’s irrelevant. I guess I can add Fireproof to my big list of sketchy products to avoid. It’s embarrassing.
- jchanimal 2y ago
  I figured the responses would be more interesting. Questions about CRDT guarantees etc. Perhaps worth seeding the convo with a remark about finality.
  - hluska 2y ago
    While your intentions may have been around discussion, I don’t want to be marketed to when I’m trying to understand something unrelated. I have a business degree so I intimately understand that HN is technically free and it’s nice to get free eyeballs, but we are people too. I’m so much more than a credit card number, yet you’ve reduced me to a user acquisition in the most insulting way possible. Perhaps instead of your ideas, it’s worth seeding your own personal make up with a firm statement of ethics?? Are you the kind of person who will hijack conversations to promote your product? Or do you have integrity? Just purely out of concern for your business, do you have a cofounder who could handle marketing for you? If so, consider letting her have complete control over that function. It’s genuinely sad to see a founder squander goodwill on shitty marketing.