3 ms·

"How do I make a transaction / mine a block?" that's a "how does it works ?" kind of question, you need to know how all the small parts work to explain the func

by spinny 5y ago

"How do I make a transaction / mine a block?" that's a "how does it works ?" kind of question, you need to know how all the small parts work to explain the functionality. Yes, some aspects you need to look at the code, others you will find documented i would recommend https://learnmeabitcoin.com/ https://learnmeabitcoin.com/ which has very in-depth resources but it seems to be down at the moment

wizzwizz4 5y ago
> you need to know how all the small parts work to explain the functionality. 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.
- spinny 5y ago
  collect a load of transactions (somehow): by this you mean the mempool. the implementation is client dependent, it uses the p2p network to receive new txs, thats what you need to look at to know how to "get txs from the network". some implementations have better documentation. if you need to look at code i would recommend the go implementation https://github.com/btcsuite https://github.com/btcsuite just because it looks cleaner to me. 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/ 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
  - wizzwizz4 5y ago
    Ah, so “you have to look at the code” is a feature, not a bug. That makes some sense, I suppose. > 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.) [0]: https://en.bitcoin.it/wiki/Difficulty https://en.bitcoin.it/wiki/Difficulty

by spinny 5y ago

wizzwizz4 5y ago

> you need to know how all the small parts work to explain the functionality. 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.

spinny 5y ago
collect a load of transactions (somehow): by this you mean the mempool. the implementation is client dependent, it uses the p2p network to receive new txs, thats what you need to look at to know how to "get txs from the network". some implementations have better documentation. if you need to look at code i would recommend the go implementation https://github.com/btcsuite https://github.com/btcsuite just because it looks cleaner to me. 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/ 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
- wizzwizz4 5y ago
  Ah, so “you have to look at the code” is a feature, not a bug. That makes some sense, I suppose. > 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.) [0]: https://en.bitcoin.it/wiki/Difficulty https://en.bitcoin.it/wiki/Difficulty