Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a tiny blockchain

medium.com

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Building a tiny blockchain

#51

Post by e12e »

DSMan195276 wrote: post #22
jbb67 wrote: post #11

Earlier quoted context omitted.

As for proof of work, am I right in assuming it works like this :- Add a field to store a random number. Keep generating values for this field until the hash of the structure has 'n' leading zeros. Is that more or less correct?

Yes, that's more or less it. It's worth adding to that description that the hash must be secure in that it does not allow determining what random number to use to get a particular output (I'm sure you already recognized this detail - it just guarantees you have to keep trying actually random numbers to find a result). Also worth adding is that the 'n' (Basically the difficulty) is generally going to need some way of…

And this scaling of the work factor - is that tied to timestamps in the previous blocks? (Ie - the work factor is something like max(average(time_blockN - time_blockN+1)?

[ed: from other comments, I gather that "passage of time" means "added blocks (hashes)" - but I'm still not clear on where the agreement on what constitutes "in 10 minutes on average" comes from - if A sees an addition to the blockchain of N blocks with X proof-of-work, lets call it N * X from B, and sees M blocks with Y proof-of-work from C -- it should be easy to figure out which is bigger of N * X and M * Y (here we don't really assume multiplication, but some way to figure out maximum proof-of-work).

But how does A know how long either took? Is the time local, so that A looks at the head of the B and C chains, and considers when A saw this head, and figure the elapsed time based on that?]

Re: Building a tiny blockchain

#52

Post by e12e »

Regardless of the quality of the article, it's refreshing to see so many good questions and concise answers in this thread (mostly about blockchains-as-distributed-ledgers). It's been a while since I saw such nice, civil and interesting technical discussion on hn.

Re: Building a tiny blockchain

#54

Post by DSMan195276 »

e12e wrote: post #51
DSMan195276 wrote: post #22

Earlier quoted context omitted.

Yes, that's more or less it. It's worth adding to that description that the hash must be secure in that it does not allow determining what random number to use to get a particular output (I'm sure you already recognized this detail - it just guarantees you have to keep trying actually random numbers to find a result). Also worth adding is that the 'n' (Basically the difficulty) is generally going to need some way of…

And this scaling of the work factor - is that tied to timestamps in the previous blocks? (Ie - the work factor is something like max(average(time_blockN - time_blockN+1)? [ed: from other comments, I gather that "passage of time" means "added blocks (hashes)" - but I'm still not clear on where the agreement on what constitutes "in 10 minutes on average" comes from - if A sees an addition to the blockchain of N blocks…

Yes, but it is not adjusted per-block, but every 2016 blocks (Which is 2 weeks time if each block takes 10 minutes to find).

It's also worth keeping in mind the problem that timestamps are technically forge-able by the miner. Bitcoin doesn't really solve this problem, but it does place requirements that the timestamp of a block be larger then the average of the past 11 (With various constraints). Thus if you presumably have mining distributed enough, then one giving you as invalid of a time as would still be accepted wouldn't end-up affecting things long-term since they can't generate blocks fast enough to heavily affect the average. Still technically an attack vector though.

Re: Building a tiny blockchain

#56

Post by nickporter »

gtfierro wrote: post #46
ue_ wrote: post #45

Earlier quoted context omitted.

Why would that make it more secure? Couldn't I simply make a lot of fraudelent transactions and append them, having a long chain, but a false one?

You could, but you'd be competing with everyone else that's also making transactions so you'd need an incredible amount of computational power to outstrip that.

And if you had that much hashing power, you'd be better off using it for mining. It's explained in more detail in the (surprisingly accessible) bitcoin whitepaper.

Re: Building a tiny blockchain

#58

Post by simias »

todd_wanna_code wrote: post #38
cableshaft wrote: post #28

Regardless of the semantic discussion on what exactly a 'blockchain' is and whether or not this qualifies, I found the article interesting by taking a tiny piece of the whole monster and demystifying it a bit. I don't see this any differently than a tutorial that makes a static image move around the screen with key presses. Is it a full game? Not at all. But can it teach you how to build a tiny piece of it, and you c…

Hey you got some link for other tutorials to go from here?

The clever part about bitcoin is reusing existing technologies in a novel way.

It uses:

- Hashcash-style proof of work: http://www.hashcash.org/ (originally designed to make spamming harder, although I don't think it ever really became widely adopted).

- Merkle trees to reference transactions in the blocks (same technology used for bittorent chunks): https://en.wikipedia.org/wiki/Merkle_tree

- Elliptic curve cryptography for signing transactions: https://en.wikipedia.org/wiki/Elliptic_curve_cryptography (asymmetric cryptography, used in TLS, SSH etc...)

- When a new "node" connects to the network it uses hardcoded addresses and DNS seeds to find other nodes to connect to: https://bitcoin.org/en/glossary/dns-seed (before that it used IRC)

And there are probably a few other things but basically if you know how to work with those technologies then you have all the tools you need to implement a bitcoin clone. It's nothing groundbreaking, it's "just" a clever novel use of existing technology.

All the actual "rules" of the network (the block reward etc...) are simply validated in the nodes, they'll reject any block that's not properly crafted (i.e. bad reward, invalid proof of work etc...). Therefore the node consensus dictates what bitcoin is. If you implement a non-compatible change in the client and you don't convince all the other users to switch you create a fork since you won't have the same definition of what constitutes a valid block.

Re: Building a tiny blockchain

#59

Post by Uptrenda »

ivanbakel wrote: post #21
Uptrenda wrote: post #9

Earlier quoted context omitted.

This is a really twisted take on blockchains. The whole point behind a blockchain is that cryptoeconomic incentives serve as an additional security function which is better than relying on generosity alone to contribute hashing power. So while it is true that a blockchain can exist without any kind of currency - the real genius behind blockchains is how they are designed as a new kind of corporation - one which requi…

> The whole point behind a blockchain is that cryptoeconomic incentives serve as an additional security function which is better than relying on generosity alone to contribute hashing power. This has nothing to do with blockchains. What you're describing is proof of work with a payout system, and you could implement that without a blockchain at all. >So while it is true that a blockchain can exist without any kind of…

Okay, lets argue that a blockchain is simply a data structure to create a linked list of hashes... Do you know what's part of that data structure as defined in the original paper: the format of a new block hash (how many zeros it has.) It's the fingerprint of a block that decides how to extend the chain. So if you simply decide to build a linked chain of blocks without any regard to the format of block hashes (proof-of-work) and the total accumulative hashing power, then it makes no sense at all.

Like I said: you can't just abstract this part away as a "data structure" and still have it mean anything. Without proof-of-work your toy example is literally just a made-up document sitting on a single computer.

>blockchains are data structures, not a concept exclusive to currency.

Blockchains as a linked list of hashes don't make sense. You need proof-of-work to decide on the chain. Proof-of-work is expensive so without the currency, proof-of-work doesn't make sense. There are other ways to agree on the order of events but they are not blockchains as understood by the experts in this space (and removing any one of these things undermines the benefits.)

Journalists and enterprise "blockchains" enthusiasts are free to use the term however they like but it doesn't change the fact that blockchains were introduced as an incentivized, trust-free ledger of value -- and by removing any one of its parts the benefits are still lost.

>This is not what the blockchain does. The blockchain helps to ensure that Proof of Work is effective for maintaining consensus after blocks are made - it's the role of PoW to produce the agreement. A blockchain without PoW would allow members to produce new combinations of blocks at will to edit the history.

Blockchains use proof-of-work to create agreement and pay anonymous contributors for doing the work to do so, its as simple as that. A "blockchain" without either of these things is not a blockchain. Incentives are needed to improve social scalability and ensure that there is a reason to continue to secure the ledger.

Proof-of-work is used to give the chain its meaning. I could hash a list of documents right now that said I had millions of dollars but this list couldn't be used by anyone else in an untrusting network of computers without a consensus algorithm... It just so happens that proof-of-work is still the most secure way to do that consensus. So you cannot abstract it away as a "data structure" independent from proof-of-work and the incentives that drive it...

The argument you're trying to make about "blockchains" is something I've only seen enterprise blockchain enthusiasts make about ledgers, and these people usually don't understand the system very well so they end up taking parts of the blockchain away and building something that makes little sense in the end (sometimes its an improvement but usually not.)

Re: Building a tiny blockchain

#60

Post by DSMan195276 »

e12e wrote: post #51
DSMan195276 wrote: post #22

Earlier quoted context omitted.

Yes, that's more or less it. It's worth adding to that description that the hash must be secure in that it does not allow determining what random number to use to get a particular output (I'm sure you already recognized this detail - it just guarantees you have to keep trying actually random numbers to find a result). Also worth adding is that the 'n' (Basically the difficulty) is generally going to need some way of…

And this scaling of the work factor - is that tied to timestamps in the previous blocks? (Ie - the work factor is something like max(average(time_blockN - time_blockN+1)? [ed: from other comments, I gather that "passage of time" means "added blocks (hashes)" - but I'm still not clear on where the agreement on what constitutes "in 10 minutes on average" comes from - if A sees an addition to the blockchain of N blocks…

To respond to your edit (Which I don't think I quite explained):

In that situation, A doesn't care how long it actually took to find those blocks, the scaling of the difficulty/work-factor handles that. A can rely on the fact that (Unless someone introduced or removed a significant chunk of hashing power, or broke the hashing algorithm) the current network difficulty represents the amount of work needed to represent approximately '10 minutes'. PoW below that difficulty isn't accepted, and above that would be considered proving more work then required (But is also, of course, harder to find. So it proves more, but should take longer then 10 minutes for the network to find).

Since Bitcoin calculates the difficulty to result in about 10 minutes between blocks (As I explained in my last comment), that's how long it should approximately take. It's possible B or C got lucky and found it faster then that, but statistically that is unlikely since the hash result is completely random. If significantly more hashing power is added to the network and the blocks are consistently found faster then the target time, then when the difficulty is recalculated later-on (After the 2016 blocks are done) it will go-up, making them again take about 10 minutes with the hew hashing power taken into account.

Post reply on HN