Bitcoin From Scratch – Part 1 • Hacker News Board

Re: Bitcoin From Scratch – Part 1

#61

Post by [deleted] » Sat, Jul 04, 2020, 12:47 PM UTC

martinko wrote: post #39

johnpaulkiser wrote: post #37

Earlier quoted context omitted.

Each node independently comes to the new difficulty on their own in an entirely deterministic way. After 2 weeks there should be 2016 blocks mined, 1 block every 10 minutes. After each 2 week period every node recalculates the new difficulty based on the actual number of blocks mined in the last 2 weeks. If the actual number of blocks produced was 25% higher than the target of 2016, then simply increase the difficult…

Thanks. Given that this relies on subjective timestamps, is this really entirely deterministic? I can imagine that one node counted 2014 blocks in the past two weeks, another 2015. What happens in such cases?

[deleted]

Re: Bitcoin From Scratch – Part 1

#62

Post by ur-whale » Sat, Jul 04, 2020, 1:07 PM UTC

Love this way of learning about tech. : build one yourself (the truly noble way would be to try and build without having seen the specs, just from a description of what it does, but that'd take ages).

However: when it comes to implementations, the real hard part of the whole Bitcoin affair is where the gnarly details hide, namely consensu, and it is missing at this point.

Re: Bitcoin From Scratch – Part 1

#63

Post by sillysaurusx » Sat, Jul 04, 2020, 1:16 PM UTC

TekMol wrote: post #58

robjan wrote: post #49

Earlier quoted context omitted.

You can see what your functions do by opening the file called util.js in the same directory. And, yes you can run this in the browser by either polyfilling "require" or transpiling it

By that logic, everything runs in a browser. The principle of computational equivalence tells us that one turing complete language can do what any other can. So yes, everything can be polyfilled or transpiled. But that does not really meet my understanding of "Runs in the browser".

If you run browserify on an index.js file, it will usually spit out a single .js file that will run in the browser.

Re: Bitcoin From Scratch – Part 1

#64

Post by WhoIsSatoshi » Sat, Jul 04, 2020, 1:52 PM UTC

nemo1618 wrote: post #2

> The PoW is suffice if the hash begins with a certain number of 0s This is a common explanation of PoW, but is actually incorrect. If you think about it, this would mean that the PoW difficulty could only increase (or decrease) by a factor of two. In reality, the block hash is simply interpreted as a (very large) number, and this number must be less than some other very large number (the "target"). So you do end up…

Do you have a source I can look at or do I have to go look at at or can you point to code by chance?

I'm quite surprised I wasn't aware of this if this is actually how it is implemented, the leading zeroes seemed right (and the difficulty by factor of 2 also!)

Thanks!

Re: Bitcoin From Scratch – Part 1

#65

Post by monokh » Sat, Jul 04, 2020, 2:02 PM UTC

jstanley wrote: post #57

rammy1234 wrote: post #56

Mining part is confusing for me. Is POW is essentially to achieve difficulty level ? You do in this while loop until you have achieved this difficulty level ? Is this the primary factor that differentiates having various protocol in crypto ?

Yes. Proof of Work is required so that there is a global limit on the rate at which new coins are created.

It also:

- Acts as the primary mechanism to make the data in the chain immutable, as the cumulation of the work (chain of valid blocks) becomes harder and harder to reproduce.

- Anti spam, i.e. you need to put something at stake (electricity and hardware cost) to participate in the issuance and transaction ordering

Re: Bitcoin From Scratch – Part 1

#66

Post by bouncycastle » Sat, Jul 04, 2020, 2:10 PM UTC

yaktubi wrote: post #54

bouncycastle wrote: post #18

Earlier quoted context omitted.

Even this sentence is just a number.

Really it’s not because it’s a sequence of glyphs first and foremost. It can be mapped to a number though.

Nope, no mapping necessary. 36 octets, so a single 288 bit number in base 2. (Big-endian, unsigned, I guess) Then convert to any base you want.

(I should have probably used 32 octets so that it fits neatly in 256 bits)

Re: Bitcoin From Scratch – Part 1

#67

Post by monokh » Sat, Jul 04, 2020, 2:45 PM UTC

fogetti wrote: post #59

> the transaction needs to be "Signed" by the `from` public key Is that so? The code actually signs with the private key. Although I might have misunderstood what that sentence refer to.

Thanks, that was a mistake. I've corrected it.

Re: Bitcoin From Scratch – Part 1

#68

Post by tromp » Sat, Jul 04, 2020, 2:47 PM UTC

runeks wrote: post #60

sodascripts wrote: post #3

Earlier quoted context omitted.

TIL. I wonder why that myth is so commonly perpetuated.

It’s not a myth. It’s a useful simplification.

It's also accurate if you say that hash value H has

-log_2 (H / 2^256) = 256 - log_2 H leading 0s

and allow for fractional number of leading 0s.

The nBits header field closely resembles a 32-bit floating point representation of this number (I say resembles because it's really a floating point representation of the threshold H value).

Re: Bitcoin From Scratch – Part 1

#69

Post by nemo1618 » Sat, Jul 04, 2020, 2:56 PM UTC

WhoIsSatoshi wrote: post #64

nemo1618 wrote: post #2

> The PoW is suffice if the hash begins with a certain number of 0s This is a common explanation of PoW, but is actually incorrect. If you think about it, this would mean that the PoW difficulty could only increase (or decrease) by a factor of two. In reality, the block hash is simply interpreted as a (very large) number, and this number must be less than some other very large number (the "target"). So you do end up…

Do you have a source I can look at or do I have to go look at at or can you point to code by chance? I'm quite surprised I wasn't aware of this if this is actually how it is implemented, the leading zeroes seemed right (and the difficulty by factor of 2 also!) Thanks!

Someone else linked it below: https://github.com/bitcoin/bitcoin/blob/e071a3f6c06f41068ad1...

Equivalent check in btcd, an alternative Bitcoin implementation: https://github.com/btcsuite/btcd/blob/991d32e72fe84d5fbf9c47...

Re: Bitcoin From Scratch – Part 1

#70

Post by tlrobinson » Sat, Jul 04, 2020, 4:04 PM UTC

TekMol wrote: post #58

robjan wrote: post #49

Earlier quoted context omitted.

You can see what your functions do by opening the file called util.js in the same directory. And, yes you can run this in the browser by either polyfilling "require" or transpiling it

By that logic, everything runs in a browser. The principle of computational equivalence tells us that one turing complete language can do what any other can. So yes, everything can be polyfilled or transpiled. But that does not really meet my understanding of "Runs in the browser".

When I open https://tomcoin.herokuapp.com/ in a browser I see it running. That meets my definition of "runs in the browser".

Would you have been happier if I wrote "written in a dialect of JavaScript which is transpiled to ES5 using Webpack and Babel so it can run in the browser"?