Yes, some aspects you need to look at the code, others you will find documented
i would recommend https://learnmeabitcoin.com/ which has very in-depth resources but it seems to be down at the moment
I know how all the small parts work. It's not new technology. I just don't know how Bitcoin does it! To mine a block, you:
• collect a load of transactions (somehow)
• validate them (the obvious stuff, plus the special transaction type requirements, plus unspecified “consensus“ magic I can't find anywhere)
• put them in a block (somehow) along with the hash of the most recent block
• keep changing a certain bit of the block until SHA256(f(SHA256(block))) is low enough (with some f: digest → bitstring)
But I can't fill in the gaps.
validate them: your best resource for this is code. your client needs to keep old consensus code around and use it to verify block under the older rules (your client will do a full sync at some point)
rules for formatting a transactions and blocks (and a byte by byte explanation) can be found on https://learnmeabitcoin.com/ as mentioned (probably will be up soon)
keep changing a certain bit of the block until SHA256(f(SHA256(block))) is low enough (with some f: digest → bitstring): yes. you set the block nonce to mine. finding a block means that the hash256() operation (sha256(sha256(block))) returns an hash with at least D (either left or right most, can't recall right now) bits set to 0, where D is the current difficult, which is adjusted by the network to make the 10min/block average time
> finding a block means that the hash256() operation (sha256(sha256(block))) returns an hash with at least D (either left or right most, can't recall right now) bits set to 0, where D is the current difficult, which is adjusted by the network to make the 10min/block average time
This is a lies-to-children explanation. Bitcoin actually uses less-than a certain value (source: [0]). The tricky part is that a SHA-256 digest is a 256-bit number, and the SHA-256 function's input is a sequence of bits; the SHA-256 specification explicitly declines to specify a canonical representation of that 256-bit number, so it can't be used as the input to SHA-256 without explaining how it's being used. I can't find anywhere what this intermediate function (the one I called f) actually is. There are only half a dozen obvious possibilities (bits from most→least, or least→most, and the four normal ways of doing ASCII hex digests) so it's not that hard to guess, given an example… but still. It's the principle of the matter; it's all under-documented.
(Thanks for the rest of the info by the way. You've given me leads I wouldn't otherwise have been able to easily find.)