# hash Published articles for hash. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Using Exact-Match Response Caching to Reduce LLM Costs DevFeed: [Using Exact-Match Response Caching to Reduce LLM Costs]() Original publisher: [Read original article]() Author: Abhilash Rao Mesala Published: 2026-09-14T11:00:00Z Content type: article Language: en Sources: [The New Stack]() Topics: [Caching](), [Large Language Model]() Tags: [ai-engineering](), [ai-infrastructure](), [caching](), [contributed](), [cost](), [finops](), [generation](), [hash](), [llm](), [token]() ### AI overview The article explains how to reduce LLM costs by fingerprinting requests, context, model settings, and underlying data to create exact-match cache keys. Valid cached responses can be reused without calling the model. It distinguishes response caching from provider prompt caching, where only eligible prompt computation is reused. ### Source excerpt An LLM can answer the same question a thousand times and charge you each time. Before paying for another answer, The post Why an old caching trick is your secret to lower LLM costs appeared first on The New Stack. ## Python sets and dictionaries can have quadratic-time performance DevFeed: [Python sets and dictionaries can have quadratic-time performance]() Original publisher: [Read original article]() Author: Daniel Lemire Published: 2026-09-03T14:01:45Z Content type: article Language: en Sources: [Daniel Lemire]() Topics: [Python](), [Data structures](), [hash](), [CPU Cache]() Tags: [array](), [cpu-cache](), [data-structure](), [hash](), [performance](), [python]() ### AI overview The article explains why Python sets and dictionaries are not formally constant-time in all cases. Hash collisions can make insertions and membership checks take quadratic time, while growing data structures can also incur reallocation and slower memory access as they exceed CPU cache capacity. ### Source excerpt In Python, the dict data structure is the conventional key-value structure. E.g., you might store a list of names as keys and have their phone numbers as values. Valentin Ignatev wrote this amusing post on X: It is indeed widely believed that, in the strict sense, the dict data structure and its companion, the set ... Continue reading Python sets and dictionaries can have quadratic-time performance ## 【eBPF 内核实现深度拆解】从验证器到 JIT，从 BTF 到调度器 DevFeed: [【eBPF 内核实现深度拆解】从验证器到 JIT，从 BTF 到调度器]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-06-12T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [eBPF](), [Linux](), [JIT](), [Benchmark](), [clang](), [hash](), [benchmarking](), [RISC-V](), [ast-matchers]() Tags: [arm](), [array](), [benchmark](), [bpf-jit](), [bpf-maps](), [bpf-verifier](), [btf](), [clang](), [co-re](), [cpu](), [ebpf](), [fentry](), [hash](), [jit](), [kernel](), [libbpf](), [linux](), [linux-kernel](), [precision](), [risc-v](), [sched-ext](), [trampoline](), [x86](), [xdp]() ### AI overview This Chinese-language series systematically explains eBPF's Linux kernel implementation, covering the BPF instruction set and registers, verifier algorithms, JIT compilation, map data structures and concurrency, helper type checking, BTF and CO-RE relocation, libbpf loading, trampolines, and sched_ext interfaces. It is aimed at engineers who want to understand eBPF kernel source code and build production BPF programs. ### Source excerpt eBPF 内核虚拟机内部实现系统讲解：BPF 指令集与寄存器机器、验证器的抽象解释与状态裁剪、JIT 编译器后端、Map 各类型的并发与内存模型、helper 函数注册与类型检查、BTF 格式规范与 CO-RE 重定位引擎、libbpf 加载器工程、fentry/fexit 蹦床机制、sched_ext 调度器内核接口。面向想读懂 eBPF 内核源码、写生产级 BPF 程序的系统工程师。 ## Recent LLVM hash table improvements DevFeed: [Recent LLVM hash table improvements]() Original publisher: [Read original article]() Published: 2026-06-07T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [hash](), [Algorithms](), [benchmarking]() Tags: [algorithm](), [compiler](), [data-structures](), [hash](), [improvements](), [llvm](), [performance]() ### AI overview The article reviews recent improvements to LLVM hash tables, including replacing quadratic probing and tombstone or empty-key sentinels with linear probing, Algorithm R deletion, and bit-array occupancy. It also discusses pointer and iterator invalidation behavior and reports performance improvements in DenseMap. ### Source excerpt LLVM has several hash tables. They used quadratic probing with in-band sentinel keys (empty, tombstone); recent work has been replacing that with linear probing with tombstone key removed. DenseMap (replacement for std::unordered_map): DenseMapInfo::getEmptyKey() / getTombstoneKey(). DenseSet: implemented using DenseMap compiler-rt/lib/sanitizer_common/sanitizer_dense_map.h ports the implementation for sanitizers. SmallPtrSet (replacement for std::unordered_set): hard-coded -1 (empty) and -2 (tombstone). StringMap (replacement for std::unordered_map) StringSet: implemented using StringMap FoldingSet (uniquing/hash-consing container, not a general map) For the open-addressed DenseMap and SmallPtrSet, pointers, references, and iterators are invalidated by insert. StringMap is different: each entry lives in a heap-allocated StringMapEntry node, so entry pointers survive grow. std::unordered_map, being node-based, keeps surviving-element pointers valid across both insert and erase and only invalidates the erased element's own iterator. LLVM code rarely needs that stronger contract -- callers do not hold long-lived references into the container across mutation -- and that gap is what gives pass to relocating erase and bit-array occupancy. Recently, Tombstones have been removed from DenseMap and SmallPtrSet. erase() also invalidates pointers. DenseMap has also retired its empty-key sentinel, leading to significant performance improvements. DenseMap with integer keys (int/unsigned/size_t) had -1/-2 reserved -- a footgun, now fixed. StringMap got Algorithm R deletion too. Its entries are separately heap-allocated, so erase keeps entry pointers valid but invalidates iterators; erase-while-iterating moved to remove_if. FoldingSet dropped chaining for linear probing plus Algorithm R; the intrusive next-in-bucket pointer became a cached 32-bit hash. ## Only 17% of all 64-bit Integers are products of two 32-bit integers DevFeed: [Only 17% of all 64-bit Integers are products of two 32-bit integers]() Original publisher: [Read original article]() Author: Daniel Lemire Published: 2026-05-22T01:16:35Z Content type: article Language: en Sources: [Daniel Lemire]() Topics: [Programming](), [hash]() Tags: [cryptographic](), [hash](), [numbers](), [precision](), [programming]() ### AI overview The article examines what fraction of 64-bit integers can be represented as the full product of two 32-bit integers. It presents the result that only 17% can be produced this way and relates the question to hash-function design and multiplication behavior. ### Source excerpt In software programming, the product between two integers is often computed to a fixed number of bits with overflow. Consider 8-bit integers. If you multiply 127 by 127, you get back the number 1 as an 8-bit unsigned integer, with an overflow. The actual full product is 16129. To represent 16129, you typically use 16 ... Continue reading Only 17% of all 64-bit Integers are products of two 32-bit integers ## Fighting Hyrum's Law in LLVM DevFeed: [Fighting Hyrum's Law in LLVM]() Original publisher: [Read original article]() Published: 2026-05-10T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [Compiler](), [reproducible builds](), [hash]() Tags: [clang](), [compiler](), [hash](), [lld](), [llvm](), [reproducible-builds](), [test]() ### AI overview This article examines how LLVM can develop dependencies on unspecified or incidental behavior under Hyrum's Law, causing output variation that harms reproducible builds, bisection, and bug reports. It describes hash-seed perturbation, reverse container iteration, and iterator invalidation checks as mechanisms for exposing such dependencies. ### Source excerpt With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. -- Hyrum's Law In a compiler, the most common form of Hyrum's Law is dependence on unspecified behavior -- hash bucket order, the order of equal elements after std::sort, padding offsets. The same framing covers a few cases that are technically undefined behavior (use of an invalidated iterator) or plain incidental properties (ABI struct layout, ELF section offsets). When the compiler itself harbors such a dependency, the symptom is usually output that varies build-to-build: an unstable sort that lands differently after the standard library changes, a hash map whose iteration order shifts when the hash function does. Occasionally the variation is run-to-run within a single build -- DenseMap keys with an ASLR-derived seed reorder buckets each invocation. Either way, reproducible builds, bisection, and bug reports all assume same input -> same output, and a stealth Hyrum dependency breaks that. This post surveys some mechanisms that perturb the contract's blind spots so dependencies cannot quietly form. ## Cuckoo Filters: Cache-Friendly Membership Checks With Deletions DevFeed: [Cuckoo Filters: Cache-Friendly Membership Checks With Deletions]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-17T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [CPU Cache](), [Caching](), [hash]() Tags: [cache](), [capacity](), [cpu-cache](), [cuckoo-filter](), [data-structures](), [false-positive](), [hash](), [insert](), [performance](), [probabilistic](), [spatial-locality](), [systems]() ### AI overview This article explains how Cuckoo filters support deletions while improving CPU cache behavior compared with counting Bloom filters. They check two specific buckets using compact fingerprints, but insertions can fail when kick-out chains exceed their limit, requiring capacity planning or overflow handling. ### Source excerpt A Cuckoo filter stores a one-to-two byte fingerprint in a hash table and finds it by checking exactly two buckets, the primary index and its XOR-derived alternate, instead of k random bit positions scattered across a large array. That spatial locality is the whole win on real CPUs. The trade-off is a hard edge: when the kick-out chain exceeds its limit, the insert fails outright. ## Shazam finds songs by voting on time offsets, not by comparing audio DevFeed: [Shazam finds songs by voting on time offsets, not by comparing audio]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-16T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Algorithm](), [hash](), [Databases]() Tags: [algorithm](), [algorithms](), [audio-fingerprinting](), [databases](), [hash](), [indexing](), [lookup](), [music-recognition](), [query](), [system-design]() ### AI overview The article explains how Shazam recognizes songs from short, noisy recordings. Instead of comparing audio similarity, it extracts spectrogram peaks, combines nearby peaks into hashes, and uses an inverted index to find tracks whose hash matches share a common time offset. The production system beyond the public 2003 paper is noted as unavailable. ### Source excerpt Shazam does not compare audio. It reduces each track to spectrogram peaks, pairs nearby peaks into ~32-bit hashes, and looks those up in an inverted index. A match is declared when many hashes from the sample agree on a single time offset into one track. The offset histogram is the whole trick: noise scatters offsets randomly, a real match stacks them into a spike. ## Hardening básico de servidores Linux DevFeed: [Hardening básico de servidores Linux]() Original publisher: [Read original article]() Author: Antonio Pérez Published: 2026-01-22T00:00:00Z Content type: tutorial Language: es Sources: [tengoping.com]() Topics: [Linux](), [Firewall](), [ssh](), [Fail2ban](), [OpenSSH](), [Kernel]() Tags: [fail2ban](), [firewall](), [hardening](), [hash](), [kernel](), [linux](), [ssh]() ### AI overview This Spanish tutorial presents a basic hardening checklist for Linux servers and explains why the measures should be applied in a specific order. It covers system updates, SSH, firewall configuration, user policies, sudo restrictions, kernel parameters, unnecessary services, Fail2ban, auditing, and final verification. ### Source excerpt Checklist de hardening en el orden correcto: SSH, firewall, usuarios, kernel, AIDE, chrony y verificación final con Lynis. ## Analysis of Dahua CCTV Camera Authentication DevFeed: [Analysis of Dahua CCTV Camera Authentication]() Original publisher: [Read original article]() Published: 2025-12-01T23:00:00Z Content type: tutorial Language: en Sources: [Dennis Yurichev]() Topics: [webcam](), [hash](), [Python]() Tags: [auth](), [camera](), [hash](), [python](), [tcp]() ### AI overview A pentesting-oriented analysis of Dahua CCTV camera authentication over its proprietary TCP protocol. It describes a fake Python server used to observe a camera login and presents the known portion of the hash calculation, while noting that the remaining 16 bytes are not understood and no Hashcat workflow was found. ### Source excerpt [Pentesting] Dahua (CCTV cameras) auth ## \[Pentesting\] RTSP (CCTV cameras) auth DevFeed: [\[Pentesting\] RTSP (CCTV cameras) auth]() Original publisher: [Read original article]() Published: 2025-11-23T23:00:00Z Content type: tutorial Language: en Sources: [Dennis Yurichev]() Topics: [passwords](), [HTTP](), [TLS (Transport Layer Security)](), [SSL](), [Python]() Tags: [auth](), [hash](), [http](), [passwords](), [python](), [ssl](), [tls]() ### AI overview A pentesting article examines authentication in RTSP CCTV camera streams, comparing basic and digest authentication. It demonstrates how ARP spoofing and captured exchanges can enable password enumeration or cracking, and recommends firmware updates, strong passwords, and SSL/TLS. ### Source excerpt [Pentesting] RTSP (CCTV cameras) auth ## A simplified p-fast trie for prefix and predecessor searches DevFeed: [A simplified p-fast trie for prefix and predecessor searches]() Original publisher: [Read original article]() Published: 2025-08-06T17:19:09Z Content type: article Language: en Sources: [Tony Finch's blog]() Topics: [Algorithm](), [hash](), [Cache](), [Query (disambiguation)]() Tags: [algorithm](), [cache](), [hash](), [query]() ### AI overview The article presents a simplified revision of a p-fast trie, a wide fan-out variant of an x-fast trie. It describes a hash-table layout for storing unique prefixes and outlines longest-prefix, predecessor, and successor searches. ### Source excerpt Previously, I wrote some sketchy ideas for what I call a p-fast trie, which is basically a wide fan-out variant of an x-fast trie. It allows you to find the longest matching prefix or nearest predecessor or successor of a query string in a set of names in O(log k) cache misses, where k is the key length. My initial sketch was more complicated and greedy for space than necessary, so here's a simplified revision. ("p" now stands for prefix.) layout A p-fast trie stores a lexicographically ordered set of names. A name is a sequence of characters from some small-ish character set. For example, DNS names can be represented as a set of about 50 letters, digits, punctuation and escape characters, usually one per byte of name. Names that are arbitrary bit strings can be split into chunks of 6 bits to make a set of 64 characters. Every unique prefix of every name is added to a hash table. An entry in the hash table contains: A shared reference to the closest name lexicographically greater than or equal to the prefix. Multiple hash table entries will refer to the same name. A reference to a name might instead be a reference to a leaf object containing the name. The length of the prefix. To save space, each prefix is not stored separately, but implied by the combination of the closest name and prefix length. A bitmap with one bit per possible character, corresponding to the next character after this prefix. For every other prefix that matches this prefix and is one character longer than this prefix, a bit is set in the bitmap corresponding to the last character of the longer prefix. search The basic algorithm is a longest-prefix match. Look up the query string in the hash table. If there's a match, great, done. Otherwise proceed by binary chop on the length of the query string. If the prefix isn't in the hash table, reduce the prefix length and search again. (If the empty prefix isn't in the hash table then there are no names to find.) If the prefix is in the hash table, check ## p-fast trie: lexically ordered hash map DevFeed: [p-fast trie: lexically ordered hash map]() Original publisher: [Read original article]() Published: 2025-08-04T20:52:21Z Content type: article Language: en Sources: [Tony Finch's blog]() Topics: [hash](), [Query (disambiguation)](), [Rust]() Tags: [array](), [bits](), [hash](), [map](), [maps](), [query]() ### AI overview This article sketches the p-fast trie, a proposed lexically ordered hash map that replaces a qp-trie's tree and interior pointers with stratified hash-map levels keyed by prefixes. It describes O(1) exact-match lookups and O(log k) predecessor and successor searches, while noting that the practical benefit is uncertain. ### Source excerpt Here's a sketch of an idea that might or might not be a good idea. Dunno if it's similar to something already described in the literature - if you know of something, please let me know via the links in the footer! The gist is to throw away the tree and interior pointers from a qp-trie. Instead, the p-fast trie is stored using a hash map organized into stratified levels, where each level corresponds to a prefix of the key. Exact-match lookups are normal O(1) hash map lookups. Predecessor / successor searches use binary chop on the length of the key. Where a qp-trie search is O(k), where k is the length of the key, a p-fast trie search is O(log k). This smaller O(log k) bound is why I call it a "p-fast trie" by analogy with the x-fast trie, which has O(log log N) query time. (The "p" is for popcount.) I'm not sure if this asymptotic improvement is likely to be effective in practice; see my thoughts towards the end of this note. layout A p-fast trie consists of: Leaf objects, each of which has a name. Each leaf object refers to its successor forming a circular linked list. (The last leaf refers to the first.) Multiple interior nodes refer to each leaf object. A hash map containing every (strict) prefix of every name in the trie. Each prefix maps to a unique interior node. Names are treated as bit strings split into chunks of (say) 6 bits, and prefixes are whole numbers of chunks. An interior node contains a (1<<6) == 64 wide bitmap with a bit set for each chunk where prefix+chunk matches a key. Following the bitmap is a popcount-compressed array of references to the leaf objects that are the closest predecessor of the corresponding prefix+chunk key. Prefixes are strictly shorter than names so that we can avoid having to represent non-values after the end of a name, and so that it's OK if one name is a prefix of another. The size of chunks and bitmaps might change; 6 is a guess that I expect will work OK. For restricted alphabets you can use something like my DNS trie n ## How Cursor Indexes Codebases Fast DevFeed: [How Cursor Indexes Codebases Fast]() Original publisher: [Read original article]() Author: Engineer's Codex Published: 2025-05-10T16:28:09Z Content type: article Language: en Sources: [Engineer's Codex]() Topics: [cursor](), [Software Engineering](), [Code](), [hash](), [Embeddings](), [structure](), [file](), [implementation]() Tags: [code](), [cursor](), [embeddings](), [hash](), [index](), [indexing](), [software-engineering]() ### AI overview This article explains how Cursor indexes codebases using Merkle trees. It describes local code chunking, hash-tree construction and synchronization with Cursor's server, followed by embedding generation through OpenAI's embedding API or a custom embedding model. ### Source excerpt Merkle Trees in the real world ## Rust HashMap notes DevFeed: [Rust HashMap notes]() Original publisher: [Read original article]() Author: Graham King Published: 2025-03-30T14:50:00Z Content type: article Language: en Sources: [Graham King]() Topics: [Rust](), [implementation](), [Data structures]() Tags: [array](), [bits](), [cache](), [code](), [datastructures](), [hash](), [hashmap](), [implementation](), [optimization](), [rust](), [software]() ### AI overview Raw research notes explaining the design and implementation of Rust's HashMap. The article describes its SwissTable-based probing layout, contiguous storage, control bytes, SIMD comparisons, hash decomposition, lookup process, and growth behavior. ### Source excerpt Raw notes on Rust's HashMap design and implementation ## Inserting One New Element into Hashes of Varying Sizes DevFeed: [Inserting One New Element into Hashes of Varying Sizes]() Original publisher: [Read original article]() Author: Pat Shaughnessy Published: 2025-02-04T00:00:00Z Content type: tutorial Language: en Sources: [Pat Shaughnessy]() Topics: [Ruby](), [hash](), [Benchmark](), [Code]() Tags: [benchmark](), [hash](), [internals](), [ruby](), [table](), [updating-ruby-under-a-microscope]() ### AI overview This article presents a Ruby experiment measuring the time required to insert one new element into hashes of different sizes. Using Ruby 3.4.1, it observes timing spikes when the hash grows to certain sizes, consistent with rehashing or redistribution. ### Source excerpt I've started working on a new edition of Ruby Under a Microscope that covers Ruby 3.x. I'm working on this in my spare time, so it will take a while. Leave a comment or drop me a line and I'll email you when it's finished. RUM includes a serie ## Updating Ruby Under a Microscope DevFeed: [Updating Ruby Under a Microscope]() Original publisher: [Read original article]() Author: Pat Shaughnessy Published: 2025-01-28T00:00:00Z Content type: article Language: en Sources: [Pat Shaughnessy]() Topics: [Ruby](), [hash](), [Computer science](), [C]() Tags: [hash](), [internals](), [ruby](), [updating](), [updating-ruby-under-a-microscope]() ### AI overview An excerpt from a planned new edition of Ruby Under a Microscope explains how Ruby uses hash tables internally. It introduces hash-table organization and describes how Ruby stores keys, values, entries, bins, and related C structures. ### Source excerpt Ruby stores much of its own internal data in hash tables. I've started working on a new edition of ## Comparison between Redis and DragonflyDB's data stores DevFeed: [Comparison between Redis and DragonflyDB's data stores]() Original publisher: [Read original article]() Published: 2024-08-27T00:00:00Z Content type: article Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Redis](), [data](), [hashing]() Tags: [architecture](), [clustering](), [comparison](), [hash](), [memory](), [redis](), [single-threaded](), [vs]() ### AI overview This article compares how Redis and DragonflyDB store data in memory. It explains Redis's single-threaded architecture and DragonflyDB's multithreaded, shared-nothing design, then introduces separate chaining, open addressing, and extendible hashing. ### Source excerpt . [Redis vs DragonflyDB Data Store Comparison](redis-vs-dragonflydbs-data-stores-cover... ## Immutable URLs can simplify deployments DevFeed: [Immutable URLs can simplify deployments]() Original publisher: [Read original article]() Published: 2024-03-14T00:00:00Z Content type: article Language: en Sources: [Garnix Blog]() Topics: [hash]() Tags: [deployments](), [hash](), [idea](), [simplify]() ### AI overview The article explores making URLs immutable and suggests that this approach could improve and simplify deployments. ### Source excerpt What happens if we make URLs immutable? A somewhat unusual idea that can substantially improve and simplify deployments. ## Wrapping up the KZG Ceremony DevFeed: [Wrapping up the KZG Ceremony]() Original publisher: [Read original article]() Author: EF Protocol Support Published: 2024-01-23T00:00:00Z Content type: article Language: en Sources: [Ethereum Foundation Blog]() Topics: [Ethereum](), [Transactions](), [Bot](), [GitHub]() Tags: [bots](), [contribution](), [contributors](), [cryptographic](), [devcon](), [ethereum](), [github](), [hash](), [open](), [research-development](), [transactions]() ### AI overview The article documents the 2023 KZG Ceremony, a 208-day multi-party computation that produced the cryptographic foundation for Ethereum's EIP-4844. It reports 141,416 contributions, explains participation and spam-prevention requirements, and provides the final transcript hash and availability information. ### Source excerpt The KZG Ceremony was the largest multi-party computation of its kind (by number of participants). Through an open, accessible process, it produced a secure cryptographic foundation for EIP-4844. Learn more about how the Ceremony worked in Carl Beekhuizen's Devcon talk: "Summoning the spirit of the Dankshard" As the... ## Chainguard contributes Rekor Search project to Sigstore DevFeed: [Chainguard contributes Rekor Search project to Sigstore]() Original publisher: [Read original article]() Published: 2023-03-24T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard](), [browser](), [Code](), [Git]() Tags: [browser](), [chainguard](), [git](), [gitsign](), [hash](), [index](), [open-source-software](), [rekor](), [search](), [sigstore](), [transparency-log](), [ui]() ### AI overview Chainguard is donating its open-source Rekor Search UI project to Sigstore. The browser-based search engine lets users search and sort entries in the public Rekor transparency log by email, hash, entry UUID, or log index, with support for Gitsign signatures and Git commit associations. ### Source excerpt Chainguard announces its donating the Rekor Search UI project to Sigstore, allowing users to conveniently search entries in the public Rekor transparency log. ## Calculating Download MD5 Hash DevFeed: [Calculating Download MD5 Hash]() Original publisher: [Read original article]() Published: 2023-03-09T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [HTTP](), [cURL](), [Google Cloud Platform (GCP)](), [dataset](), [Code]() Tags: [ardan-labs](), [blog](), [cloud](), [code](), [curl](), [dataset](), [go](), [go-programming](), [golang](), [google-cloud](), [hash](), [http](), [programming]() ### AI overview This tutorial explains how to validate a downloaded file's MD5 signature using HTTP headers and Go. It demonstrates obtaining file metadata with an HTTP HEAD request, reading the MD5 value reported by Google Cloud Storage, and implementing the request and header parsing in Go. ### Source excerpt Introduction One of the exercises I give to students is to download a single big file over HTTP concurrently using several goroutines using HTTP Range requests. An extra part of the exercise is to validate the downloaded file from a known MD5 signature. This extra part turns out to be interesting, let's have a look. Getting Download Information Let's make an HTTP HEAD request to get information about a file located in a public dataset stored on Google Cloud Storage (GCS). ## Ultimate Go: Advanced Engineering Episode 13 DevFeed: [Ultimate Go: Advanced Engineering Episode 13]() Original publisher: [Read original article]() Published: 2023-01-11T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Blockchain](), [Go Language](), [Algorithm](), [Security](), [Ethereum](), [API](), [Transactions]() Tags: [algorithm](), [bitcoin](), [blockchain](), [data-stamping](), [digital-signature](), [digital-signatures](), [ethereum](), [go](), [go-blockchain](), [hash](), [hexademical](), [how-to](), [keccak256](), [salt](), [security](), [video]() ### AI overview This video tutorial explains how to add a salt value to transaction hashes, implement the keccak256 algorithm in Go, and use transaction stamping in a blockchain. It also discusses digital signatures and related security issues. ### Source excerpt Introduction In episode 12, Bill laid out his strategy to handle data hashing on his blockchain. The first step he took was to create a package to handle the cryptographical aspects of his blockchain. After that, he wrote a hash function that met the requirements outlined in his strategy. This function took transaction data as a parameter and returned a hexadecimal representation of the hash. To implement this function, Bill imported packages from the Go standard library and Ethereum API. ## Ultimate Go: Advanced Engineering Episode 12 DevFeed: [Ultimate Go: Advanced Engineering Episode 12]() Original publisher: [Read original article]() Published: 2023-01-04T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [data](), [Blockchain](), [Algorithm](), [Ethereum](), [Library](), [Code]() Tags: [algorithm](), [bitcoin](), [blockchain](), [code](), [ethereum](), [go](), [go-blockchain](), [hash](), [hashing](), [hex-value](), [hexademical](), [standard-library](), [video]() ### AI overview This video tutorial explains how to hash a transaction in Go using packages from the standard library and the Ethereum Go library. It also discusses the desired properties of a hashing function and the role of cryptographic signatures and public-key recovery in a decentralized blockchain. ### Source excerpt Introduction In episode 11, Bill highlighted the issue of identity verification and provided a solution to this problem. The solution proposed was to cryptographically sign a transaction to verify its authenticity. Bill chose to implement a solution making use of the Elliptic Curve Digital Signature Algorithm (ECDSA) as the public key can be extracted from a signature. Although a small distinction, the ability to re-compute a public key is essential in a decentralized and distributed environment. [Next page]()