Show Posts
|
Pages: [1] 2 »
|
I'm not so sure about the usefulness of this document, still, I've gave you some merit for the effort. At least it's part of (your) learning curve. [/quote]
I don't care about "Merit", what am I supposed to do with that?
If you're unsure about the use of the document, then I'm unsure about the use of "Development & Technical Discussion".
It's the last time that I've posted here, if people like the ones I've encountered here are the first "Bitcoiners" people get to talk to, then it's no wonder nobody likes us.
TL;DR: Keep your worthless merit.
|
|
|
You're making me feel bad about being so harsh to you, but you made me say it.
|
|
|
Alright then, maybe point out what's wrong?
It's beyond me how someone capable enough to dissect the above document, can be too incompetent to write a simple and useful reply in one go; instead, one has to hold his hand and guide him towards generating a somewhat useful reply.
Stay away, petty little trashcan.
|
|
|
The summary needs the definition of "entropy".
There are a few of them i.e. physical entropy, Shannon entropy, entropy relevant to domain of "Master Seed Generation" etc..
I would prefer to see that OP understand the difference and provide the explicit meaning of entropy he used when summarizing his knowledge.
As far as I could find, the entropy simply refers to "randomness", with the former being collected by a CSPRNG that collects randomness from a mixture of external sources (i.e., environmental noise, system events, or user input)... Those are just fancy words that don't reveal the essence. In the domain of "Master Seed Generation" entropy is just a big ( commonly 128/256 bits) binary number. Ideally it must be random... but, there is always a but. Its randomness depends on the way by which it has been generated. The best way is to digitize physical processes that are believed to be stochastic. For instance, Passport wallet digitizes Avalanche noise for this purpose. How'd you change that?
It is your summary, not mine  Fancy words that describe the process. If you're not willing to help, you might as well stay away altogether.
|
|
|
Nonetheless, I'm curious as to what can be tweaked more, please be precise!
Only the document's title, everything checks out. BIP39 should be predominantly mentioned, should be something like " BIP39, Generation of Master Seed". Because not all HD wallets use mnemonic, for example, Bitcoin Core. In cases where the wallet doesn't follow BIP39 standard; the master seed ( seed, hdseed) is usually generated though pRNG, and not from a mnemonic. What you're describing, however, is the derivation of the master extended private key, which is derived indeed derived by passing the master seed + "Bitcoin Seed" string through the HMAC-SHA512.
I think he's talking about BIP32's master key derivation from the entropy, he might have misunderstood the document. Link: github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#master-key-generation( one reason to be specific with the title) Hm, alright.
|
|
|
The summary needs the definition of "entropy".
There are a few of them i.e. physical entropy, Shannon entropy, entropy relevant to domain of "Master Seed Generation" etc..
I would prefer to see that OP understand the difference and provide the explicit meaning of entropy he used when summarizing his knowledge.
Hm, maybe you can help me with that? As far as I could find, the entropy simply refers to "randomness", with the former being collected by a CSPRNG that collects randomness from a mixture of external sources (i.e., environmental noise, system events, or user input)... How'd you change that?
|
|
|
BIPs are quite hard for normal people to understand, so infographics that basically summarize them are always appreciated.
I see you missed the part involving HMAC-SHA3512. It's not strictly involved in creating the master seed itself but it uses the master seed to create the master private key. I can't check right now, but I recall from memory that the entropy input is passed through that MAC, with "Bitcoin seed" as the data (I believe the case of the characters is like that) and the entropy as the secret key. Then the output is split into two halves being the extended key (i.e. the master key itself) and chain code.
The OP title does say "master seed" so when people talk about that they are usually referring to the entropy as in your document.
Thank you! Yeah, I also share your sentiment on Bips. What you're describing, however, is the derivation of the master extended private key, which is derived indeed derived by passing the master seed + "Bitcoin Seed" string through the HMAC-SHA512. I'm working on the derivation part, wherein the above is covered as well.
|
|
|
You're not helpful, man. I want to know if the above ~8 min read is correct or not; if you can't bring up the energy to have a read-through of the summary and report back to me, you might as well stay away altogether.
You could've responded with something helpful, but no, some links here and some rambling there, stay away.
Edit: 🤣, I had a look over it, and it's essentially a simplified version of the above... How will that help?
|
|
|
Thank you!! Hm, I know about the other bit-length's existence, but as you say yourself: they usually aren't used, which is why I chose to leave them out.  Hm, clear, but it's not wrong to leave it in, correct? Many thanks! 🤠
|
|
|
[Personal] should indicate pretty well who it's aimed for, and why can't you guys simply be supportive for once? It's the technical section, ain't it? Every time all you guys do is throw around with some bips, who, and I've looked at them, are many times more confusing (using key words the average Joe knows jack-shit about) than the document above. No wonder everyone I talk to thinks that you guys are a special kind of idiots.
Edit: confused it with bip 32, to which the above adhered. Bip 39, on the other hand, ONLY specifies the words and what they have to adhere to, so how's that any more helpful than the above?!
I'm done here, you guys seem to enjoy the occasional ordinals-rant along with some cringe (worthless) experiments.
|
|
|
I've finalized my summary about HD-wallet's master seed generation, and would like to hear some input regarding it's contents! I'll most likely continue refinement of the content in the future, but for now, I'd simply like to have the summary reviewed on both chronological- and factual correctness. 🤠 I've spent multiple weeks on reading, gathering, writing and refining the summary, and have reached out to Greg Walker (Learnmeabitcoin.com) to ask if he'd be willing to give my summary an initial review, which he did! Nonetheless, I'm curious as to what can be tweaked more, please be precise! I've shared the link to the document here: https://acrobat.adobe.com/id/urn:aaid:sc:EU:981be534-af5c-4bdf-85a5-17926f5044fa
|
|
|
🤣, I keep on finding other parts of the picture... Truly a gift that keeps on giving... Bitcoin.
But is the above going in the right direction?
|
|
|
I'm trying to write a personal summary, and the above is a rough start. Thanks for the great input, though, you're especially trained in being an asshole, it seems. Typical Bitcoin Talk trash.
|
|
|
Derivation of Extended Private Key
The extended private key is derived from the root key by employing a cryptographic hash function, such as HMAC-SHA512, resulting in a hash value that contains both the chain code and extended private key.
• The hash value is 512 bits (64 bytes) in size. The first 256 bits (32 bytes) of the hash represent the chain code, while the next 256 bits (32 bytes) represent the extended private key.
• The chain code, along with the parent private key, is then used to deterministically derive child keys. By combining the parent private key with the chain code and an index, a unique child key is generated.
This ensures that the same child key can be derived independently by different parties as long as they have the same parent private key and chain code.
Moreover, The chain code also enhances security by preventing the derivation of parent private keys from child keys alone, adding an additional layer of protection to hierarchical deterministic wallets.
Derivation of Extended Public Key
The extended public key is derived from the extended private key by applying elliptic curve cryptography (ECC) to the corresponding private key, resulting in the public key, which is subsequently combined with the chain code from the extended private key to form the extended public key—thereby enabling the same deterministic derivation of child keys as the extended private key.
ECC is a type of asymmetric cryptography that relies on the mathematical properties of elliptic curves over finite fields.
An elliptic curve is defined by an equation of the form y² = x³ + ax + b mod p, where y² and x³ represent the coordinates of points on the curve, including both the generator point G (denoted as xG and yG) and the resulting public key K (denoted as xK and yK).
Furthermore, a, b, and p are parameters that define a specific elliptic curve, with a and b determining the specific shape and properties of the curve, and p ensuring that the curve operates over a finite field of 2*256 elements, providing a large number of points for cryptographic operations.
• The specific curve utilized in the Bitcoin protocol is “secp256k1”, with the above referring to that specific curve.
In order to derive public key K, generator point G is added to itself k times, or K = k × G, where K is the resulting point (the public key), k is the private key, and G is the generator point.
• The generator point G is a fixed point on the elliptic curve that serves as the starting point for generating other points on the curve through scalar multiplication, which refers to the operation of adding point G to itself multiple times.
• Each addition of G to itself represents one "step" in the multiplication process, and after k steps, we arrive at the resulting point K, which is the public key corresponding to the private key k.
Once the public key is known, it is combined with the chain code derived from the extended private key, a checksum is computed and appended, and the package is encoded into Base 58, rendering the extended public key human-readable and suitable for use in HD wallets.
|
|
|
I see, thanks. I'll have to dive deeper into this, I've edited the summary with your example, I like it.
|
|
|
Sharp, thanks! I've edited the summary.
|
|
|
Hey there, me again: https://www.reddit.com/u/Fabs_-/s/kntRD6IAOfBlockchain, longest chain and reorg’s The "longest" chain refers to the blockchain which took the most energy and accumulated work to build, hence it's also referred to as the "strongest" chain. The longest chain refers to the blockchain which individual nodes accept as the valid version of the blockchain, allowing said nodes to agree on the same blockchain and thus, the same transaction history. Occasionally there’s a short-lived uncertainty between nodes about the longest chain, which happens when two miners mine and broadcast a new block at (almost) the same time. Due to the propagation speed of blocks across the Bitcoin network, different parts of the network will receive one of either two blocks, leading to some nodes following Chain A, and others Chain B. Once the next block is mined, confirmed and broadcast, it will either be linked to the blocks of Chain A, or the blocks on Chain B, creating a new longest chain, leading to the respective nodes following the other chain to perform a chain reorganization in order to catch up. A chain reorganization refers to the process of adopting the new longest chain. Once the chain reorganization has been finished, block(s) on the new longest chain will be activated, and block(s) that were part of the other chain will be deactivated, leading to them no longer being a part of the transaction history of the longest chain and thus, the blockchain. The deactivated block(s) from the other chain are referred to as (a) "stale block(s)", which are block(s) that are no longer part of the longest chain. Transactions that were contained within the stale block(s) will be recycled into a node’s mempool, and propagated across the Bitcoin network once more for a chance to be mined in a future block. Anything that should be edited?
|
|
|
Hmm, I don't know how I should word this, nor would I say that I fully understand what you mean, could you expand on this?
|
|
|
I have, what a pis-poor experience this forum has been so far, aside from a handful of sharp inputs.
|
|
|
What a joke, honesty. What benefit would I have in blindly copying other's?! Fine. I'll have a post up on Reddit where I'll mention my username here, as well as my activity on Bitcoin talk. https://www.reddit.com/u/Fabs_-/s/sHSWMLSrYu
|
|
|
|