The joke is there are two kinds of distributed systems: Spanner and Bitcoin.

I'm working on a project where I need to prove that a file in a git repo is append only, ie all changes to the file only added lines. The only way I can think of is looking at the git history of the file, but would there be a faster way using Merkel trees somehow?

There are use-cases outside of "crypto" for blockchain - notably for security related use-cases such as historization ; tough I concede that use-case can be handled with more standard technologies it is very fun to get into it and study such use as it may have properties that could be interesting. One has to have some time for this but to be frank it's not really something super hard to pull-off (Bc itself conceptually)

I'm currently exploring how different APIs compute ETags [1]. I'm inclined to think the overhead of Merkle-trees make them relatively less useful for ETags for paginated APIs where responses are small and flat hashing is fast. One rule of thumb would be: the overhead isn't justified unless you need either (a) efficient updates on very large collections, or (b) collection-level state tracking across pagination boundaries. Sound about right?

[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

Also, ETags can use weak validators:

> W/ (case-sensitive) indicates that a weak validator is used. Weak ETags are easy to generate, but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult to generate efficiently. Weak ETag values of two representations of the same resources might be semantically equivalent, but not byte-for-byte identical. This means weak ETags prevent caching when byte range requests are used, but strong ETags mean range requests can still be cached.

Isn't the whole point of a merkle tree that you just... compare them?

Yes, the term block chain does has a specific technical meaning: a sequence of hashed values where each contains the hash of the previous, similar to the way a git commit includes the hash of its parent commit. But the term blockchain has also taken on a broader colloquial meaning of "log with certain cryptographic properties", which both block chain and merkle tree implementations can satisfy with various advantages and disadvantages. I think it's fair to allow usage of the broader definition.

A blockchain can use Merkle trees in several ways. First, the block header usually contains the Merkle root of all transactions. This makes the header, and in turn the Proof-of-Work, commit to all txs, which helps make the chain immutable. Second, the header can also directly commit to the UTXO set, simplifying the design of light clients (sadly, Bitcoin doesn't do this).

Doesn't bitcoin use merkle-trees internally to create its blockchain?