Live data from Hacker News

Tinychain: a pocket-sized implementation of Bitcoin

github.com

11–20 of 45 posts

Re: Tinychain: a pocket-sized implementation of Bitcoin

#11
post #4

I'm working on my own blockchain (not specifically bitcoin) implementation just to wrap my head around everything. One thing I'm not getting that also wasn't answered by the source code is how you check timestamps. I understand the whole network time = median offset + local time thing, however I'm a bit fuzzy on how you check timestamps on previous blocks when you're initially downloading the chain. How do you know t…

In my toy blockchain implementation, I just went with two constraints: 1) every timestamp must be strictly larger than the one of the previous block (this makes difficulty calculation easier) 2) timestamps may not be in the future (except for a little wiggle room for unsynchronized clocks)

My reasoning was roughly as follows:

Miners are incentivized to pick very large timestamps, because the longer it takes to mine X blocks, the easier becomes the proof of work they need to solve, giving them more block rewards and transaction fees in the long run. But if they want the network to accept their blocks, they can't pick timestamps in the future, so the best they can do is pick the current time as their timestamp.

Re: Tinychain: a pocket-sized implementation of Bitcoin

#12
I can see this useful for all cryptocurrencies as well as alleviating some of the need for hedge funds investing in cryptocurrencies for their clients as brought out here ...Hedge Funds Investing in Cryptocurrencies ‘Exploding’ – 62 in Pipeline https://news.bitcoin.com/hedge-funds-investing-in-cryptocurr...

Re: Tinychain: a pocket-sized implementation of Bitcoin

#13
post #4

I'm working on my own blockchain (not specifically bitcoin) implementation just to wrap my head around everything. One thing I'm not getting that also wasn't answered by the source code is how you check timestamps. I understand the whole network time = median offset + local time thing, however I'm a bit fuzzy on how you check timestamps on previous blocks when you're initially downloading the chain. How do you know t…

In my toy blockchain implementation, I just went with two constraints: 1) every timestamp must be strictly larger than the one of the previous block (this makes difficulty calculation easier) 2) timestamps may not be in the future (except for a little wiggle room for unsynchronized clocks) My reasoning was roughly as follows: Miners are incentivized to pick very large timestamps, because the longer it takes to mine X…

Okay, this makes sense! I keep thinking too strictly with my constraints.

Re: Tinychain: a pocket-sized implementation of Bitcoin

#14
post #8

Currently reading through a book on bitcoin, so this is extremely timely! Got me thinking, what are some solid bitcoin/cryptocurrency resources that the HN community would recommend?

I link to some of my favorite resources at the end of this section: https://github.com/jamesob/tinychain#what-is-bitcoin

I also recommend subscribing to the bitcoin-core-dev mailing list.

Re: Tinychain: a pocket-sized implementation of Bitcoin

#16
I'm also working on my own cryptocurrency implementation forked from known basiccoin of Zack Hess. Simply I'm trying to make the code more readable, fix bugs and provide better API. Currently I do not have a fine README that explains my intentions but going through the whole code and rewriting most parts made me realize how simple actually blockchain is. Thinking about fine details like how synchronization of blockchain should work is really inspiring. If you want to take a look at the code it is on https://github.com/halilozercan/halocoin

Re: Tinychain: a pocket-sized implementation of Bitcoin

#17
post #4

I'm working on my own blockchain (not specifically bitcoin) implementation just to wrap my head around everything. One thing I'm not getting that also wasn't answered by the source code is how you check timestamps. I understand the whole network time = median offset + local time thing, however I'm a bit fuzzy on how you check timestamps on previous blocks when you're initially downloading the chain. How do you know t…

Wouldn't you only need to verify proof-of-work on the largest chain? Largest meaning the highest cumulative difficulty rather than number of blocks.

If you include a timestamp in each block, just have each node simply reject times that are out of order or too far from the current time, which will prevent people from mining on an invalid chain. "Current time" meaning nothing more than a few minutes in the future of now. Yes, even when dealing with an old chain.

Here is how it works:

If an invalid or malicious person spends hashrate to mine a block with a bad date, all the nodes in the network will see it and reject the block.

Because the block is rejected, everyone else keeps attempting to mine the same block, but with the correct timestamp. The window is: greater than the last block, less than a couple minutes from now.

Because most miners are on non-malicious nodes, they eventually produce a longer chain than the chain with the bad timestamp.

Because this good chain is longer, new nodes that sync the blockchain from scratch would simply pick the longest of the available chains (which is the good one).

This could still go wrong if the attacker has a large amount of hashrate (or luck) for an extended period of time, but this gets very expensive very fast. This is why it is sometimes good to wait a few blocks before assuming consensus.

Re: Tinychain: a pocket-sized implementation of Bitcoin

#18
post #4

I'm working on my own blockchain (not specifically bitcoin) implementation just to wrap my head around everything. One thing I'm not getting that also wasn't answered by the source code is how you check timestamps. I understand the whole network time = median offset + local time thing, however I'm a bit fuzzy on how you check timestamps on previous blocks when you're initially downloading the chain. How do you know t…

A block's timestamp is frozen in its hash, which is validated by any node receiving a block (whether during initial block download or otherwise). Bitcoin and tinychain don't accept blocks with a timestamp in the future beyond some threshold (in both cases 2 hours).

Re: Tinychain: a pocket-sized implementation of Bitcoin

#19
post #4

I'm working on my own blockchain (not specifically bitcoin) implementation just to wrap my head around everything. One thing I'm not getting that also wasn't answered by the source code is how you check timestamps. I understand the whole network time = median offset + local time thing, however I'm a bit fuzzy on how you check timestamps on previous blocks when you're initially downloading the chain. How do you know t…

AFAIK you don't need to check historical timestamps (beyond sanity checks) during initial block download (IBD).

What you need to consider is whether an attacker can manipulate historical timestamps to get you to follow the wrong blockchain. The answer is, they can't.

The only thing manipulating historical timestamps would accomplish is allow the attacker to change the historical difficulty of their alternative blockchain. But that doesn't enable them to add additional proof of work. The amount of total proof of work they can add to an alternative blockchain is not dictated by difficulty, but merely by how much hashrate they have poured into the chain.

Since total proof of work for a chain is the metric by which the "correct" blockchain is established we can conclude that manipulating historical timestamps doesn't make it any easier for an attacker to get you to follow their chain.

That's for IBD. Obviously you need to verify timestamps after IBD, since timestamps are used to adjust difficulty and that's a consensus critical rule.

Re: Tinychain: a pocket-sized implementation of Bitcoin

#20
post #8

Currently reading through a book on bitcoin, so this is extremely timely! Got me thinking, what are some solid bitcoin/cryptocurrency resources that the HN community would recommend?

Satoshi's original posts to the cryptography mailing list, and its members' responses are also of tremendous value. The chain starts at: http://www.metzdowd.com/pipermail/cryptography/2008-October/...
Post reply on HN