preimage resistance
Picture a hash function as an industrial meat grinder: given a sausage, you cannot reconstruct the cow. Preimage resistance is exactly that one-wayness. Given a digest y, no efficient algorithm should be able to find any message x with H(x) = y. The function is easy to run forwards and infeasible to run backwards.
There are two flavors that people often conflate. First-preimage resistance: from the output y alone, find some x that hashes to it. Second-preimage resistance: given a specific message x1, find a different x2 with H(x2) = H(x1). For an ideal n-bit hash, brute force costs about 2^n evaluations for either property — for SHA-256 that is 2^256, astronomically beyond any conceivable computer. Note this is far harder than finding a collision, which costs only about 2^(n/2) by the birthday bound, because there the attacker may choose both inputs.
Blockchains lean on preimage resistance everywhere. An address is the hash of a public key, so publishing the address does not reveal the key; a hash time-locked contract locks funds behind H(secret) so only the holder of the secret can claim them; proof of work is a constrained preimage search for a nonce whose block hash falls below a target. If a hash lost preimage resistance, address-based protection, commit-reveal schemes, and PoW puzzles would all unravel.
Preimage resistance does not imply collision resistance, nor the reverse in general — a hash can have one property without the other. Robust designs aim for all three (first preimage, second preimage, collision) simultaneously.